Receiving "No subject alternative names matching IP address" when using wildcard cert in ES 5.0.2 cluster

Elastic Stack Elasticsearch
1

I've built a two node cluster and connected each node with no issues. I've installed the x-pack plugin and I'm trying to add SSL/TLS. Rather than generating a separate self-signed certificate for each node, I've got a wildcard certificate that was signed by a well-known commercial CA.

Both nodes are running on separate Amazon EC2 instances. The nodes are using the discovery-ec2 plugin. This works fine with SSL. When I deploy the certificate and configure ES, the nodes discover each other and try to communicate. However, now with SSL/TLS in the mix, each throws an error into the log with eventually traces down to this exception:

java.security.cert.CertificateException: No subject alternative names matching IP address 10.19.4.226 found

(Each has the IP address of the other node in the message).

Contents of elasticsearch.yml:
cluster.name: cluster01
node.name: ip-10-19-28-164.domain
path.conf: "/etc/elasticsearch"
path.data: "/var/lib/elasticsearch"
path.logs: "/var/log/elasticsearch"
network.host: site
node.master: true
node.data: false
http.cors.enabled: true
http.cors.allow-origin: "/.*/"
cloud.aws.region: us-east-1
cloud.node.auto_attributes: true
discovery.type: ec2
discovery.zen.minimum_master_nodes: 2
discovery.ec2.groups: cluster_group
cluster.routing.allocation.awareness.attributes: aws_availability_zone
xpack.ssl.key: "/etc/elasticsearch/x-pack/.key"
xpack.ssl.certificate: "/etc/elasticsearch/x-pack/.crt"
xpack.security.transport.ssl.enabled: true
xpack.security.http.ssl.enabled: true

2

Heya Steven,

There were some cases where the hostname could get dropped for SSL/TLS in 5.0.0 - 5.0.2 that I fixed to solve these types of issues. Can you see how 5.1.1 works for you?

-Jay

3

Hi Jay.

I just tried using version 5.1.1 of Elasticsearch + x-pack and that did not fix the problem. The exception message remains the same as with 5.0.2.

Regards, Steven

4

I wonder if this has something to do with the EC2 discovery. Would you be willing to test with zen discovery and providing DNS names for the unicast hosts? If anything uses an IP address, this will cause the error you are seeing.

5

Sure I will give that a try and report back.

6

I believe you are correct, right now we have the discovery-ec2 reuturning IP addresses. I tried using IP addresses with zen discovery and I got the same error.

I don't have deep understanding of the wildcard certs. Is there no way to work around the IP address not working here?

Thanks for your help.

7

As a further update, I've also tried using discovery ec2 host type of PRIVATE_DNS, and I still get an exception on the certificate. The message changes to indicate DNS this time ( No subject alternative DNS name matching ip-10-19-19-193.ec2.internal found), but essentially the problem seems to not be specific to IP addresses.

Not sure what to try next, use of a wildcard certificate is much preferred in this use case.

Thanks.

8

Actually I should provide one more update. It looks like the wildcard I was given is different from the domain ec2.internal. So my last update may very well be in error, as I can easily see that ec2.internal doesn't match the actual wildcard I have.

So I'll repose my previous question, not know much about how wildcard certificates work, is there no good workaround for the IP address? That is the easiest thing for me to get from ec2 discovery.

Thanks again for the help.

9

One workaround that decreases the security a bit is turning off hostname verification; only the certificate that is presented will be verified and the host information will not be checked. You are already using a wild card certificate so hostname verification is already less secure as you are only verifying the domain of the server (*.foo.com). If you choose to turn off hostname verification, the setting would be xpack.security.transport.ssl.verification_mode: certificate.

10

This may be the approach we take. Your point about already using a wildcard cert is well taken. I will try this out as a workaround for us.

11

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