3 ms·

Certificates have issuance date, no? Given ntp is a thing now, we might get close to finding the billiont.

tialaramex 7y ago
The issuance date inside a certificate is not required to be accurate. Technical reasons for inaccuracy include a widespread choice to have stuff "Just work" if you install a brand new certificate even though it's not rare for end users to have clocks wrong by ~1 hour and historically a preference to put entropy (randomness) in the date-time fields because they're near the beginning of the certificate. The latter doesn't apply to Let's Encrypt (they're too new and this is no longer the Done Thing) but the former certainly does and there might be other technical reasons for small deviations. Inaccuracies in the timestamps are only forbidden if their purpose seems to be to defeat some other policy. For example during SHA-1 deprecation new certificates were forbidden because once you cease issuing there's no new risk from collision attacks. You can't travel back in time with knowledge of a collision and get certificates, so if a collision is found in 2017 but no certs were issued after 2016 then we're safe. To enforce the prohibition certificates using SHA-1 but dated after the prohibition weren't trusted. But a misbehaving CA (in this case WoSign) could back-date a SHA-1 certificate presumably for a hefty mark-up over their usual prices. This was against the rules, Gerv (who has since died) investigated and built up good evidence that's what happened though. Anyway, there are less than 100 000 seconds in a day and in that time Let's Encrypt issues typically over a million certificates. So there might be dozens of certificates issued in the same second as the billionth one no matter how you count.
- fanf2 7y ago
  Do you have a reference describing how entropy was added to certificate lifetimes? I can't see anything about it in old versions of the CA/B forum baseline requirements, and my understanding is that random serial numbers provide enough unpredictability so they don't need to randomize the other fields.

The issuance date inside a certificate is not required to be accurate. Technical reasons for inaccuracy include a widespread choice to have stuff "Just work" if you install a brand new certificate even though it's not rare for end users to have clocks wrong by ~1 hour and historically a preference to put entropy (randomness) in the date-time fields because they're near the beginning of the certificate. The latter doesn't apply to Let's Encrypt (they're too new and this is no longer the Done Thing) but the former certainly does and there might be other technical reasons for small deviations. Inaccuracies in the timestamps are only forbidden if their purpose seems to be to defeat some other policy. For example during SHA-1 deprecation new certificates were forbidden because once you cease issuing there's no new risk from collision attacks. You can't travel back in time with knowledge of a collision and get certificates, so if a collision is found in 2017 but no certs were issued after 2016 then we're safe. To enforce the prohibition certificates using SHA-1 but dated after the prohibition weren't trusted. But a misbehaving CA (in this case WoSign) could back-date a SHA-1 certificate presumably for a hefty mark-up over their usual prices. This was against the rules, Gerv (who has since died) investigated and built up good evidence that's what happened though. Anyway, there are less than 100 000 seconds in a day and in that time Let's Encrypt issues typically over a million certificates. So there might be dozens of certificates issued in the same second as the billionth one no matter how you count.

fanf2 7y ago
Do you have a reference describing how entropy was added to certificate lifetimes? I can't see anything about it in old versions of the CA/B forum baseline requirements, and my understanding is that random serial numbers provide enough unpredictability so they don't need to randomize the other fields.