How is it possible ? future logging

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: Probably the one place that certificate is valid, is in the Certificate Log itself and perhaps other LE logs :stuck_out_tongue:

1 Like

@arjunnkn I don’t see what you mean when you say:

I click the link you provided but I don’t see what you see.
Can you post a picture?

@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.

1 Like

see the third row . its timestamp is ahead of the date from which its validity started

1 Like

Ok now I understand your point.

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.”

1 Like

You’ve got it backwards. It was logged in February 2019. It’s valid the year 2020.

1 Like

My eyes are deceiving me!
This is 2020 but my eyes aren’t 20/20!!!


So …
I’m going to give you a cert today…
But it will only be good next year - all year - anytime… NEXT YEAR.

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

1 Like

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

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”.


So the only real “limit” is the END DATE.
Which can’t be more than 825 days into the future from the date it was issued.
Regardless of START DATE.

1 Like

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.

1 Like

@Osiris @rg305 on my log parser another certificate gets logged see

No you cannot use it before start date too

1 Like

Nothing strange about that one, right?

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…

@Osiris if you dont mind can we discuss as i am not completely satisfied yet ??

Please do, what did you want to discuss about that second certificate?

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.


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 :stuck_out_tongue: Good to know!


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.

Hope that helps add some more background!


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.

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


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