# TSL Transport layer "valid certification path to requested target" **URL:** \ **Category:** Elasticsearch\ **Created:** [June 28, 2018, 10:06pm UTC](https://discuss.elastic.co/t/tsl-transport-layer-valid-certification-path-to-requested-target/137865 "2018-06-28T22:06:54Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![jordo1138](https://avatars.discourse-cdn.com/v4/letter/j/71e660/32.png) [@jordo1138](https://discuss.elastic.co/u/jordo1138)\ **Post date:** [June 28, 2018, 10:06pm UTC](https://discuss.elastic.co/t/tsl-transport-layer-valid-certification-path-to-requested-target/137865/1 "2018-06-28T22:06:55Z")
There are many topics around transport layer tls and fixes etc but the issue I"m running into is on a 3 node cluster ES 6.3 where I have placed the my root ca cert, wild card cert and key in to the /etc/elasticsearch folder on ubuntu 16 and when the transport validation mode is "certificate" i get the error below. when i curl each node for \_xpack/certificates i get the expected result also with the listings of my cert information. When i keep the verification\_mode: none of course the 3 node cluster is up and communicating but i'm stumped as to why the clients don't trust the cert when the mode is certificate level and as far as i understand when using pem format, the path to the ca cert authorities as shown in the yml excerpt below should be good to go any ideas? Thanks, My elasticsearch.yml xpack settings are here: xpack.security.transport.ssl.enabled: true xpack.security.transport.ssl.verification\_mode: certificate xpack.security.transport.ssl.key: /etc/elasticsearch/devops.key xpack.security.transport.ssl.certificate: /etc/elasticsearch/devops.crt xpack.security.transport.ssl.certificate\_authorities: ["/etc/elasticsearch/xxxxxxroot.crt"] Caused by: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target at sun.security.provider.certpath.SunCertPathBuilder.build(SunCertPathBuilder.java:141) ~[?:?] at sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:126) ~[?:?] at java.security.cert.CertPathBuilder.build(CertPathBuilder.java:280) ~[?:1.8.0\_171] at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:392) ~[?:?] at sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:302) ~[?:?] at sun.security.validator.Validator.validate(Validator.java:260) ~[?:?] at sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:324) ~[?:?] at sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:281) ~[?:?] at sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:136) ~[?:?] at ---
**Author:** ![TimV](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/timv/32/13162_2.png) [@TimV](https://discuss.elastic.co/u/TimV)\ **Post date:** [June 29, 2018, 12:39am UTC](https://discuss.elastic.co/t/tsl-transport-layer-valid-certification-path-to-requested-target/137865/2 "2018-06-29T00:39:55Z")
What does the certificate chain look like from `/etc/elasticsearch/xxxxxxroot.crt` to `/etc/elasticsearch/devops.crt` Does the root CA sign it directly, or is it signed by an intermediate CA? Is what you've listed the CA _really_ a root CA (that is, self signed)? If you have access to an openssl binary, can you try: ```auto openssl verify -verbose -CAfile /etc/elasticsearch/xxxxxxroot.crt /etc/elasticsearch/devops.crt ``` The error messages that `openssl verify` gives can be a bit cryptic, but it will at least check whether the trust chain is correct. ---
**Author:** ![jordo1138](https://avatars.discourse-cdn.com/v4/letter/j/71e660/32.png) [@jordo1138](https://discuss.elastic.co/u/jordo1138)\ **Post date:** [June 29, 2018, 1:46am UTC](https://discuss.elastic.co/t/tsl-transport-layer-valid-certification-path-to-requested-target/137865/3 "2018-06-29T01:46:07Z")
Ok, so probly part of the problem... the openssl verify gave out the error below "error 20 at 0 depth lookup:unable to get local issuer certificate" I did a look into it, and it is the CA issued by Comodo where as the devops.crt is by digicert...they were handed to me to use but there could be a breakdown somewhere... I may go back and just use ES6.3 utilities to generate a new set just for the transport layer but my goal was to use our wildcard cert (devops.crt) so that the 3 node hostnames could be \*.devops.X.com Thanks, ---
**Author:** ![TimV](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/timv/32/13162_2.png) [@TimV](https://discuss.elastic.co/u/TimV)\ **Post date:** [June 29, 2018, 3:08am UTC](https://discuss.elastic.co/t/tsl-transport-layer-valid-certification-path-to-requested-target/137865/4 "2018-06-29T03:08:56Z")
> [@jordo1138](#): > > there could be a breakdown somewhere It certainly looks that way. You've got a few options here: 1. You can just pull down the CA that signed the `devops` certificate. If it's from digicert then you should be able to easily get the CA and point to it. However, that does mean that anyone with a digicert certificate can estalbish their identity and be trusted by your cluster. When you configure `xpack.security.transport.ssl.certificate_authorities` you are effectively stating that you are willing to trust all certificates signed by those CAs, and let them join your cluster. You might have added protections at a network level, but the TLS based trust isn't going to help you there. 2. Generate a new CA of your own, and use that to create certificates for the transport layer on your nodes. If you do that, and keep all the keys locked-down & private, then you can generally turn off hostname verification, and you don't need to worry about having a wildcard cert. So it's possible to use a single cert (without any hostname information) for all the nodes. All you could have 1 cert that includes the hostname for all 3 nodes. The trust model for a closed cluster with its own private CA is quite different to the trust model for public websites. For public sites, where it is expected (and largely required) that every site on the internet has access to _some_ certificate from one of the CAs that you trust, then you can't simply rely on that fact that a website has _a_ certificate to establish any sort of trust - because effectively _everyone has a certificate_. So, in that case hostname verification is adding a required check of _"Are you who I **think** you are?"_ But if you have your own private CA, and you are _very_ strict about who you give certificates to (that is, you only give certificates to nodes that are supposed to be in your cluster) and you do a proper job of protecting the private keys for the CA and the node certificates, then the fact that a node has access to a certificate (from your CA) is all you need - that is sufficient to tell you that they are supposed to be part of your cluster. In that case _hostname verification_ adds _some_ minor incremental value in that if someone steals the private key for your cert, then they would also have to do some sort of hostname spoofing to be able to use it, but you need to decide whether that benefit is worth the pain of managing hostnames for your certs and regenerating them if you change hosts. ---
**Author:** ![jordo1138](https://avatars.discourse-cdn.com/v4/letter/j/71e660/32.png) [@jordo1138](https://discuss.elastic.co/u/jordo1138)\ **Post date:** [June 29, 2018, 9:06pm UTC](https://discuss.elastic.co/t/tsl-transport-layer-valid-certification-path-to-requested-target/137865/5 "2018-06-29T21:06:25Z")
Thanks, I'll probably try the ES utilities for generating new CA and certs ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [July 27, 2018, 9:09pm UTC](https://discuss.elastic.co/t/tsl-transport-layer-valid-certification-path-to-requested-target/137865/6 "2018-07-27T21:09:19Z")
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.