# Duplicates in CT logs. Precertificate vs. Leaf certificate **URL:** \ **Category:** Issuance Tech\ **Created:** [August 12, 2018, 10:25am UTC](https://community.letsencrypt.org/t/duplicates-in-ct-logs-precertificate-vs-leaf-certificate/69190 "2018-08-12T10:25:49Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![EnriqCG](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/enriqcg/32/22105_2.png) [@EnriqCG](https://community.letsencrypt.org/u/EnriqCG)\ **Post date:** [August 12, 2018, 10:25am UTC](https://community.letsencrypt.org/t/duplicates-in-ct-logs-precertificate-vs-leaf-certificate/69190/1 "2018-08-12T10:25:49Z")
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. ---
**Author:** ![Osiris](https://avatars.discourse-cdn.com/v4/letter/o/839c29/32.png) [@Osiris](https://community.letsencrypt.org/u/Osiris)\ **Post date:** [August 12, 2018, 10:33am UTC](https://community.letsencrypt.org/t/duplicates-in-ct-logs-precertificate-vs-leaf-certificate/69190/2 "2018-08-12T10:33:56Z")
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](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. ---
**Author:** ![JuergenAuer](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/juergenauer/32/26491_2.png) [@JuergenAuer](https://community.letsencrypt.org/u/JuergenAuer)\ **Post date:** [August 12, 2018, 11:00am UTC](https://community.letsencrypt.org/t/duplicates-in-ct-logs-precertificate-vs-leaf-certificate/69190/3 "2018-08-12T11:00:44Z")
Additional: > [@EnriqCG](#): > > Does this only happen with crt.sh? Is it a problem with them? crt.sh lists precertificates and leaf certificates. Google [https://transparencyreport.google.com/https/certificates](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 > **[RFC 6962: Certificate Transparency](https://datatracker.ietf.org/doc/html/rfc6962)** > > This document describes an experimental protocol for publicly logging the existence of Transport Layer Security (TLS) certificates as they are issued or observed, in a manner that allows anyone to audit certificate authority (CA) activity and notice... So a browser can check, if the certificate is logged. ---
**Author:** ![Patches](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/patches/32/17145_2.png) [@Patches](https://community.letsencrypt.org/u/Patches)\ **Post date:** [August 12, 2018, 7:52pm UTC](https://community.letsencrypt.org/t/duplicates-in-ct-logs-precertificate-vs-leaf-certificate/69190/4 "2018-08-12T19:52:29Z")
Your first and third question were already answered, so I'll take your second one: > [@EnriqCG](#): > > - Are precertificates **required** to be published to CT logs? 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](https://groups.google.com/a/chromium.org/forum/#!msg/ct-policy/sz_3W_xKBNY/6jq2ghJXBAAJ), 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. ---
**Author:** ![ahaw021](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/ahaw021/32/14882_2.png) [@ahaw021](https://community.letsencrypt.org/u/ahaw021)\ **Post date:** [August 15, 2018, 1:38pm UTC](https://community.letsencrypt.org/t/duplicates-in-ct-logs-precertificate-vs-leaf-certificate/69190/5 "2018-08-15T13:38:07Z")
hi @EnriqCG [RFC 6962 - Certificate Transparency](https://tools.ietf.org/html/rfc6962) 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)](https://github.com/CaliDog/Axeman) 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. > **[Certificate Transparency - Log Entry Internals](https://www.linkedin.com/pulse/certificate-transparency-log-entry-internals-andrei-hawke/)** > > The log entries are not stored as a plain format (review RFC) but rather as a binary base64 encrypted structures. In order to get useful data (domain names, fingerprints, etc) out of a Log Entry we need to convert and then run it through a X509... [https://www.linkedin.com/pulse/certificate-transparency-log-internals-andrei-hawke/](https://www.linkedin.com/pulse/certificate-transparency-log-internals-andrei-hawke/) Also have a look at [censys.io](http://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/](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) ---
**Author:** ![ahaw021](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/ahaw021/32/14882_2.png) [@ahaw021](https://community.letsencrypt.org/u/ahaw021)\ **Post date:** [August 15, 2018, 1:55pm UTC](https://community.letsencrypt.org/t/duplicates-in-ct-logs-precertificate-vs-leaf-certificate/69190/6 "2018-08-15T13:55:14Z")
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](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](https://global.discourse-cdn.com/letsencrypt/original/3X/6/d/6d3a1e00c1af986ed3ab6e98437ea268a61b8ce0.png) Andrei ---
**Author:** ![EnriqCG](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/enriqcg/32/22105_2.png) [@EnriqCG](https://community.letsencrypt.org/u/EnriqCG)\ **Post date:** [August 15, 2018, 2:04pm UTC](https://community.letsencrypt.org/t/duplicates-in-ct-logs-precertificate-vs-leaf-certificate/69190/7 "2018-08-15T14:04:08Z")
> [@ahaw021](#): > > [Certificate Transparency - Log Entry Internals](https://www.linkedin.com/pulse/certificate-transparency-log-entry-internals-andrei-hawke/) > [https://www.linkedin.com/pulse/certificate-transparency-log-internals-andrei-hawke/](https://www.linkedin.com/pulse/certificate-transparency-log-internals-andrei-hawke/) Those articles will be a good resource to understand CT, which at the momment I don't really understand. > [@ahaw021](#): > > Tools like this [https://github.com/CaliDog/Axeman](https://github.com/CaliDog/Axeman) have a look for the specific OID mentioned and don’t parse if that is the only entry I will definetely try Axeman. Thanks a lot. ---
**Author:** ![system](https://global.discourse-cdn.com/letsencrypt/original/3X/c/a/ca6c06ea1ea201324bba7048c6841ce60236468d.png) [@system](https://community.letsencrypt.org/u/system)\ **Post date:** [September 14, 2018, 2:04pm UTC](https://community.letsencrypt.org/t/duplicates-in-ct-logs-precertificate-vs-leaf-certificate/69190/8 "2018-09-14T14:04:10Z")
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.