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.
Hi, could you link any source where this information came from ?
Hello @tlussnig,
Certly removal 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
Cheers,
sahsanu
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.
However, something needs to be done, since now Let’s Encrypt users cannot obtain any trusted non-Google log proof for their certificates!!
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.
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.
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.
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/
We’ve applied for inclusion in Symantec’s, DigiCert’s, and Venafi’s CT logs. Currently none of them have accepted us.
@jsha By “accepted”, do you mean they refused or did not answer yet?
This is obtained using my certificate and the DST-signed LE X3 intermediate:
sending request to 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
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
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
unable to submit certificate to log, HTTP error 400 Bad Request: {
"error_message": "Invalid Request.",
"success": false
}
sending request to 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
unable to submit certificate to log, HTTP error 400 BAD REQUEST: A trusted root was not found.
sending request to 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
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
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
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
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
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
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=
@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).
@jsha thank you for all the details
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 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.
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.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.