Certificate without IP-Address for node-to-node communication

[jupp]

Hi Folks,

is it possible to leave the IP in the SAN for node-to-node communication. We want to verify only based on the DNS of the Server.
I ask because we won't Change our Certificate when the ip-adress changes (think about moving a VM within V-Sphere to another Location/VLAN/Rack)

Greetz,

Jupp

[jpcarey (Jared Carey)]

You can use purely DNS names, if that is what you are asking. You need to set the network.publish_host to the DNS name, along with the zen discover host list being DNS names.

[jupp]

Sorry @jpcarey my question was totally unclear.

Next try: When i generate a Certitifcate for a Elasticsearch-Node it seems that i must put also the ip-Adress of the node in the SAN section along withe the Distinguish Names (DNs) - right?

It seems that the node tries to resolve the ip of the hostname and tries to match against the ip in the SAN of the certificate when it wants to communicate with another node in the cluster via ssl. When the IP-Address is not in the certificate the communication-partner is not trusted. We install our nodes on VMs which are manage by VSphere. For Maintenance it is possible that the Servers will be move to another Rack. The Hostname will be the same but the IP-Address can change especially when the server will be moved in another VLAN. The Certificate would be invalid and we must generate a new one.

Without the the ip-address in the SAN it would be possible to reuse the certificate. Is it possible to disable the ip-validation by a property or a special certificate-konfiguration?
Certificate-signing is unfortuately not automatic yet in our company but we must use our own Company CA so we cannot use certutil to generate one.

Greetings
Jupp

[jpcarey (Jared Carey)]

The certificate does not need to contain an IP address, you can use purely DNS - just be sure as I mentioned before that elasticsearch has been setup to communicate using DNS. Elasticsearch by default is going to check that the certificate that it is being presented (from another node) has at least one valid identity / value contained in the cert. I don't think having an incorrect IP would matter, as long as the DNS name that it tries correctly resolves to the the IP address of the connection.

Example. If I was node01.corp.local, and I was connecting to node02.corp.local - node02 should present a certificate that would have a SAN:

        X509v3 extensions:
            X509v3 Subject Alternative Name: critical
                DNS:node02.corp.local

In order for node01 to connect to node02, it had to resolve an IP address. As long as the IP address matches the DNS resolution of node02.corp.local - it would allow the TLS connection (assuming it also trusted the direct certificate, or the signing authority of the certificate).

I made a blog around this that you might find helpful. https://www.elastic.co/blog/tls-elastic-stack-elasticsearch-kibana-logstash-filebeat

Also, Java by default will cache a successful dns lookup forever. If you change the IP, java will not know without a restart. You will need to modify the java security policy for an appropriate refresh rate:
https://www.elastic.co/guide/en/cloud/current/_dns_caching.html#_dns_caching

[jupp]

Hi Jared, your blogpost and this Thread helped us a lot. We are now evaluating the right Configuration (which bind_host, which publish_host) in conjunction with our CA.

Some Properties in X-Pack are a bit confusing, like the clientAuthentication-Property, it has different defaults in the main-Section and in the http-Section. But when you think about i it. It makes sense

I think with your exhausting blogpost we can do it right now

Greetz

Jupp