# Certificate Transparency Logs Problem

**URL:** <https://community.letsencrypt.org/t/certificate-transparency-logs-problem/14001>\
**Category:** Server\
**Created:** [April 10, 2016, 8:06pm UTC](https://community.letsencrypt.org/t/certificate-transparency-logs-problem/14001 "2016-04-10T20:06:26Z")\
**Posts on this page:** 17\
**Page:** 1

<div class="post-metadata">

**Author:** ![Jason](https://avatars.discourse-cdn.com/v4/letter/j/dc4da7/32.png) [@Jason](https://community.letsencrypt.org/u/Jason)\
**Post date:** [April 10, 2016, 8:06pm UTC](https://community.letsencrypt.org/t/certificate-transparency-logs-problem/14001/1 "2016-04-10T20:06:26Z")

</div>

Now that Google has decided to remove Certly as a log server from the Chrome trusted logs list (effective from April 15) and now that the WoSign Log’s request has been denied, there is **no** non-Google log that supports either DST Root X3 or ISRG Root X1.

What can be done about that? Discuss freely.

---

<div class="post-metadata">

**Author:** ![tlussnig](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/tlussnig/32/2053_2.png) [@tlussnig](https://community.letsencrypt.org/u/tlussnig)\
**Post date:** [April 10, 2016, 9:19pm UTC](https://community.letsencrypt.org/t/certificate-transparency-logs-problem/14001/2 "2016-04-10T21:19:32Z")

</div>

Hi, could you link any source where this information came from ?

---

<div class="post-metadata">

**Author:** ![sahsanu](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/sahsanu/32/89984_2.png) [@sahsanu](https://community.letsencrypt.org/u/sahsanu)\
**Post date:** [April 10, 2016, 11:27pm UTC](https://community.letsencrypt.org/t/certificate-transparency-logs-problem/14001/3 "2016-04-10T23:27:27Z")

</div>

Hello @tlussnig,

Certly removal [https://groups.google.com/a/chromium.org/d/msg/ct-policy/nyRtXSWSeaM/sL1gpJEuCQAJ](https://groups.google.com/a/chromium.org/d/msg/ct-policy/nyRtXSWSeaM/sL1gpJEuCQAJ)  
WoSign denied [https://groups.google.com/a/chromium.org/d/msg/ct-policy/LE0AlqMHISQ/L7EGfOQvCQAJ](https://groups.google.com/a/chromium.org/d/msg/ct-policy/LE0AlqMHISQ/L7EGfOQvCQAJ)

Cheers,  
sahsanu

---

<div class="post-metadata">

**Author:** ![tlussnig](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/tlussnig/32/2053_2.png) [@tlussnig](https://community.letsencrypt.org/u/tlussnig)\
**Post date:** [April 11, 2016, 5:23am UTC](https://community.letsencrypt.org/t/certificate-transparency-logs-problem/14001/4 "2016-04-11T05:23:54Z")

</div>

So if there is not an wrong measurement the reason for exclusion is clear and an pre defined condition the CT-Log server are required to have an 99% availability. This may sound high but since is be an critical infrastructure part i can understand the requirement and the removal.  
That there is no non-google log that support this root is another part.

---

<div class="post-metadata">

**Author:** ![Jason](https://avatars.discourse-cdn.com/v4/letter/j/dc4da7/32.png) [@Jason](https://community.letsencrypt.org/u/Jason)\
**Post date:** [April 11, 2016, 1:32pm UTC](https://community.letsencrypt.org/t/certificate-transparency-logs-problem/14001/5 "2016-04-11T13:32:09Z")

</div>

However, something needs to be done, since now Let’s Encrypt users cannot obtain any trusted non-Google log proof for their certificates!!

---

<div class="post-metadata">

**Author:** ![tlussnig](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/tlussnig/32/2053_2.png) [@tlussnig](https://community.letsencrypt.org/u/tlussnig)\
**Post date:** [April 11, 2016, 5:40pm UTC](https://community.letsencrypt.org/t/certificate-transparency-logs-problem/14001/6 "2016-04-11T17:40:53Z")

</div>

Hi, you can still use certly. If you fear that google could hide the record.  
On the other hand if you fear that google get the data remember that CT is about public.

---

<div class="post-metadata">

**Author:** ![Jason](https://avatars.discourse-cdn.com/v4/letter/j/dc4da7/32.png) [@Jason](https://community.letsencrypt.org/u/Jason)\
**Post date:** [April 11, 2016, 9:31pm UTC](https://community.letsencrypt.org/t/certificate-transparency-logs-problem/14001/7 "2016-04-11T21:31:00Z")

</div>

Well, the thing is that although Certly may still be freely used, its SCTs will be kind of “useless”, since they will not be trusted at all by Chrome from 15 April onwards… That was the discussion about in the first place. That there currently is NO non-Google Chrome-trusted log that will accept either DST or ISRG Roots.

---

<div class="post-metadata">

**Author:** ![tialaramex](https://avatars.discourse-cdn.com/v4/letter/t/f08c70/32.png) [@tialaramex](https://community.letsencrypt.org/u/tialaramex)\
**Post date:** [April 12, 2016, 11:32am UTC](https://community.letsencrypt.org/t/certificate-transparency-logs-problem/14001/8 "2016-04-12T11:32:06Z")

</div>

Are you sure that other logs won’t accept these certificates? I haven’t been able to find any documented restriction on submitting certificates chained to a BR root in any of the logs I looked at.

If you don’t have any evidence and you’re enthusiastic you should be able to test this by hand, as logs are generally not very interested in who submits a certificate (the certificate is a public document, so it’s not as though you can “steal” one) you can try to submit a recent LE certificate to other logs to see if they reject it.

---

<div class="post-metadata">

**Author:** ![tialaramex](https://avatars.discourse-cdn.com/v4/letter/t/f08c70/32.png) [@tialaramex](https://community.letsencrypt.org/u/tialaramex)\
**Post date:** [April 12, 2016, 11:42am UTC](https://community.letsencrypt.org/t/certificate-transparency-logs-problem/14001/9 "2016-04-12T11:42:41Z")

</div>

Venafi’s log is included in Chrome since M47 and they write  
"Venafi provides a CT log independent of any specific Certificate Authority (CA), welcoming any CA to publish to the Venafi CT log."

[https://www.venafi.com/blog/post/venafi-supports-google-certificate-transparency/](https://www.venafi.com/blog/post/venafi-supports-google-certificate-transparency/)

---

<div class="post-metadata">

**Author:** ![jsha](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/jsha/32/12_2.png) [@jsha](https://community.letsencrypt.org/u/jsha)\
**Post date:** [April 12, 2016, 5:33pm UTC](https://community.letsencrypt.org/t/certificate-transparency-logs-problem/14001/11 "2016-04-12T17:33:50Z")

</div>

We’ve applied for inclusion in Symantec’s, DigiCert’s, and Venafi’s CT logs. Currently none of them have accepted us.

---

<div class="post-metadata">

**Author:** ![tdelmas](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/tdelmas/32/1866_2.png) [@tdelmas](https://community.letsencrypt.org/u/tdelmas)\
**Post date:** [April 12, 2016, 6:30pm UTC](https://community.letsencrypt.org/t/certificate-transparency-logs-problem/14001/12 "2016-04-12T18:30:02Z")

</div>

@jsha By “accepted”, do you mean they refused or did not answer yet?

---

<div class="post-metadata">

**Author:** ![Jason](https://avatars.discourse-cdn.com/v4/letter/j/dc4da7/32.png) [@Jason](https://community.letsencrypt.org/u/Jason)\
**Post date:** [April 12, 2016, 7:23pm UTC](https://community.letsencrypt.org/t/certificate-transparency-logs-problem/14001/13 "2016-04-12T19:23:35Z")

</div>

This is obtained using my certificate and the DST-signed LE X3 intermediate:

> sending request to [https://ct.googleapis.com/aviator](https://ct.googleapis.com/aviator)  
> version: 0  
> log ID: aPaY+B9kgr46jO65KB1M/HFRXWeT1ETRCmesu09P+8Q=  
> timestamp: 1458939442057 (2016-03-25 22:57:22)  
> extensions:  
> signature: BAMASDBGAiEAiGtjGP/YCLRwExv1QXM/X3DRHGkJXP1Knxec8O4r+KgCIQCyxIkG6Mv278V+YKXvoDrrgTvePYGSDBPNPuIU37jMww==  
> SCT (119 bytes): AGj2mPgfZIK+OozuuSgdTPxxUV1nk9RE0QpnrLtPT/vEAAABU6+RM4kAAAQDAEgwRgIhAIhrYxj/2Ai0cBMb9UFzP19w0RxpCVz9Sp8XnPDuK/ioAiEAssSJBujL9u/FfmCl76A664E73j2BkgwTzT7iFN+4zMM=

> sending request to [https://ct.googleapis.com/pilot](https://ct.googleapis.com/pilot)  
> version: 0  
> log ID: pLkJkLQYWBSHuxOizGdwCjw1mAT5G9+443fNDsgN3BA=  
> timestamp: 1458939442515 (2016-03-25 22:57:22)  
> extensions:  
> signature: BAMARzBFAiADwnHMQWqVm5Mv2lsRCz8okY5ojzGLknCn7bQ20XbJbQIhAOMKYtgvryVmZs69tsD+T2kcapIbg/tLgfBkHa+AY0WC  
> SCT (118 bytes): AKS5CZC0GFgUh7sTosxncAo8NZgE+RvfuON3zQ7IDdwQAAABU6+RNVMAAAQDAEcwRQIgA8JxzEFqlZuTL9pbEQs/KJGOaI8xi5Jwp+20NtF2yW0CIQDjCmLYL68lZmbOvbbA/k9pHGqSG4P7S4HwZB2vgGNFgg==

> sending request to [https://ct.googleapis.com/rocketeer](https://ct.googleapis.com/rocketeer)  
> version: 0  
> log ID: 7ku9t3XOYLrhQmkfq+GeZqMPfl+wctiDAMR7iXqo/cs=  
> timestamp: 1458939443058 (2016-03-25 22:57:23)  
> extensions:  
> signature: BAMARzBFAiBAFnB/THPoZrq73zqAdOs4QU4ceQspvuAAzA4Ii2nUDgIhALtzG2FWf9C+ppAXqub4g4ZXYGlveeBJx/UfFEupjBm2  
> SCT (118 bytes): AO5Lvbd1zmC64UJpH6vhnmajD35fsHLYgwDEe4l6qP3LAAABU6+RN3IAAAQDAEcwRQIgQBZwf0xz6Ga6u986gHTrOEFOHHkLKb7gAMwOCItp1A4CIQC7cxthVn/QvqaQF6rm+IOGV2Bpb3ngScf1HxRLqYwZtg==

> sending request to [https://ct.googleapis.com/submariner](https://ct.googleapis.com/submariner)  
> unable to submit certificate to log, HTTP error 400 Bad Request: {  
> "error\_message": "Invalid Request.",  
> "success": false  
> }

> sending request to [https://log.certly.io](https://log.certly.io)  
> unable to submit certificate to log, HTTP error 400 Bad Request: { "error\_message": "could not verify certificate chain", "success": false }

> sending request to [https://ct1.digicert-ct.com/log](https://ct1.digicert-ct.com/log)  
> unable to submit certificate to log, HTTP error 400 BAD REQUEST: A trusted root was not found.

> sending request to [https://ct.izenpe.com](https://ct.izenpe.com)  
> unable to submit certificate to log, HTTP error 400 Bad Request: { "error\_message": "could not verify certificate chain", "success": false }

> sending request to [https://ct.izenpe.com/pilot](https://ct.izenpe.com/pilot)  
> unable to submit certificate to log, HTTP error 400 Bad Request: { "error\_message": "could not verify certificate chain", "success": false }

> sending request to [https://ct.ws.symantec.com](https://ct.ws.symantec.com)  
> unable to submit certificate to log, HTTP error 400 Bad Request: {"error\_message":"Root certificate is not trusted.","success":false}

> sending request to [https://ct.wosign.com](https://ct.wosign.com)  
> version: 0  
> log ID: nk/3PcPOIgtpIXyJnkaAdqv414Y21cz8haMadWKLqIs=  
> timestamp: 1458939774237 (2016-03-25 23:02:54)  
> extensions:  
> signature: BAMARjBEAiAWm1u+YUpxlR453d2533E5wf+J2ciECjgylMdCiFv/fAIgNbdYS8pj8QX/roFTL3WpBBoxu+v0gDeIMJKBBZhk+T4=  
> SCT (117 bytes): AJ5P9z3DziILaSF8iZ5GgHar+NeGNtXM/IWjGnVii6iLAAABU6+WRR0AAAQDAEYwRAIgFptbvmFKcZUeOd3dud9xOcH/idnIhAo4MpTHQohb/3wCIDW3WEvKY/EF/66BUy91qQQaMbvr9IA3iDCSgQWYZPk+

> sending request to [https://ctserver.cnnic.cn](https://ctserver.cnnic.cn)  
> unable to submit certificate to log, HTTP error 400 Bad Request: { "error\_message": "unknown root", "success": false }

> sending request to [https://ctlog.api.venafi.com](https://ctlog.api.venafi.com)  
> version: 0  
> log ID: rDua7X+pZ0dXFZ5tfVdWcvnZgQCUHpve/+yhMTt1eC0=  
> timestamp: 1458939776533 (2016-03-25 23:02:56)  
> extensions:  
> signature: BAEBABfRxws/l9MyGA3dI6zPqUTiUM97x08KM8gj+TnHhn38FhcCLqy+OxnlZ1oqz0A91LucyDH4P1sVDsJg8tpQkNTxeySq6Bi56oPao6xwHhrZwDZygz1MxVZWVMgCKxuJtXTuu0ZQfXy3I8XawEzsp+8LmwG5wxImfWpmuPIpAL6+p52qfr2k9aeSdUkQaRoJrpxPD4AmEHhmUsqJNDLh2JLl22fI8HlzmCshEUKBz+px6QE6Mg7P+V+BFdcSlflo1Da4BgyH0Iv6GgtO+Ff3WTN2CgIjGQ2ROMr64ry1+iO9uJBXgQy5sf2EYG0wOXTzHR4hpaOelthIjOyG23D2eqA=  
> SCT (303 bytes): AKw7mu1/qWdHVxWebX1XVnL52YEAlB6b3v/soTE7dXgtAAABU6+WThUAAAQBAQAX0ccLP5fTMhgN3SOsz6lE4lDPe8dPCjPII/k5x4Z9/BYXAi6svjsZ5WdaKs9APdS7nMgx+D9bFQ7CYPLaUJDU8XskqugYueqD2qOscB4a2cA2coM9TMVWVlTIAisbibV07rtGUH18tyPF2sBM7KfvC5sBucMSJn1qZrjyKQC+vqedqn69pPWnknVJEGkaCa6cTw+AJhB4ZlLKiTQy4diS5dtnyPB5c5grIRFCgc/qcekBOjIOz/lfgRXXEpX5aNQ2uAYMh9CL+hoLTvhX91kzdgoCIxkNkTjK+uK8tfojvbiQV4EMubH9hGBtMDl08x0eIaWjnpbYSIzshttw9nqg

> sending request to [https://plausible.ct.nordu.net](https://plausible.ct.nordu.net)  
> version: 0  
> log ID: qucLfzy41WbIbC8Wl5yfRF9pqw60U1WJsvd6AwEE880=  
> timestamp: 1458939784127 (2016-03-25 23:03:04)  
> extensions:  
> signature: BAMASDBGAiEAynqT4IsDzdiZdC7+XMeGZffQNYT7NztB0ACt2AzX/nECIQDjDhxagPWoD5fKCDpI9Q0Xs3mbFzvKHEHWCGbespAbKg==  
> SCT (119 bytes): AKrnC388uNVmyGwvFpecn0RfaasOtFNVibL3egMBBPPNAAABU6+Wa78AAAQDAEgwRgIhAMp6k+CLA83YmXQu/lzHhmX30DWE+zc7QdAArdgM1/5xAiEA4w4cWoD1qA+Xygg6SPUNF7N5mxc7yhxB1ghm3rKQGyo=

---

<div class="post-metadata">

**Author:** ![jsha](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/jsha/32/12_2.png) [@jsha](https://community.letsencrypt.org/u/jsha)\
**Post date:** [April 12, 2016, 8:39pm UTC](https://community.letsencrypt.org/t/certificate-transparency-logs-problem/14001/14 "2016-04-12T20:39:31Z")

</div>

@jason: There’s a more straightforward way to find out about included roots, by fetching `/ct/v1/get-roots`.

@tdelmas: So far Symantec has reject on the grounds that our submission volume is too high. The others haven’t replied yet. It looks like Venafi actually does include us now - and we may have incorrectly concluded that they didn’t. So we’ll start submitting to them soon.

Also note that if you’re using the TLS Extension method to provide SCT proofs, you can submit your logs independently and don’t need to wait on us. If you’re waiting to use the OCSP Stapling method, you’re blocked on our work to include SCTs in OCSP (which is progressing, but slowly).

---

<div class="post-metadata">

**Author:** ![tdelmas](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/tdelmas/32/1866_2.png) [@tdelmas](https://community.letsencrypt.org/u/tdelmas)\
**Post date:** [April 12, 2016, 8:54pm UTC](https://community.letsencrypt.org/t/certificate-transparency-logs-problem/14001/15 "2016-04-12T20:54:59Z")

</div>

@jsha thank you for all the details

---

<div class="post-metadata">

**Author:** ![tialaramex](https://avatars.discourse-cdn.com/v4/letter/t/f08c70/32.png) [@tialaramex](https://community.letsencrypt.org/u/tialaramex)\
**Post date:** [April 12, 2016, 10:06pm UTC](https://community.letsencrypt.org/t/certificate-transparency-logs-problem/14001/16 "2016-04-12T22:06:48Z")

</div>

Thankyou for performing this experiment, it’s particularly interesting to me that Google’s “submariner” does not accept this certificate since I understood the stated purpose of “submariner” is precisely to log certificates from roots which are applying for major trust stores like Mozilla, and of course LE are in the latter stages of just such an application.

Mozilla (and presumably other trust stores, behind closed doors) pay significant attention to what can be found in [crt.sh](http://crt.sh) and censys for applying CAs. In m.d.s.policy we’ve seen evidence of CAs that can’t get their ASN.1 right, don’t implement the BRs correctly and other problems that historically might have been discovered only months after the CA cert is added to the trust store when it’s much harder to get them to fix things. So to me submariner’s declared purpose made very good sense indeed.

---

<div class="post-metadata">

**Author:** ![Jason](https://avatars.discourse-cdn.com/v4/letter/j/dc4da7/32.png) [@Jason](https://community.letsencrypt.org/u/Jason)\
**Post date:** [April 12, 2016, 10:18pm UTC](https://community.letsencrypt.org/t/certificate-transparency-logs-problem/14001/17 "2016-04-12T22:18:16Z")

</div>

Well, actually I submitted my certificate using the DST-signed intermediate. When I used an old certificate I had from LE X1 and provided the ISRG Root X1, submariner accepted that.

---

<div class="post-metadata">

**Author:** ![system](https://global.discourse-cdn.com/letsencrypt/original/3X/c/a/ca6c06ea1ea201324bba7048c6841ce60236468d.png) [@system](https://community.letsencrypt.org/u/system)\
**Post date:** [May 12, 2016, 10:18pm UTC](https://community.letsencrypt.org/t/certificate-transparency-logs-problem/14001/18 "2016-05-12T22:18:33Z")

</div>

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