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

**URL:** <https://discuss.elastic.co/t/receiving-no-subject-alternative-names-matching-ip-address-when-using-wildcard-cert-in-es-5-0-2-cluster/69322>\
**Category:** Elasticsearch\
**Created:** [December 16, 2016, 9:35pm UTC](https://discuss.elastic.co/t/receiving-no-subject-alternative-names-matching-ip-address-when-using-wildcard-cert-in-es-5-0-2-cluster/69322 "2016-12-16T21:35:33Z")\
**Posts on this page:** 11\
**Page:** 1

<div class="post-metadata">

**Author:** ![mungoknotwise](https://avatars.discourse-cdn.com/v4/letter/m/9dc877/32.png) [@mungoknotwise](https://discuss.elastic.co/u/mungoknotwise)\
**Post date:** [December 16, 2016, 9:35pm UTC](https://discuss.elastic.co/t/receiving-no-subject-alternative-names-matching-ip-address-when-using-wildcard-cert-in-es-5-0-2-cluster/69322/1 "2016-12-16T21:35:33Z")

</div>

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](http://cluster.name): cluster01  
[node.name](http://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

---

<div class="post-metadata">

**Author:** ![jaymode](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/jaymode/32/50103_2.png) [@jaymode](https://discuss.elastic.co/u/jaymode)\
**Post date:** [December 19, 2016, 12:35pm UTC](https://discuss.elastic.co/t/receiving-no-subject-alternative-names-matching-ip-address-when-using-wildcard-cert-in-es-5-0-2-cluster/69322/2 "2016-12-19T12:35:55Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![mungoknotwise](https://avatars.discourse-cdn.com/v4/letter/m/9dc877/32.png) [@mungoknotwise](https://discuss.elastic.co/u/mungoknotwise)\
**Post date:** [December 19, 2016, 1:31pm UTC](https://discuss.elastic.co/t/receiving-no-subject-alternative-names-matching-ip-address-when-using-wildcard-cert-in-es-5-0-2-cluster/69322/3 "2016-12-19T13:31:40Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![jaymode](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/jaymode/32/50103_2.png) [@jaymode](https://discuss.elastic.co/u/jaymode)\
**Post date:** [December 19, 2016, 1:49pm UTC](https://discuss.elastic.co/t/receiving-no-subject-alternative-names-matching-ip-address-when-using-wildcard-cert-in-es-5-0-2-cluster/69322/4 "2016-12-19T13:49:46Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![mungoknotwise](https://avatars.discourse-cdn.com/v4/letter/m/9dc877/32.png) [@mungoknotwise](https://discuss.elastic.co/u/mungoknotwise)\
**Post date:** [December 19, 2016, 2:10pm UTC](https://discuss.elastic.co/t/receiving-no-subject-alternative-names-matching-ip-address-when-using-wildcard-cert-in-es-5-0-2-cluster/69322/5 "2016-12-19T14:10:59Z")

</div>

Sure I will give that a try and report back.

---

<div class="post-metadata">

**Author:** ![mungoknotwise](https://avatars.discourse-cdn.com/v4/letter/m/9dc877/32.png) [@mungoknotwise](https://discuss.elastic.co/u/mungoknotwise)\
**Post date:** [December 19, 2016, 4:28pm UTC](https://discuss.elastic.co/t/receiving-no-subject-alternative-names-matching-ip-address-when-using-wildcard-cert-in-es-5-0-2-cluster/69322/6 "2016-12-19T16:28:59Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![mungoknotwise](https://avatars.discourse-cdn.com/v4/letter/m/9dc877/32.png) [@mungoknotwise](https://discuss.elastic.co/u/mungoknotwise)\
**Post date:** [December 19, 2016, 5:38pm UTC](https://discuss.elastic.co/t/receiving-no-subject-alternative-names-matching-ip-address-when-using-wildcard-cert-in-es-5-0-2-cluster/69322/7 "2016-12-19T17:38:54Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![mungoknotwise](https://avatars.discourse-cdn.com/v4/letter/m/9dc877/32.png) [@mungoknotwise](https://discuss.elastic.co/u/mungoknotwise)\
**Post date:** [December 19, 2016, 5:57pm UTC](https://discuss.elastic.co/t/receiving-no-subject-alternative-names-matching-ip-address-when-using-wildcard-cert-in-es-5-0-2-cluster/69322/8 "2016-12-19T17:57:15Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![jaymode](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/jaymode/32/50103_2.png) [@jaymode](https://discuss.elastic.co/u/jaymode)\
**Post date:** [December 19, 2016, 6:21pm UTC](https://discuss.elastic.co/t/receiving-no-subject-alternative-names-matching-ip-address-when-using-wildcard-cert-in-es-5-0-2-cluster/69322/9 "2016-12-19T18:21:09Z")

</div>

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`.

---

<div class="post-metadata">

**Author:** ![mungoknotwise](https://avatars.discourse-cdn.com/v4/letter/m/9dc877/32.png) [@mungoknotwise](https://discuss.elastic.co/u/mungoknotwise)\
**Post date:** [December 19, 2016, 6:41pm UTC](https://discuss.elastic.co/t/receiving-no-subject-alternative-names-matching-ip-address-when-using-wildcard-cert-in-es-5-0-2-cluster/69322/10 "2016-12-19T18:41:50Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\
**Post date:** [January 16, 2017, 6:41pm UTC](https://discuss.elastic.co/t/receiving-no-subject-alternative-names-matching-ip-address-when-using-wildcard-cert-in-es-5-0-2-cluster/69322/11 "2017-01-16T18:41:53Z")

</div>

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