Duplicates in CT logs. Precertificate vs. Leaf certificate

Issuance Tech
1

Good day,

I was routinely checking CT logs for a couple of my domains where I stumbled accross multiple issuances which didn’t seem right. Every single domain had two certificates issued on the same day.

Further investigation revealed that both certificates share the same serial number and both are practically the same certificate. I noticed the only difference was one being a precertificate and the other one a leaf certificate.

  • What is the difference between the two?
  • Are precertificates required to be published to CT logs?
  • Does this only happen with crt.sh? Is it a problem with them?

Thanks for your time.

2

It has everything to do with embedding certificate log signatures in the final certificate, called “Signed Certificate Timestamps”. For more information, see: http://www.certificate-transparency.org/faq#TOC-What-is-an-SCT

These SCTs as they are abbreviated, can be included in the TLS handshake, in a stapled OCSP response or, as Let’s Encrypt uses them, into the final certificate itself.

For the SCT to be included in the final certificate, the CA (in casu Let’s Encrypt), has to send a “pre-certificate” to the log first. Then, when it receives the SCT, it can include this SCT in the final certificate. But it has to send the final certificate to the log too. So you’ll see it twice.

2 Likes
3

Additional:

crt.sh lists precertificates and leaf certificates. Google

https://transparencyreport.google.com/https/certificates

lists only leaf certificates.

The certificate which such a timestamp has an extension:

OID 1.3.6.1.4.1.11129.2.4.2

So a browser can check, if the certificate is logged.

1 Like
4

Your first and third question were already answered, so I'll take your second one:

For you, yes they are required. There's no way for you to get a certificate from Let's Encrypt (and most other certificate authorities) without them.

For Let's Encrypt, no, they don't necessarily have to submit them. But if they didn't, everyone would be forced to set up OCSP stapling or compile and install an extra extension into their Apache and nginx servers to comply with Google Chrome's new Certificate Transparency requirements, or their sites would not work in recent versions of Google Chrome.

That's a lot of work, which is why most CAs, including Let's Encrypt, have gone the precertificate/SCT route, so end users don't have to do anything they didn't do before to comply with these new requirements.

1 Like
5

hi @EnriqCG

RFC 6962 - Certificate Transparency the RFC describes the role of pre-certificates

Section 3.1

Depending on how you write your parser I generally ignore these.

Tools like this GitHub - CaliDog/Axeman: Axeman is a utility to retrieve certificates from Certificate Transparency Lists (CTLs) have a look for the specific OID mentioned and don't parse if that is the only entry

I wrote a couple of articles which may be a bit dated.

https://www.linkedin.com/pulse/certificate-transparency-log-internals-andrei-hawke/

Also have a look at censys.io as that is the one I ended up standardizing my searches on. It has a good API and I believe they don't include records with pre-certificates

Another good service is here https://keychest.net/

Alternatively, (root as well as intermediate) certificate authorities
may submit a certificate to logs prior to issuance. To do so, the CA
submits a Precertificate that the log can use to create an entry that
will be valid against the issued certificate. The Precertificate is
constructed from the certificate to be issued by adding a special
critical poison extension (OID 1.3.6.1.4.1.11129.2.4.3, whose
extnValue OCTET STRING contains ASN.1 NULL data (0x05 0x00)) to the
end-entity TBSCertificate (this extension is to ensure that the
Precertificate cannot be validated by a standard X.509v3 client)

1 Like
6

I also remembered some extra details (it’s been 10 months since i touch the project)

If you parse the header you will get a record of 0 or 1

(check out the parser here) https://github.com/ahaw021/SPLUNK-ELK-CERTIFICATE-TRANSPARENCY/blob/master/Internals%20-%20CT%20Log%20Entries/ctl_cert_parser_structure.py

The leaf input which can essentially be counted as a header has this property in it

image

Andrei

7

Those articles will be a good resource to understand CT, which at the momment I don't really understand.

I will definetely try Axeman. Thanks a lot.

8

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