4 ms·

It's surprisingly hard to tell which certificate was the billionth issued. You'd have to decide on a source of truth, and CT is probably not a good one for this

by jaas 7y ago

It's surprisingly hard to tell which certificate was the billionth issued. You'd have to decide on a source of truth, and CT is probably not a good one for this purpose. Submissions to CT are not necessarily made and processed in issuance order. The goal is to get all certs into CT as quickly as possible, but ordering isn't particularly important (maybe one submission from our CA starts a second before another but the network request is delayed until after the second one). At the heart of things, our certificate signing infrastructure includes multiple HSMs, each one with multiple signing cores. This means that we're signing certificates in parallel all the time. The signed certificates are inserted into our internal database in a serialized order, but due to how we optimize our database it's not easy for us to just ask "what is the billionth one." That kind of query is usually not a very useful one for us to make.

ddevault 7y ago
So, what you're saying is that my certificate was definitely the billionth.
- cjm42 7y ago
  No, he's saying that he cannot deny that your certificate was the billionth.
tehlike 7y ago
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.
remram 7y ago
Could we get a winner according to some source? It's not like it matters a whole lot. Going by issuance date is probably good enough for most readers, but I have no idea how to go about finding that.
- schoen 7y ago
  It's kind of labor-intensive! Like, in theory you can look at all of https://crt.sh/?Identity=%25&iCAID=7395 https://crt.sh/?Identity=%25&iCAID=7395 https://crt.sh/?Identity=%25&iCAID=16418 https://crt.sh/?Identity=%25&iCAID=16418 to see all of them, and then find the billionth one. But wait, there are already 1.7 billion logged on just CAID 16418 alone...? That's because of something called CT precertificates which are a weird hack where CAs may issue every certificate twice (once in a usable form and once in an unusable form) in order to facilitate CT logging verification. So some (but not all!) of those 1.7 billion are duplicates, which you can determine by excluding the ones that have the "precertificate poison" X.509 extension. Which I don't think crt.sh lets you do easily in this query interface. Also, I think its interface can only show you results in log order rather than sorted by issuance date. So you would potentially need to do your own CT log parsing into a database in order to run this moderately complicated query, unless you can find someone else with a parsed CT log database who will let you run more specific database queries than crt.sh. It's always weird when something computer-related is like "that data is public, but not currently present in a useful database schema that you can query to answer your exact question", but I think this is one of those cases!
  - remram 7y ago
    crt.sh actually has their postgres database open to the public! You can connect with: psql -h crt.sh -p 5432 -U guest certwatch From what you're saying, the query would be: SELECT c.ID FROM certificate c WHERE (c.ISSUER_CA_ID = 16418 OR c.ISSUER_CA_ID = 7395) AND NOT x509_hasExtension(c.CERTIFICATE, '1.3.6.1.4.1.11129.2.4.3') OFFSET 1000000000 LIMIT 1; Unfortunately (but expectedly) it times out
    - schoen 7y ago

by jaas 7y ago

ddevault 7y ago

So, what you're saying is that my certificate was definitely the billionth.

cjm42 7y ago
No, he's saying that he cannot deny that your certificate was the billionth.

tehlike 7y ago

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.

remram 7y ago

Could we get a winner according to some source? It's not like it matters a whole lot. Going by issuance date is probably good enough for most readers, but I have no idea how to go about finding that.

schoen 7y ago
It's kind of labor-intensive! Like, in theory you can look at all of https://crt.sh/?Identity=%25&iCAID=7395 https://crt.sh/?Identity=%25&iCAID=7395 https://crt.sh/?Identity=%25&iCAID=16418 https://crt.sh/?Identity=%25&iCAID=16418 to see all of them, and then find the billionth one. But wait, there are already 1.7 billion logged on just CAID 16418 alone...? That's because of something called CT precertificates which are a weird hack where CAs may issue every certificate twice (once in a usable form and once in an unusable form) in order to facilitate CT logging verification. So some (but not all!) of those 1.7 billion are duplicates, which you can determine by excluding the ones that have the "precertificate poison" X.509 extension. Which I don't think crt.sh lets you do easily in this query interface. Also, I think its interface can only show you results in log order rather than sorted by issuance date. So you would potentially need to do your own CT log parsing into a database in order to run this moderately complicated query, unless you can find someone else with a parsed CT log database who will let you run more specific database queries than crt.sh. It's always weird when something computer-related is like "that data is public, but not currently present in a useful database schema that you can query to answer your exact question", but I think this is one of those cases!
- remram 7y ago
  crt.sh actually has their postgres database open to the public! You can connect with: psql -h crt.sh -p 5432 -U guest certwatch From what you're saying, the query would be: SELECT c.ID FROM certificate c WHERE (c.ISSUER_CA_ID = 16418 OR c.ISSUER_CA_ID = 7395) AND NOT x509_hasExtension(c.CERTIFICATE, '1.3.6.1.4.1.11129.2.4.3') OFFSET 1000000000 LIMIT 1; Unfortunately (but expectedly) it times out
  - schoen 7y ago