After renew certificate, some applications didn't trust anymore

[tdeuling]

Hi,
I renew my certificate and now some applications didn’t trust the certificate.
Firefox and Chrome on Linux works fine.
Chrome on Android Tablet throws a NET::ERR_CERT_AUTHORITY_INVALID
Thunderbird on Linux throws a 'the certificate is not trusted because it hasn’t been verified as issued by a trusted authority’
My OwnCloud-Client throws: The issuer certificate of a locally looked up certificate could not be found
No certificates could be verified

What could be the problem. Before renewing everythings worked fine…

[ahaw021]

hi @tdeuling

Please fill out the fields below so we can help you better.

My domain is:

I ran this command:

It produced this output:

My operating system is (include version):

My web server is (include version):

My hosting provider, if applicable, is:

I can login to a root shell on my machine (yes or no, or I don’t know):

I’m using a control panel to manage my site (no, or provide the name and version of the control panel):

[tdeuling]

My domain is: cloud.coding.ms

I ran this command: ./certbot-auto certonly --standalone --rsa-key-size 4096 -d cloud.coding.ms
-> Because it didn’t work, I’d performed some updates and run it again!

It produced this output:
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Cert not yet due for renewal

You have an existing certificate that has exactly the same domains or certificate name you requested and isn’t close to expiry.
(ref: /etc/letsencrypt/renewal/cloud.coding.ms.conf)

What would you like to do?

1: Keep the existing certificate for now
2: Renew & replace the cert (limit ~5 per 7 days)

Select the appropriate number [1-2] then [enter] (press ‘c’ to cancel): 2
Renewing an existing certificate
Performing the following challenges:
tls-sni-01 challenge for cloud.coding.ms
Waiting for verification…
Cleaning up challenges
Generating key (4096 bits): /etc/letsencrypt/keys/0003_key-certbot.pem
Creating CSR: /etc/letsencrypt/csr/0003_csr-certbot.pem

My operating system is (include version): Linux Debian-77-wheezy-64-minimal 3.16.0-4-amd64 #1 SMP Debian 3.16.36-1+deb8u2 (2016-10-19) x86_64 GNU/Linux

My web server is (include version): Apache/2.4.10 (Debian)

My hosting provider, if applicable, is: self hosted

I can login to a root shell on my machine (yes or no, or I don’t know): yes, root

I’m using a control panel to manage my site (no, or provide the name and version of the control panel): no control panel

[ahaw021]

hi @tdeuling

you are not serving up an intermediate certificate which is why some browsers trust your site and some don’t

certain browsers have whats called a certificate bundle (that includes LetsEncrypt) other browsers rely on the web server to serve these up

you can confirm this with the test site SSLLabs: https://www.ssllabs.com/ssltest/analyze.html?d=cloud.coding.ms&latest

To fix this please refer to Mozilla Guide on TLS configs

https://mozilla.github.io/server-side-tls/ssl-config-generator/

you are using certbot so that means you should be able to point apache to your live folder

NOTE: i use windows so the location is different but the concept is the same

for each domain there is a symlink under \etc\letsencrypt\live to which you can point your apache config

don’t forget to also restart the apache server for the new certificates to be loaded

[tdeuling]

@ahaw021 thanks for your reply.
I’m not sure what to do.
My Apache is already pointing to the live files:

SSLEngine on
SSLCertificateFile /etc/letsencrypt/live/cloud.coding.ms/cert.pem
SSLCertificateKeyFile /etc/letsencrypt/live/cloud.coding.ms/privkey.pem

…and the live files are symlinks on:

/etc/letsencrypt/live/cloud.coding.ms # ls -l 
lrwxrwxrwx 1 root root 39 Mar 23 09:57 cert.pem -> ../../archive/cloud.coding.ms/cert3.pem
lrwxrwxrwx 1 root root 40 Mar 23 09:57 chain.pem -> ../../archive/cloud.coding.ms/chain3.pem
lrwxrwxrwx 1 root root 44 Mar 23 09:57 fullchain.pem -> ../../archive/cloud.coding.ms/fullchain3.pem
lrwxrwxrwx 1 root root 42 Mar 23 09:57 privkey.pem -> ../../archive/cloud.coding.ms/privkey3.pem

[ahaw021]

hi @tdeuling

you should have reviewed your config vs the mozilla tls suggested config (that is why the link was posted)

you are missing a statement in your apache config

SSLCertificateChainFile /path/to/intermediate_certificate

add this statement and point to the correct file (chain.pem)

restart the apache server and you should be all good

Andrei

[tdeuling]

Args, sorry. I’d remove that row, because the Apache config test told me:

The SSLCertificateChainFile directive (/etc/apache2/sites-enabled/default-ssl.conf:46) is deprecated, 
SSLCertificateFile should be used instead

And additionally, your ssl-config-generator suggested me:

SSLCertificateFile      /path/to/signed_certificate_followed_by_intermediate_certs
SSLCertificateKeyFile   /path/to/private/key

# Uncomment the following directive when using client certificate authentication
#SSLCACertificateFile    /path/to/ca_certs_for_client_authentication

There were not the SSLCertificateChainFile row…

Anyway, now it works - my configuration looks like:

SSLCertificateFile /etc/letsencrypt/live/cloud.coding.ms/cert.pem
SSLCertificateChainFile /etc/letsencrypt/live/cloud.coding.ms/chain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/cloud.coding.ms/privkey.pem

[Osiris]

If your Apache version is 2.4.8 or above, SSLCertificateChainFile is indeed deprecated and shouldn’t be used.

But…!

As the Mozilla Generator also signals, you should point SSLCertificateFile to the server certificate AND the intermediate certificate in one file.

certbot provides a solution for you with fullchain.pem (which is cert.pem and chain.pem concatenated in one file, just like Apache needs).

So, change cert.pem to fullchain.pem and remove the SSLCertificateChainFile directive. Reload/restart Apache and you’re good to go.

[tdeuling]

Great! That works for me.
Thanks a lot.