30 September 2021 - Help for NGINX/CERTBOT that is already serving fullchain.pem as ssl_certificate

I took the liberty of opening a new thread specifically for us that are using NGINX. The other two threads are becoming very busy with a myriad of web servers/OS and I think that creating a specific topic for might help navigating specially during an "emergency".

What I could gather from reading a lot of posts is that you must make sure that, in your nginx configuration, you have the ssl_certificate directive pointing to your /etc/letsencrypt/live/{{domain}}/fullchain.pem

However, we already have that setting in our nginx.

For OTCP stapling, we also have:

ssl_trusted_certificate /etc/letsencrypt/live/{{ domain }}/chain.pem;

I also assured that we have correct dates in our certificates:

sudo openssl x509 -dates -noout -in cert.pem
notBefore=Sep 11 20:57:45 2021 GMT
notAfter=Dec 10 20:57:44 2021 GMT

sudo openssl x509 -dates -noout -in chain.pem
notBefore=Sep  4 00:00:00 2020 GMT
notAfter=Sep 15 16:00:00 2025 GMT

sudo openssl x509 -dates -noout -in fullchain.pem
notBefore=Sep 11 20:57:45 2021 GMT
notAfter=Dec 10 20:57:44 2021 GMT

However, even with these setup, we have users sending screenshots of Chrome NET::ERR_CERT_DATE_INVALID.

We can't reproduce it ourselves, nor in Chrome/Firefox/Safari (mac Os 10.15) nor in iOS 14.

I find it interesting to report that our status monitoring tool, StatusCake, started reporting errors for Invalid HTTPS certificate yesterday; they had just solved it apparently (https://status.statuscake.com/).

Also, yesterday, we had a bunch of errors from incoming Mandrill/Mailchimp API requests to our application, and they were reporting invalid HTTPS certificate as well; problems solved without us doing anything.

This makes me worried if the solution is actually user-dependent and if there's anything we can do about this at all on our end.

UPDATE: I posted below the result of the openssl s_client -connect which is actually informing of expired certificates.

We do NOT copy certificates from anywhere to anywhere. Certbot generates them in the /etc/letsencrypt/live/domain/ folder, and the nginx configuration points directly there.

As a quick update. On the same machine I can access our website just fine using Chrome/Safari/Firefox, if I try openssl s_client connect I get the message that we have expired certificates:

CONNECTED(00000005)
depth=1 O = Digital Signature Trust Co., CN = DST Root CA X3
verify error:num=10:certificate has expired
notAfter=Sep 30 14:01:15 2021 GMT
verify return:0
depth=1 O = Digital Signature Trust Co., CN = DST Root CA X3
verify error:num=10:certificate has expired
notAfter=Sep 30 14:01:15 2021 GMT
verify return:0
depth=3 O = Digital Signature Trust Co., CN = DST Root CA X3
verify error:num=10:certificate has expired
notAfter=Sep 30 14:01:15 2021 GMT
verify return:0
---
Certificate chain
 0 s:/CN=ourdomain.com
   i:/C=US/O=Let's Encrypt/CN=R3
 1 s:/C=US/O=Let's Encrypt/CN=R3
   i:/C=US/O=Internet Security Research Group/CN=ISRG Root X1
 2 s:/C=US/O=Internet Security Research Group/CN=ISRG Root X1
   i:/O=Digital Signature Trust Co./CN=DST Root CA X3
---
Server certificate

From what we've seen here, Chrome erroring is often because the user's certificate trust store was not updated to include ISRG Root X1. This may be the case on client systems where updates were disabled.

There are numerous threads here talking about either updating or manually installing the root certificate (ISRG Root X1) on Windows/macOS.

Your OpenSSL erroring can be unrelated. Your site is currently serving the Android-compatible chain, which is known to break OpenSSL < 1.1. For OpenSSL 1.0.2, workarounds are available: Old Let’s Encrypt Root Certificate Expiration and OpenSSL 1.0.2 - OpenSSL Blog

You can also switch to serving the shorter chain, which is not Android-compatible, but will fix OpenSSL < 1.1. This (usually) doesn't resolve the Chrome issues however, because ISRG Root X1 must be present in the trust store in any case. There is no way to work around this (except on Android).

2 Likes

@tlforthewin
Thank you for being proactive and trying to overcome the busyness of those other large topics :slight_smile:

This date check only processes the first cert in the file; as shown by the dates of cert.pem and fullchain.pem:

This is to be expected when the TLS libraries used reference a trust store that does not have validity for the entire path. It is not a clear indication of any failure of the server.

In this case, I suspect the OpenSSL version to be less than 1.1 and has yet to be patched.

Again, thanks for this topic; I hope this initiative will be replicate by others as well.
But, in this specific case shown, it seems only indirectly related to nginx and/or certbot.

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