How are CT and handling precertificates now?


I remember a discussion about whether Let’s Encrypt was going to submit precertificates or issued certificates to CT logs. I was wondering how the use of precertificates is affecting the apparent issuance volumes that will appear in; could it sometimes confuse users using that web interface, or confuse tools like lectl or letsdebug, when a precertificate and a final certificate both appear in a log? (Could they be fooled into thinking that the issuance volume has been twice as high as it really has and hence that a rate limit has already been triggered when it really hasn’t?)


Hi @schoen,

Regarding lectl, to avoid confusion about how many certs you have issued I had to add two switches:

-p | --pre       [Default: true] shows only logged pre certs.
-f | --final     [Default: true] shows only logged final certs.

If you use one of those switches, the rate limit is count using pre or final certs, if you don’t use any of those switches you get the list of pre and final certs but the rate limit count is using only pre certificates because final certs could appear in DB a few hours or days after the pre cert is logged so you don’t get an accurate result.

I also added a new colum CERT TYPE to show whether it is a Pre cert or a Final cert.

CRT ID     CERT TYPE   DOMAIN (CN)                         VALID FROM             VALID TO               EXPIRES IN  SANs
499027109  Final cert           2018-Jun-01 00:01 UTC  2018-Aug-30 00:01 UTC  87 days
498144939  Pre cert           2018-Jun-01 00:01 UTC  2018-Aug-30 00:01 UTC  87 days
495304801  Final cert              2018-May-30 15:00 UTC  2018-Aug-28 15:00 UTC  85 days
495205959  Pre cert              2018-May-30 15:00 UTC  2018-Aug-28 15:00 UTC  85 days

But yes, if you use only the search in it is very confuse because you don’t know whether the cert is a pre cert, is a final cert or what it is till you check that specific cert. In this case it should be good to see a switch in site to filter pre and final (leaf) certificates.

Regarding letsdebug I suppose it is using the postgresql access to DB so it would be easy to deal with this issue.



For Let’s Debug, I’m tracking the certificates by the certificate serial, which is the same between the precert and the final cert, which side-steps the problem.

You can get a crappy result using a direct SQL query via the web interface.

“select distinct on (x509_serialnumber(c.CERTIFICATE)) as crtsh_id, x509_subjectName(c.CERTIFICATE), x509_notbefore(c.CERTIFICATE) from certificate c, certificate_identity ci where reverse(lower(ci.NAME_VALUE)) LIKE reverse(’’) and x509_notBefore(c.CERTIFICATE) > NOW() - INTERVAL ‘7 days’ AND ci.CERTIFICATE_ID = c.ID AND ci.issuer_ca_id = 16418 and ci.name_type = ‘dNSName’;”


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