It means the CA just set the dates to those dates they specifically wanted.
It looks like it’s the certificate of one of Let’s Encrypts own Certificate Logssystems. 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.
By the way, it’s issued by this root certificate: https://crt.sh/?id=1476662614 Probably the one place that certificate is valid, is in the Certificate Log itself and perhaps other LE logs
@rg305 Check the date the certificate was logged. Way before the “Not before” date. @arjunnkn assumed this was not possible, because as I read it, he thought the “Not before” date was the date the certificate was issued. But that isn’t necessarily the case.
But I don’t see the “crime”.
Like what if the whole thing was in the past…
Logged today for a cert that was valid only last year.
How it that a bad thing?
At least there is an entry of its’ existence.
“Better late than never.”
By the way, interesting thing I found in the CA/B Forum BR in a specific definition:
Validity Period: The period of time measured from the date when the Certificate is issued until the Expiry
Date.
Notice the use of “is issued”.
And in section 6.3.2 we see:
6.3.2. Certificate Operational Periods and Key Pair Usage Periods
Subscriber Certificates issued after 1 March 2018 MUST have a Validity Period no greater than 825 days.
Subscriber Certificates issued after 1 July 2016 but prior to 1 March 2018 MUST have a Validity Period ngreater than 39 months.
So in essence, the “Not after” date is calculated from the day the certificate was ISSUED and NOT the “Not Before” date?
No. Like I said, I think @arjunnkn just misinterpreted the “Not before” date as the date of issuance, but that isn’t necessarily true. It would of course be impossible to log a certificate which wasn’t even issued until the future. However, it’s perfectly possible to issue a certificate now with the “Not Before” date in the future. But that requires the understanding that “Not before” is not the same as “date of issuance”.
I think that’s how you should interpret the BR yes.
Not an issue for most certificates, but it means you can’t issue a (subscriber!) certificate with a lifetime of 365 days more than 1 year and 3 months and 5 days into the future.
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…
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.
None of the baseline requirements apply to these test certificates, it’s conceptually similar to the staging environment in that sense.
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
