Hi everyone, I’m going to preface this that I am a complete n00b to all this and when I read these posts it seems like a different language.
I tried accessing some websites on my MacBook Pro running version 10.11.6 via Google chrome and getting the NET::ERR_DATE_INVALID stating my connection is not private on various websites. In this example, I am trying to access
opensea.io
.
image
1920×2560 490 KB
If someone could explain some step by step instructions how to resolve this then it would be very appreciated. As the great Michael Scott once said, “Why don’t you explain this to me like I am five”.
The
opensea.io
site appears to be configured correctly according to Let's Encrypt's current recommendations.
The evidence is building up that some versions of macOS may have an unexpected incompatibility with a workaround that Let's Encrypt recommended for what would have been an incompatibility with older Android devices. If this is confirmed, it means that sites that choose the Android compatibility option will be incompatible with some macOS versions, while sites that choose the macOS compatibility option will be incompatible with some Android versions.
Right now, it appears that this is something that would have to be fixed by the site operator, or by Apple, not by you. A temporary workaround might be to use Firefox to access these specific sites, because it uses its own trust store and certificate validation rather than those provided by the operating system.
The most detailed discussion of this issue on this forum is at
Certificate Compatibility - Let's Encrypt
indicates that macOS >= 10.12.1 trusts ISRG Root X1, however I am getting errors in Safari and Google Chrome even though I am running MacOS 10.14.6 (Mojave). Is there something I need to do to get MacOS 10.14.6 to trust LetsEncrypt certificates?
Also, if so many people are having problems, is there some reason you can't just renew the DST Root CA X3” certificate?
herbw:
Also, if so many people are having problems, is there some reason you can't just renew the DST Root CA X3” certificate?
Root certificates are built into operating systems (or sometimes web browsers), rather than issued by some other authority. Their inclusion in the software reflects a real-world trust relationship between the software developer—on behalf of the end users—and the certificate subject, which is a trusted root CA that has agreed to follow various rules and policies, and is audited to ensure compliance with them.
Because the root CAs are effective only by virtue of their inclusion in software, there's no way to remotely replace them without help from whoever can update that software (for example, an OS developer).
This is different from end-entity certificates, which have an
issuer
who has digitally signed them to confirm that their contents are correct. "Renewal" of these other digital certificates means replacing them with an updated version, newly signed by (typically) the same issuer. That replacement can be done in response to a request by the individual computer that's identified by the certificate, and it can then be installed there.
For end-entity certificates, we get the current version by downloading it from a server when establishing a TLS connection to the server. For root certificates, they have to be built-in to the software
or delivered by a trusted update mechanism directly from the software developer, as in the case of Microsoft Windows
. Without that, an update to a root certificate would be meaningless because software would simply have no way to decide whether it was legitimate, as well as, in most cases, no way to hear about the existence of the purported update!
Identrust, which owns the DST X3 Root CA, could prepare a new root certificate that states that this root will remain in use for a longer period of time, but unless that new version gets installed into trusted root stores in individual users' devices, it would simply have no effect. Also, the expiration dates for roots are (in one theory, which is maybe a bit debated) meant to encourage people to periodically switch to new roots in case there's an unknown attack or leak related to older roots, like a malicious CA insider or spy, or a software flaw in the CA implementation that sometimes leaks part of the secret key, or something. So although it's very inconvenient, especially because it's not really coordinated with other software lifecycles at all, the periodic expiration of root certificates is arguably beneficial in some ways.
Today is the 22nd birthday of the DST X3 root certificate, which is a pretty long period of time during which various people could have tried to obtain the secret key somehow. Spy agencies would love to have it because they could use it for all kinds of mischief (especially prior to the introduction of the Certificate Transparency system). They probably haven't succeeded, but 22 years is a fairly long time!
How can I help you?
FYI: That is the same cert trust path that this forum is using.
openssl s_client -connect community.letsencrypt.org:443 -servername community.letsencrypt.org
CONNECTED(00000005)
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
[which was put their to ensure that older Android devices would still have access]
Certbot issues a fullchain pem which will not verify
$ openssl verify -CAfile fullchain.pem fullchain.pem
fullchain.pem: O = Digital Signature Trust Co., CN = DST Root CA X3
error 10 at 1 depth lookup:certificate has expired
O = Digital Signature Trust Co., CN = DST Root CA X3
error 10 at 3 depth lookup:certificate has expired
The last cert in fullchain.pem is the ISRG Root X1 cert issued by the expired DST Root CA X3, so verify will always fail unless it is removed from fullchain.pem.
I think certbot should not be appending it to fullchain.pem, or you issue a note to not serve fullchain.pem by nginx or apache etc.
Or suggest a way where fullchain.pem can be verified in an automated fashion (e.g. in CI) using opensssl which works with all other certs, otherwise CI scripts (or monitoring scripts) that use openssl verify have to add a letsencrypt exception
I use both nginx and Apache and they have no trouble serving that trust path.
Your client is the one with the "problem".
As shown above, even this forum serves that exact same fullchain,pem:
openssl s_client -connect community.letsencrypt.org:443 -servername community.letsencrypt.org
CONNECTED(00000005)
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
And if you use openssl verify -CAfile fullchain.pem fullchain.pem on the response, it will tell you the last cert has expired, and shows an error.
We use openssl verify in CI (and in monitoring) to detect bad/expired certs. Is there a better one liner?
This is now a know problem that the entire Internet is working on.
There are some workarounds.
I think one is to use -trusted_first
I would also try using -partial_chain
And, of course, to update/patch the OpenSSL.
Apparently it's a problem with browsers caching the old R3 certificate. It seems to me that as long as it's there a browser may or may not use it.
I'm using several Let's Encrypt certificates and when viewed on the latest Chrome (MacOS 10.13) most of them work and display ISGR, but some don't and display R3 (I just updated one of these and it didn't improve the situation).
Have latest openssl on linux, but -partial_chain seems to work. thank you!
Yes, ca.cer contains it too. I even forced cert renewal (I use acme.sh) but it's still there. Why would Let's encrypt include there a CA cert signed by an expired root CA?? As long as the client has that expired root CA in their trust and the server sends that useless intermediate cert, that makes it fail in some software. I checked on Debian Stretch for example - funnily enough curl would not even connect to Let's encrypt own API and acme.sh won't renew any cert unless you stop trusting DST Root CA X3.
We're still getting reports from some clients that they can't connect. In those cases Chrome on Windows 7 does not get the new root cert. Our cert path ist X1 -> R3 -> Our Cert (short). Of course it is not possible to install the cert manually on every client and the fear is that clients can't connect that don't contact us with the problem. Is there any other solution? Why is this not a bigger issue?
herbw: