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 crt.sh; 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?)
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 crt.sh 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 community.letsencrypt.org 2018-Jun-01 00:01 UTC 2018-Aug-30 00:01 UTC 87 days community.letsencrypt.org 498144939 Pre cert community.letsencrypt.org 2018-Jun-01 00:01 UTC 2018-Aug-30 00:01 UTC 87 days community.letsencrypt.org 495304801 Final cert status.letsencrypt.org 2018-May-30 15:00 UTC 2018-Aug-28 15:00 UTC 85 days status.letsencrypt.org 495205959 Pre cert status.letsencrypt.org 2018-May-30 15:00 UTC 2018-Aug-28 15:00 UTC 85 days status.letsencrypt.org [...]
But yes, if you use only the search in https://crt.sh 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 crt.sh site to filter pre and final (leaf) certificates.
Regarding letsdebug I suppose it is using the postgresql access to crt.sh 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 crt.sh-like result using a direct SQL query via the web interface.
“select distinct on (x509_serialnumber(c.CERTIFICATE)) c.id 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(’%.no-ip.com’) 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.