Since LE has certificiate transparency, can we determine which cert was the billionth? I registered two certs with them today, here's hoping it was me ;)
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.
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.
Like, in theory you can look at all of
https://crt.sh/?Identity=%25&iCAID=7395
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!
You can connect with:
psql -h crt.sh -p 5432 -U guest certwatch
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;