SSL certificate hostname issue in case of microservices internal communication

Question

I have to secure the microservices internal communication using SSL. All my microservices are spring boot application where we are using zookeeper as discovery server. The internal service communication takes place via rest template and feign client. we are using ribbon as client side load balancer. We have set the following properties in all the microservices

spring.application.name=Application1
spring.cloud.zookeeper.discovery.enabled=true
spring.cloud.zookeeper.connectString=localhost:2181
spring.cloud.zookeeper.enabled=true
server.port=7800
spring.cloud.zookeeper.discovery.instance-ssl-port=7801

server.ssl.enabled=true
server.ssl.key-store-type=JKS
server.ssl.key-store=classpath:LP-PF1HMVQU.jks
server.ssl.key-store-password=123456
server.ssl.key-alias=LP-PF1HMVQU
server.ssl.protocol=TLS

We have to use self signed certificate, i have generated the same and imported the certicate to JRE trust store to make the communication possible (SSL Handshake). The catch here is that i had to keep the CN of the certificate same as my system's host name (LP-PF1HMVQU). This is because when the service is registered with zookeeper, it stores machine name or hostname as its address and same is retured during the handshake.

Service registered on zookeeper

{"name":"employee-service","id":"b4c2204a-b00c-4102-b609-17d7f73f35d7","address":"LP-PF1HMVQU","port":7800,"sslPort":null,"payload":{"@class":"org.springframework.cloud.zookeeper.discovery.ZookeeperInstance","id":"application-1","name":"employee-service","metadata":{}},"registrationTimeUTC":1564658801106,"serviceType":"DYNAMIC","uriSpec":{"parts":[{"value":"scheme","variable":true},{"value":"://","variable":false},{"value":"address","variable":true},{"value":":","variable":false},{"value":"port","variable":true}]}}

Now in Production we will have a docker container for each service and there can be multiple docker containers for each service. These docker containers are registered to zookeeper and it keeps the IP-Address of the container.

How should i create the certificate, what should be the CN name, so that it matches any IP-Address. I have tried the wildcard * as the CN name but it did not work.

Please suggest how to achieve this.

Answer 1

what should be the CN name, so that it matches any IP-Address

Do not do that, it will not work (as expected)

HTTPS and IP addresses

While you technically can have an IP address in an HTTPS URL, like https://192.0.2.42/whatever, it will get you only trouble as the certificate attached to it will need to mention that IP, and not a name since there is not. It is technically possible (see certificate delivered by https://1.1.1.1/) just more difficult/out of standard cases.

Hence, instead, I recommend instead to register whatever domain name you want and then use that as a suffix for all your needs. If the name are publicly resolvable you will even be able to get DV certificates for them. If not, you will probably need to set up a private CA yourself.

You said also:

CN of the certificate same as my system's host name (LP-PF1HMVQU)

This is strange, because it is not a full name, and certainly not resolvable so no CA will agree to sign those kind of certificate. If that is really what you want (but see below) you will need your own private CA anyway.

CN and SAN

The very first certificate had only a "Subject" part where you could put a DN object, that is an X.400 description of some entity, an entity being either an individual, an abstract entity like an organization, an email address or an hostname, for a website.

So initially we had the website hostname as a CN component in the subject and browsers matched that.

But very fast the need arose to have one certificate for multiple names, starting with the "root" vs "www" duality, so an extension was created: Subject Alternative Names.

In there, one can put other names (or IP addresses as we will see below). Nowadays browsers (and more generally HTTP client) mostly disregard what is in the Subject, hence the CN, to look only after the "SAN" part.

So this is where you would need to put the IP addresses.

Let us look again at the certificate given back by https://1.1.1.1/. You can see in it the following for the subject part:

CN = cloudflare-dns.com
O = "Cloudflare, Inc."
L = San Francisco
ST = California
C = US

and for the SAN:

Not Critical
DNS Name: cloudflare-dns.com
DNS Name: *.cloudflare-dns.com
DNS Name: one.one.one.one
IP Address: 1.1.1.1
IP Address: 1.0.0.1
IP Address: 162.159.132.53
IP Address: 2606:4700:4700::1111
IP Address: 2606:4700:4700::1001
IP Address: 2606:4700:4700::64
IP Address: 2606:4700:4700::6400
IP Address: 162.159.36.1
IP Address: 162.159.46.1

So if you really want to have IP addresses in a certificate, this is how you need to do it. If you manage the CA by yourself, then it is technically not a big problem (you need to make sure to use

The full details (specification) are at https://www.rfc-editor.org/rfc/rfc5280#section-4.2.1.6 and you can find here and elsewhere a lot of instructions on how to craft proper CSR/certificates with the SAN extension needed for IP addresses.

Note that you can have wildcards for domain names in the SAN, like *.example.com but you can not have them for IP addresses. So your "it matches any IP-Address" seems a non goal. It looks like maybe you are after a blank certificate to bypass authentication and make your system work? If so, do not do that and drop that idea: TLS without authentication is mostly as bad as plain text, even if the exchange is encrypted as you do not know who you are encrypting too.