My organisation has been trying to use the crt.sh database that tracks the Let's Encrypt public certificate transparency log to compute our Let's Encrypt quota usage for each domain. Let's Encrypt does not expose any public interface for checking quota limits or usage, so tracking the public certificate transparency log seems to be the only way to monitor it.
The queries they were using were timing out and failing, at which point I became involved.
The timeouts turned out to be due to some bugs introduced by changes made to the original crt.sh-derived queries, but I'm sure we're not the only ones with these issues so I wanted to share what I've found and done.
The Let's Encrypt certificatesPerNameLimit quota defaults to 50 certs per week issued with a distinct set of subject fully qualified domain names. "Renewals" are not counted, where a renewal is a new cert issued with the exact same set of domain names as a previously-issued cert. Renewals have a separate certificatesPerFQDNSetLimit quota of 5 per week per unique set of domains. See
https://letsencrypt.org/docs/rate-limits/ . Pre-certificates are not counted against this limit, only the final certificates issued are counted. Internally in Let's Encrypt's backend the quota is bucketed into 1 hour blocks by requesting next-to-top-level domain e.g.
myorg.com .
Thanks very much for the database - it's astounding how well it copes with what must be a huge load, even across replicas, especially since it's denormalized and there's very little pre-computed info for the certs built up in expression indexes. The custom full-text search trick it uses is extremely clever.