How is it possible ? future logging

[mnordhoff]

@Osiris

I did see something strange however on the certificate you first mentioned: it’s logged by the 2020 Oak CT log, but its timestamp is in 2019? I didn’t see it was the 2020 shard of the Oak log before…

Logs are sharded based on when the certificates expire, not when they were issued.

That way e.g. browsers can distrust the 2020 log shards in early 2021 because you know they no longer have any valid certificates.

[Osiris]

Aaah, so that’s the “Window” mentioned on the CT logs page. I thought it was the window the shard was “open for business” in general Good to know!

[cpu]

@Osiris

It looks like it’s the certificate of one of Let’s Encrypts own Certificate Logs systems. Let’s Encrypt can sign their certificates the way they wanted. They themselves are not limited to the specific rules we are. Like, when we want a certificate from Let’s Encrypt, almost everything from the CSR is ignored. We’re getting a certificate with a validity of 90 days from the moment Let’s Encrypt issues it (minus one hour for clock drift I think). However, Let’s Encrypt doesn’t have to apply those rules to themselves. They can issue certificates in the future like this one if they’d like.

Folks might have noticed already but the certificates the OP is concerned about aren't issued by Boulder/ACME. They're the product of ct-woodpecker's own internal PKI and don't chain to a trusted root. These certificates are part of the end-to-end monitoring of the CT log by Let's Encrypt staff and not the result of anyone issuing custom certificates with the normal ACME infrastructure.

One of ct-woodpecker's jobs is to periodically log certificates to monitored CT logs to record success/failure, latency, etc. After submission it can monitor the log for proof of inclusion of certificates it has previously logged. To do so with a minimum amount of overhead/fuss it issues test certificates that chain to its internal root CA. It doesn't act as an ACME client, or respond to domain validation. This internal PKI also facilitates the manipulation of the certificate lifetime so that all of the active shards of the log can be tested with submissions.

Importantly not just anyone can spin up their own ct-woodpecker instance (or similar home-spun root CA) and submit test certificates to the Let's Encrypt CT logs. The Let's Encrypt SRE team has specifically configured their CT log shards with their own ct-woodpecker instance's root CA as an allowed root, letting the monitor submit test certificates even though they aren't issued by a trusted CA participating in the web PKI.

@rg305

Yeah, weird…
But is that a “crime” ? ? ?

None of the baseline requirements apply to these test certificates, it's conceptually similar to the staging environment in that sense.

Hope that helps add some more background!

[arjunnkn]

lets consider the case when SCT is added to the [quote=“cpu, post:23, topic:122323”]
not the result of anyone issuing custom certificates with the normal ACME infrastructure.
[/quote]

Thanks I just wanted to hear this for confirmation because it got logged as an exception to my CTL analyser
Thanks