Certificate might nog have been added to the log?

stevenvolckaert · March 27, 2023, 7:31am

I've been using Let's Encrypt with Posh-ACME for several years (currently version 4.17.0), to issue X.509 certicates to enable HTTPS for our customers websites.

This morning, I requested a certificate for 'vastgoeddemeyer.be' (and 'www.vastgoeddemeyer.be' in the SAN list), which succeeded without any errors.

Surfing to this website however, produces a NET::ERR_CERTIFICATE_TRANSPARENCY_REQUIRED error; see below.

I tried this in:

Google Chrome 111.0.5563.111 (Official Build) (64-bit) (cohort: Stable)
Microsoft Edge 111.0.1661.54 (Official build) (64-bit)

After this I went back to the previous certificate for this website, which is still valid for some time.

When I search crt.sh, the new certificate isn't found:

The old (currently in use) certificate: SHA-1 thumbprint '204cf6646540a59c2ac17634a13a7eabe342f9a4'
The new certificate: SHA-1 thumbprint '4899B241C2EE5254ED57C48C89EEE19772258488'

Any ideas what could have gone wrong here? Could it be possible that the new certicate wasn't written to the log somehow?

Thank you for your help!

Steven Volckaert

_az · March 27, 2023, 8:09am

Can you post the PEM of that certificate? I don't see it in Censys either, which is usually pretty quick the aggregate the logs.

I only see these:

stevenvolckaert · March 27, 2023, 9:15am

Posh-ACME stores certificates in the CER format and I would have to do some research to convert this to the PEM format. I tried attaching the certificate's full chain (fullchain.cer) to this message, but the file format isn't allowed.

You can find the full chain of certificate 4899B241C2EE5254ED57C48C89EEE19772258488 below, does this help?

If you do require the file in the PEM format, then any pointers on how to convert CER to PEM on Windows Server (e.g. with PowerShell) would be very helpful.

Full certificate chain of certificate 4899B241C2EE5254ED57C48C89EEE19772258488 for [www.]vastgoeddemeyer.be:

orangepizza · March 27, 2023, 9:16am

could you open advanced button on the error page?, those will print more verbose error in there

_az · March 27, 2023, 11:21am

The certificate is fine and has correct SCTs in it. I think it's probably impossible for Let's Encrypt to issue a certificate that hasn't been logged - the order finalization should fail.

I think we have occasionally seen users report this problem with brand new certificates on some platforms. I have a theory that it happens when the system clock is slightly behind and the OS observes an SCT "from the future" (because SCTs are not backdated by an hour, like the certificate validity period is).

I think Chrome on Windows uses the operating system's native SSL validator. You could try clearing the SSL state and seeing whether that makes a difference with the certificate in question.

stevenvolckaert · March 27, 2023, 12:58pm

I confirm certificate 4899B241C2EE5254ED57C48C89EEE19772258488 for [www.]vastgoeddemeyer.be works. Clearing SSL state wasn't necessary.

Thank you @_az for your analysis and help!

I now suspect the issue was caused by the system time not being up-to-date: A time change due to Daylight Saving Time occurred on Sunday 26 March 2023 02:00 (becoming 03:00), and the time on my PC might not have been in sync when I did the test: It was likely still on the old time (CET / UTC+1) while the certificate was issued on the new time (CEST / UTC+2), which indeed caused my PC to observe a certificate issued in the future.

system · April 26, 2023, 12:58pm

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