Error with certificate transparency on recently issued certificate

My domain is:

I ran this command: certbot certonly -d

It produced this output: Command ran successfully

My web server is (include version): Apache2 (latest)

The operating system my web server runs on is (include version): Ubuntu 18.04

My hosting provider, if applicable, is: None

I can login to a root shell on my machine (yes or no, or I don't know): Yes

I'm using a control panel to manage my site (no, or provide the name and version of the control panel): No

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): certbot 0.31.0

Hi, I recently obtained a certificate using certbot for the domain, however, when navigating to the site on Chrome, it errors with

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!

1 Like

Hi @skyyc,

Is it possible that your copy of Chrome is out of date? I would think this error could be a result of having a very old version of Chrome.

1 Like

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)

1 Like

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.

1 Like

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?

1 Like

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)

1 Like

Every site I normally use seem to all work fine. Aaaand as I write this it starts working. :man_facepalming:

1 Like

@skyyc that error screenshot, is it from macOS?

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.

I have been trying to chase this problem down for a long time :laughing:.


The screenshot is from Windows.

1 Like

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?


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