# ECE 2.0.1 Unable to upload Letsencrypt TLS certificate

**URL:** <https://discuss.elastic.co/t/ece-2-0-1-unable-to-upload-letsencrypt-tls-certificate/158802>\
**Category:** Elastic Cloud Enterprise (ECE)\
**Created:** [November 29, 2018, 5:28pm UTC](https://discuss.elastic.co/t/ece-2-0-1-unable-to-upload-letsencrypt-tls-certificate/158802 "2018-11-29T17:28:42Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![cmoi](https://avatars.discourse-cdn.com/v4/letter/c/8c91f0/32.png) [@cmoi](https://discuss.elastic.co/u/cmoi)\
**Post date:** [November 29, 2018, 5:28pm UTC](https://discuss.elastic.co/t/ece-2-0-1-unable-to-upload-letsencrypt-tls-certificate/158802/1 "2018-11-29T17:28:42Z")

</div>

Hi,

I am unable to install a certificate signed by Letsencrypt as a TLS certificate neither for Proxy or Cloud UI and get this error:

Certificate chain was invalid [Path does not chain with any of the trust anchors]

Could it be because the docker images use an OpenJDK version that does not include the root certificate needed to trust letsencrypt certificate ?

I thought it could be a similar issue, but with letsencrypt certificates, to this one : [https://github.com/elastic/elasticsearch-docker/issues/171](https://github.com/elastic/elasticsearch-docker/issues/171)

Is it possible to add support to letsencrypt certificate on ECE 2 ?

Thanks for your help.

---

<div class="post-metadata">

**Author:** ![Alex\_Piggott](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/alex_piggott/32/11053_2.png) [@Alex\_Piggott](https://discuss.elastic.co/u/Alex_Piggott)\
**Post date:** [November 29, 2018, 6:40pm UTC](https://discuss.elastic.co/t/ece-2-0-1-unable-to-upload-letsencrypt-tls-certificate/158802/2 "2018-11-29T18:40:20Z")

</div>

Are you definitely including the cert chain including the CAs in the upload? See [https://www.elastic.co/guide/en/cloud-enterprise/current/ece-manage-certificates.html#ece-before\_you\_begin\_7](https://www.elastic.co/guide/en/cloud-enterprise/current/ece-manage-certificates.html#ece-before_you_begin_7)

I thought we did support arbitrary cert chains for the proxy/cloud UI. I'll have a dig around if the above isn't the issue

Alex

---

<div class="post-metadata">

**Author:** ![cmoi](https://avatars.discourse-cdn.com/v4/letter/c/8c91f0/32.png) [@cmoi](https://discuss.elastic.co/u/cmoi)\
**Post date:** [November 29, 2018, 7:59pm UTC](https://discuss.elastic.co/t/ece-2-0-1-unable-to-upload-letsencrypt-tls-certificate/158802/3 "2018-11-29T19:59:45Z")

</div>

Hi Alex,

Letsencrypt gives me a privkey.pem file that i convert to rsa this way : openssl rsa -in privkey.pem -out rsaprivkey.pem

Then i concatenate this rsa key with the fullchain.pem generated by letsencrypt wich includes the certificate and the chain certificate.

When i upload this file through the GUI i get the error.

---

<div class="post-metadata">

**Author:** ![Alex\_Piggott](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/alex_piggott/32/11053_2.png) [@Alex\_Piggott](https://discuss.elastic.co/u/Alex_Piggott)\
**Post date:** [November 29, 2018, 8:18pm UTC](https://discuss.elastic.co/t/ece-2-0-1-unable-to-upload-letsencrypt-tls-certificate/158802/4 "2018-11-29T20:18:41Z")

</div>

Despite its name, I'm not convinced `fullchain.pem` includes the CA cert, can you double check? If not, try converting/`cat`ing that in

Otherwise you should be able to use `openssl` to verify the combined PEM is valid (or if not, what's wrong with it), eg:

Let's assume the following values are set:

```auto
SRV_KEY=[path to server RSA key]
SRV_CERT=[path to server X509 cert]
INTER_CERT=[path to intermediate CA X509 cert]
CA_CERT=[path to CA X509 cert]
CHAIN=[path to certificate chain, eg cat $SRV_KEY $SRV_CERT $INTER_CERT $CA_CERT > $CHAIN]

```

To verify the server key matches the cert (eg to avoid `[Key Mismatch: public key in server certificate doesn't match public key part of PKCS1 RSA private key]`), run:

```auto
openssl rsa -noout -modulus -in ${SRV_KEY} | openssl sha256
> (stdin)= 3da7dff874ae18e4529667339ada88e9ef17adb793cff6cf92f500e09af72879

openssl x509 -noout -modulus -in ${SRV_CERT} | openssl sha256
> (stdin)= 3da7dff874ae18e4529667339ada88e9ef17adb793cff6cf92f500e09af72879

```

And make sure the two outputs match (this will be a value other than `3da7dff...` for your cert and key).

To check that the cert chain is valid, run:

```auto
openssl verify -CAfile ${CA_CERT} -untrusted ${INTER_CERT} ${CHAIN}

> ${CHAIN}: OK

```

To debug an invalid cert chain, grab the subject and issuer for each cert and make sure they match the next cert:  
The **issuer** for the server cert (`issuer=C = US, ST = California, O = Stu Test, CN = Stu Test Intermediate CA`)...

```auto
openssl x509 -subject -issuer -noout -in ${SRV_CERT}

> subject=CN = *.stu.example.com
> issuer=C = US, ST = California, O = Stu Test, CN = Stu Test Intermediate CA

```

...should match the **subject** for the intermediate cert (`subject=C = US, ST = California, O = Stu Test, CN = Stu Test Intermediate CA`).

Next, the **issuer** (`issuer=C = US, ST = California, O = Stu Test, CN = Stu Test CA`) for the **intermediate cert**...

```auto
openssl x509 -subject -issuer -noout -in ${INTER_CERT}

> subject=C = US, ST = California, O = Stu Test, CN = Stu Test Intermediate CA
> issuer=C = US, ST = California, O = Stu Test, CN = Stu Test CA

```

...should match the **subject** for the **CA cert**.

```auto
openssl x509 -subject -issuer -noout -in ${CA_CERT}

> subject=C = US, ST = California, O = Stu Test, CN = Stu Test CA
> issuer=C = US, ST = California, O = Stu Test, CN = Stu Test CA

```

CA certs are self signed, so the subject is the issuer.

---

<div class="post-metadata">

**Author:** ![cmoi](https://avatars.discourse-cdn.com/v4/letter/c/8c91f0/32.png) [@cmoi](https://discuss.elastic.co/u/cmoi)\
**Post date:** [November 29, 2018, 10:04pm UTC](https://discuss.elastic.co/t/ece-2-0-1-unable-to-upload-letsencrypt-tls-certificate/158802/5 "2018-11-29T22:04:20Z")

</div>

Hi Alex,

Thank you for the tips on checking the certificate.

The commands `openssl rsa -noout -modulus -in ${SRV_KEY} | openssl sha256` and `openssl x509 -noout -modulus -in ${SRV_CERT} | openssl sha256` returned the same string.

I do not have an `$INTER_CERT` maybe it is the issue.

The fullchain.pem file content is cert.pem concatenated with chain.pem. rsaconcat2.pem is the previously rsaprickey.pem concatenated with fullchain.pem.

The command verify gives me:

> openssl verify -CAfile chain.pem rsaconcat2.pem  
> rsaconcat2.pem: OK

The subject and issuer gives me (I just edited [mydomain.com](http://mydomain.com)):

> openssl x509 -subject -issuer -noout -in cert.pem  
> subject= /CN=\*.ece.mydomain.com  
> issuer= /C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3

> openssl x509 -subject -issuer -noout -in chain.pem  
> subject= /C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3  
> issuer= /O=Digital Signature Trust Co./CN=DST Root CA X3

Should I search for the DST Root CA X3 certificate and add it to the end of the chain ?

You can find more information on the letsencrypt certificate structure here : [Chain of Trust - Let's Encrypt](https://letsencrypt.org/certificates/)

---

<div class="post-metadata">

**Author:** ![Alex\_Piggott](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/alex_piggott/32/11053_2.png) [@Alex\_Piggott](https://discuss.elastic.co/u/Alex_Piggott)\
**Post date:** [November 30, 2018, 2:59pm UTC](https://discuss.elastic.co/t/ece-2-0-1-unable-to-upload-letsencrypt-tls-certificate/158802/6 "2018-11-30T14:59:36Z")

</div>

Yep, you need a CA at the end, where the subject is the issuer

Alex

---

<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:** [December 14, 2018, 2:59pm UTC](https://discuss.elastic.co/t/ece-2-0-1-unable-to-upload-letsencrypt-tls-certificate/158802/7 "2018-12-14T14:59:43Z")

</div>

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