At this point, if I had to guess…
I would say that your system is negotiating via one of the WEAK TLSv1.2 ciphers.
Which means it is unable to do:
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ( 0xc02f )
Please confirm if your system supports that cipher.
[yes, the server cipher ordering could be improved]
Chrome is using these ciphers (on my Mac at least) when connecting;
community.letsencrypt.org: TLS 1.3, X25519, and AES_128_GCM (working)
letsencrypt.org: TLS 1.3, X25519, and AES_256_GCM (not working)
www.finn.no: TLS 1.2, ECDHE_RSA, and AES_128_GCM (not working)
fn.is: TLS 1.2, ECDHE_RSA with P-384, and AES_256_GCM (working)
Try:
drop support for: TLS 1.3, X25519, and AES_256_GCM
[just for testing]
There is no way (that I know of) to drop a specific cipher in Chrome anymore; the "--cipher-suite-blacklist" is no longer available and/or you cannot block "whatever you want" (see https://bugs.chromium.org/p/chromium/issues/detail?id=58831). Starting Chrome with "open /Applications/Google\ Chrome.app --args --cipher-suite-blacklist=0x1302" did not work (0x1302 = TLS_AES_256_GCM_SHA384).
OK, working on test sites for 1301, 1302, and 1303.
Waiting for DNS to sync…
Tested on fn.is having working LE certificates, and set TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as the only cipher on the server (same as being selected on www.finn.no, that does not work). I also set the same ECHD curve (prime256v1) as www.finn.no.
According to ssllabs.com they are now equal;
www.finn.no: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ( 0xc02f ) ECDH secp256r1 (eq. 3072 bits RSA) FS 128
fn.is: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ( 0xc02f ) ECDH secp256r1 (eq. 3072 bits RSA) FS 128
However, Chrome detects them as different (even though ssllabs.com identifies them as equal);
www.finn.no: TLS 1.2, ECDHE_RSA, and AES_128_GCM.
fn.is: TLS 1.2, ECDHE_RSA with P-256, and AES_128_GCM.
fn.is works just fine after the changes (but www.finn.no does not).
(I tested with www.finn.no because it’s running TLSv1.2, and not 1.3 as letsencrypt.org does, to get equal testing parameters).
I guess that “Netlify” and “nginx” aren’t doing the same exact things…
I’ll PM you with the test sites.
OK, started looking at random websites using LE, and found a site that Chrome uses the same ciphers as letsencrypt.org, that works without issues (in both Chrome and Safari);
letsencrypt.org: TLS 1.3, X25519, and AES_256_GCM (not working).
www.click2houston.com: TLS 1.3, X25519, and AES_256_GCM (working).
They are also confirmed to both use the same ciphers via curl (“SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384”).
I think we are back to when the LE certificates are issued?
Does Safari or something show the Certificate Transparency information for the certificates? To be precise, the two embedded SCTs?
Some or all of the newer certificates you’ve mentioned have embedded SCTs from a newer log – coincidentally, the Oak log run by Let’s Encrypt.
Oak has only been Usable in Google Chrome since version 80, which was released in February, so Let’s Encrypt only started embedding SCTs from it recently.
(Let’s Encrypt uses a number of CT logs. Different certificates may have SCTs from different ones, even if they were issued around the same time.)
However, it has apparently been Usable in Apple’s CT implementation since December 2.
And I believe enforcement is designed to fail open – even if macOS somehow fails to update the list of supported logs for months, I believe it will disable enforcement, not reject good certificates.
I’m proposing this as a theory, but it should not be possible for it to go wrong.
Is there any documentation of what that error message means…?
OK, it’s not the dates either;
Working:
www.basketball-reference.com (issued 2020-02-14), TLS 1.2, ECDHE_RSA with P-256, and AES_128_GCM.
support.buzzfeednews.com (issued 2020-03-12), TLS 1.3, X25519, and AES_128_GCM.
www.cbr.com (issued 2020-03-10), TLS 1.2, ECDHE_RSA with P-256, and AES_128_GCM.
www.click2houston.com (issued 2020-03-18), TLS 1.3, X25519, and AES_256_GCM.
app.clutchpoints.com (issued 2020-02-18), TLS 1.2, ECDHE_RSA with X25519, and AES_128_GCM.
Not working:
support.coursehero.com (issued 2020-02-12), TLS 1.2, ECDHE_RSA, and AES_128_GCM.
www.trend-chaser.com (issued 2020-03-06), TLS 1.2, ECDHE_RSA, and AES_256_GCM.
www.finn.no (issued 2020-02-27), TLS 1.2, ECDHE_RSA, and AES_128_GCM.
letsencrypt.org (issued 2020-03-07), TLS 1.3, X25519, and AES_256_GCM.
Yes, it looks like it (just one);
Firefox has the same one (where it works), but has one additional one (?) with same timestamp?
No, but all discussions I've seen online leads back to Apple's Certificate Transparency policy - Apple Support .
Let’s Encrypt certificates have two SCTs, unless there is a bug or misconfiguration with the CA software. (The details vary, but browsers and OSes require websites use at least two.)
The letsencrypt.org certificate certainly does have two: https://crt.sh/?id=2559799947
They will both have timestamps that are about the same – probably milliseconds apart, but Firefox apparently doesn’t show that precision – because Let’s Encrypt gets them simultaneously while issuing the certificate.
It seems suspicious that your Firefox installation shows the name of the second log (Google Xenon) but not the name of the Let’s Encrypt Oak log, suggesting that it doesn’t recognize it.
Edit: Your Safari is also showing the Oak log without a name, but I don’t know if that’s normal.
I checked the certificates on the “working” vs “not working” list I made above, and you are right; every one that fails, has the Oak log.
The question is; why does it work for the certificates that does not have the Oak log? They are also only showing up with one of the SCTs when inspecting the certificate (same as the non-working ones from Oak).
Presumably because the browsers that are not recognising the certificate do not trust Oak as a qualified log for the purposes of satisfying the requirement that all certificates have at least two valid SCTs in order to be considered trusted.
So, a new security update was released, which fixed the problem.
This update (from late January 2020) broke it; https://support.apple.com/en-gb/HT210919
This update (from late March 2020) fixed it; https://support.apple.com/en-gb/HT211100
No other changes was done on my system.
That’s ridiculous, but I’m glad it’s fixed!
Maybe the January update accidentally reverted to a pre-December version of the CT list? If I remember correctly, that has sometimes happened to other things.
Latest update did not solve it after all. It apparently works for some time after a reboot, and then stops working. I’m not alone anymore either; macOS + Safari certificate weirdness
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
