Enabling service discovery for services communicating with Mutual SSL

Consul
1

Hello,

I am a noob with Consul trying to set it up for service discovery in our platform at my company where services already talk to each other over mutual SSL.

After registering these services in Consul and using DNS for discovery, I get an SSL handshake error…

javax.net.ssl.SSLPeerUnverifiedException: Certificate for <my-api.service.consul> doesn't match any of the subject alternative names: [platform.local, 192.168.99.100]

…which is expected because the certificate in use doesn’t have the consul DNS in the SAN list.

I am interested to know what’s the best practice here to solve this issue? I can think of below options:

  1. Should I use a different certificate that has the consul DNS in SAN list? It is inconvenient and doesn’t seem scalable.
  2. Use HTTP API instead of DNS for discovery. Since we use a custom orchestrator, I find DNS to be very flexible for service discovery. HTTP API based discovery would require parsing the response to extract the address.
  3. Use Consul Connect Service Mesh? Is this problem the right use case for Connect service mesh? It adds more complexity so I want to be sure if this is the right way to go.
  4. Some other way… ?

Looking forward to hearing some opinions!

2

I’ve had the same issue in the past, and has been one of my bigger issues with consul service discovery. If I remember correctly, the suggestion was to use IPs in the cert, but as you said, I think that is a bad solution over all. If I can remember anything else, I’ll reply

3

Thanks for the reply Ryan.

Indeed adding IP/consul dns in the SAN would not be desirable as some of the services also use publicly signed certificates.

I am inclined to go for consul connect service mesh as mTLS is a very important feature for us and currently we do that separately in every service. But it does add complexity when combined with docker.