with AWS with CentOS here too! if you can help me please:
how did you know your DST Root CA X3 certificate? where it was located?
you remove it manually from chain.pem and fullchain.pem ?
i'm stuck, as https://chainchecker.certifytheweb.com/ says "Let's Encrypt Modern Chain" (i understand is fine) and my browser can see the page with no problems, BUT when I execute
Hi @punchi,
what's happening is that your certificate chain (or, the server's CA chains, still have the cross-signed X3 CA registered as an active CA). You need to manually disable the X3 CA so your server stops sending it out. In my case, I had an MQTT server that relied on the built-in CA chains in the operating system (AWS Linux). The MQTT server had both the full chain in it's cert file and the OS had the CA listed as active. I have no idea if that would change over time but in the short term, it was causing the MQTT server to send out the work root CA (X3).
The MQTT servers' .pem file had four certificates, the server cert, the R3 cert, the ISRG X1 cert, and the DST Root X3 cert. You can see the X3 cert in my original post. It would most likely suffice for you to copy and paste it into a file as I had mentioned in my earlier post and then update the ca trust file. I removed the cert from the .pem chain file as an extra precaution. If you are having this issue with a web server, the certificate location will be listed in the config file (typically /etc/nginx/sites/available/sitename.com for Nginx and /etc/httpd/sites-available/sitename.conf or /etc/apache2/sites-available/sitename.conf for Apache although it will vary by installation).
you could also do a
sudo find /etc -type f -name "*.pem"
or
sudo find /etc -type f -name "*.crt"
to locate any .crt or .pem files in /etc
Let me know if you are still stuck and the configuration you are trying to get working again and I'll see what help I can be.
@jsha@frsp1@rg305 anyone knows how to rip off the Path #2 ?? there's no DST Root CA X3 here /etc/letsencrypt/live/gesnex.com/fullchain.pem where it can be located this path 2?
Let me explain that a bit (there is no way to remove it - a valid path will always be known/found).
The last cert in each always ends with "in trust store".
Those certs should never be sent by a server - they are to be found in the root stores that we all trust.
So,, what's the difference between path #1 and #2? They both start exactly the same:
Certs 1 & 2 are identical in both paths (same serial #).
but cert 3 is different (same name but different serial numbers)
Path #1 cert 3 is in the root store (so it will always be known)
Path #2 cert 3 is NOT in the root store and is known (so it must have been sent by the server)
It is that cert that ties the chain to the EXPIRED root cert.
If you want to "break" that path, you need only remove one link from that chain.
1 & 2 must be sent to complete path #1 and 4 is already in the root trust store...
So that only leaves the removal of 3.
If you want to "break" path #2, then don't send path #2 cert 3 "ISRG Root X1 (cross-signed)".
Without the hints, only systems that have cached it would likely ever try to use it.
[thus the need to delete it from stores and even memory (reboots are sometimes required)]
@punchi Check your openssl version. If it is 1.0.2k like in AWS Linux 1 and 2 then that version needs the -trusted_first option so it behaves like openssl version 1.1.
Example:
openssl s_client -connect community.letsencrypt.org:443 -servername community.letsencrypt.org -trusted_first
CONNECTED(00000003)
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = community.letsencrypt.org
verify return:1
---
Certificate chain
0 s:/CN=community.letsencrypt.org
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
Without -trusted_first, a chain with DST Root CA X3 will cause openssl to show an expiration error like this:
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
thanks for the nice explanation @rg305 !! but now how can I stop sending the ISRG Root X1, fingerprint SHA256: 6d99fb265eb1c5b3744765fcbc648f3cd8e1bffafdc4c2f99b9d47cf7ff1c24f ?? where is located?
That depends on the ACME client used.
Usually with some form of fullchain file.
The simplest/fastest way is to find that current file and manually edit it - remove the last cert from within it and then restart your web service.
NOTE: This "workaround" (not permanent fix) will last until the next renewal (automatic replacement of that fullchain file).
but now how can I stop sending the ISRG Root X1, fingerprint SHA256: 6d99fb265eb1c5b3744765fcbc648f3cd8e1bffafdc4c2f99b9d47cf7ff1c24f ?? where is located?