java.security.cert.CertificateException: No subject alternative names present while connecting to domain names

Elastic Stack Elasticsearch
1

I test the installation of elasticsearch + xpack on one single machine. I am having 3 nodes - es1.local, es2.local, es3.local, each node with different ports. I use discovery zen unicast hosts in form es1.local:PORT1, es2.local:PORT2 ... but I am seeing an exception with message:
java.security.cert.CertificateException: No subject alternative names present
AFAIK it should connect to domain names and no SAN should be presented in certificates. Am I doing something wrong?

2

Hi there, please take a look at X-Pack security Troubleshooting | X-Pack for the Elastic Stack [5.1] | Elastic. From that page:

java.security.cert.CertificateException: No subject alternative names present
Indicates that a client connection was made to an IP address but the returned certificate did not contain any SubjectAlternativeName entries. IP addresses are only used for hostname verification if they are specified as a SubjectAlternativeName during certificate creation. If the intent was to use IP addresses for hostname verification, then the certificate will need to be regenerated with the appropriate IP address.

Does this help?

Thanks,
CJ

3

Hello. I know this article. But I am not using IP addressess in elasticsearch.yml. I use domain names in zen discovery, see:

discovery.zen.minimum_master_nodes: 2
discovery.zen.ping.unicast.hosts:
- es1.local:9401
- es2.local:9402
- es3.local:9403
xpack.security.transport.ssl.verification_mode: certificate

I am using certification verification mode now because of the issue. But I think it should work with full verification mode also.

4

Why do you think that?
One type of SAN is a DNS Name, which is what you would need. If you want to perform hostname verification, then you need to have hostnames (SANs) in your certs.

5

I wrote it wrong, it should be: "SAN should not be required". In another environment I have one node per machine and it is using same ports. In that environment full (so certificate + hostname) verification works well. Also in that environment I do not use SAN certificates, there is just sufficient to have correct CN.
Maybe I should ask - what mechanisms the full verification uses to verify the host name?

1 Like
6

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.