Certificate information shows DST Root CA X3 -> R3 issued the certificate, and I have never encountered this error before. If anyone knows why this is happening, help is much appreciated! Thanks!
AIUI what you've described shouldn't happen because Chrome has a concept of "timely" information, after about two months without updates it concludes it is unable to be certain about the status of SCTs and should not use them to make decisions any more.
I see that just a few minutes later, another certificate was issued for the same name, but with different CT logs used to obtain SCTs for that certificate. Certificate serial 04:d6:76:22:8d:d1:15:e1:f6:d3:34:8e:3e:fb:16:dd:29:f8 ("The F8 certificate") is in use on that server now, while 03:7c:0c:3b:20:38:fc:50:05:c5:86:d7:bf:f6:ef:a4:95:1b ("The 1B certificate") was issued some minutes earlier and may be the cause of this forum comment by skyyc
The 1B certificate has SCTs from Let's Encrypt Oak 2021 and Google Xenon 2021. Whereas the F8 certificate has SCTs from DigiCert Yeti 2021 and Google Argon 2021.
Oak 2021 was usable from Chrome M78, Xenon 2021 from Chrome M73, whereas Yeti 2021 has been usable since M67 and Argon 2021 since M65.
It would be interesting to know if Let's Encrypt chooses to obtain SCTs from different logs at random or whatever, or else why different ones were chosen for these issuances.
Still, if the 1B certificate was causing problems for skyyc and the F8 certificate worked, it would definitely be interesting to know which version of Chrome they have installed. @skyyc from the ... menu of your Chrome pick Help -> About Google Chrome and if you would please let us know what it said (Chrome may try to update itself, that's fine, but please let us know what it said before it updated)
As far as I know, Boulder submits the pre-cert to a number of logs (5? I believe?) and the ones that return first, are embedded into the final certificate, taking into account the Google/non-Google rule.
I just updated Chrome and the issue still persists. (Sorry I didn't get the previous version, didn't read the full post). The issues only began after I attempted to issue a Wildcard certificate, which I have done before successfully. Could I have messed up some certbot configuration?
Because Let's Encrypt delivers certificates with SCTs burned inside them, it should not be possible as I understand it for a situation to arise in which you are presenting certificates which aren't acceptable to Chrome due to Certificate Transparency. For what it's worth, on a PC I have with Chrome everything checks out fine for your site. I suspect others in this thread have checked and Chrome likewise works for them on your site.
I don't see any reason to believe Certbot could cause this (many other things could go wrong of course, but not this). I definitely do not recommend trying to issue new certificates for names you've already got certificates for, as at this point that's pretty clearly not the problem. Do other sites all work fine in the same install of Chrome? Maybe a Chrome expert can chime in here with any recommendations for how to diagnose what exactly Chrome thinks went wrong (it is possible that "Advanced" button is helpful, but it's also possible it just has some generic blurb with no details at all)
Previously we managed to chase down one of these errors and it came down to a "bug" of sorts in the handling of SCT timetamps, when accessing a site that had a very recently renewed Let's Encrypt certificate in Chrome on macOS.
OK so this feels like a Chrome bug, possibly with a sprinkle of "Your clock isn't quite set correctly" for @skyyc but maybe not. I wonder what the best way to get somebody from Chrome's team to look at it would be? Maybe Ryan Sleevi?
.