Will you support Certificate Transparency?


Will Let’s Encrypt support Google’s Certificate Transparency (CT, see [certificate-transparency.org][1]) by:

  • attaching a signed certificate timestamp (SCT) to a certificate using an X.509v3 extension or
  • enabling the client to deliver SCTs by using a special TLS extension or
  • using Online Certificate Status Protocol (OCSP) stapling?

In contrast to the last two mechanisms, X.509v3 extension does not require any server modification, whereas OCSP stapling does not delay the issuance of the certificate, since the CA can get the SCT asynchronously.

Source: “[How CT works][2]”
[1]: http://www.certificate-transparency.org/
[2]: http://www.certificate-transparency.org/how-ct-works

Certificate transparency submit
Certificate Transparency + X.509v3 Extension
[Google Chrome] Announcement: Requiring Certificate Transparency in 2017
Apt repository and SCT support

We’re planning to submit certificates to CT logs, which we think is the most important part: being transparent and open about the certificates we issue, and allowing the public to research and analyze them. If we provide SCTs, it would be via OCSP, definitely not by X.509v3 extension. But we’re not yet sure if we’ll provide SCTs via OCSP at launch. In particular, necessary support for OCSP extensions seems to be absent from Golang. However, subscribers who want to provide SCTs with their certificates should be able to fetch them directly from the CT logs and provide them via TLS extension.


Why “definitely not” by X.509v3 extension? It is easier and requires no additional, “painful” configuration… This “definitely” worries me a little…


Using x509v3 extensions would require that we block issuance of a certificate on the retrieval of some pre-determined number of SCTs, whereas storing the SCT in OCSP responses allows us to issue a certificate asynchronously of this process. Additionally verification of SCTs embedded in OCSP responses is handled in the same manner as those embeded in x509v3 extensions, so no extra client configuration should be necessary.

How easy is setting up certificate transparency?

Thanks for addressing this, do you have any resources or implementations for the TLS Extension method of delivering SCT’s that you can direct me to?


@spunkyspunktech: Tom Ritter has a good guide on how you can setup Apache to serve SCTs via TLS extensions here – https://ritter.vg/blog-require_certificate_transparency.html


OK, accepted, but why not allow someone using a config option from the LE client (eg. --embed-sct) to have this X.509v3 extension? The default would be not to embed, but it seems better if we COULD do that…


I agree with this! It seems very painful to set up webserver to deliver sct via TLS extension, and OCSP requires the CA to enable this for SCT, which LE may do at launch, if at all. OCSP also require OCSP stapling on the server, and to use the OCSP extensions.


I agree that it’s painful to set up a webserver to deliver SCT vis TLS extension. However, keep in mind that, for now, browsers do not do anything with attached SCTs for non-EV certs. That’s why we’re focusing on log submission right now.


Can I ask something: Is it so painful and time-consuming to write code to the CA so as to generate (the CA would do that either way since it submits to logs) and embed an extension to the certificate? DigiCert and COMODO already support embedding SCT for ALL types of certificates. I currently have COMODO PositiveSSL and I am great with my embedded SCT (after contacting support at comodo dot com, of course, but still I HAVE IT).

My point is: Why not implement it? It isn’t that difficult after all…


It’s significantly more complicated than it sounds, actually. I’d encourage you to read the relevant section of RFC6962. In effect, the CA has to issue the certificate twice. First you generate a precertificate with a critical poison extension, then submit it to a CT log, receive the SCT, and then sign it again. There is potential for failure and delay at each step in the process, plus significant additional complexity, which is why the authors of the CT spec included easier options.


Also note that currently if you want Apache to serve SCTs you must use a patched version built from source as the stable branch doesn’t have these features yet, making it even harder for the LE client to try to set this up.


You’re right in the sense that browsers don’t require CT for non EV certificates, but chrome does show whether any DV/OV/EV certificate is supplied with valid certificate transparency information.
And also allows you to view this transparency information: Screenshot


Hopefully LE will be using OCSP to submit and serve SCT’s.
In time SCT delivery via TLS extension will become simpler…


[quote=“jsha, post:2, topic:222”]
If we provide SCTs, it would be via OCSP, definitely not by X.509v3 extension. But we’re not yet sure if we’ll provide SCTs via OCSP at launch. In particular, necessary support for OCSP extensions seems to be absent from Golang.[/quote]
There is no “SCT via OCSP” as of now…
Does LE wait for “Golang to support OCSP extensions”?
Or it is “low priority thing” (and as such has no ETA at all)?

It’s not a complaint, just wondering, what’s the plan on it :slight_smile:


Hi, it is wrong defined there is an definition how CT can be provided by OCSP-Stapling.
I think this was what je meant with OCSP.


[quote=“tlussnig, post:16, topic:222, full:true”]
Hi, it is wrong defined there is an definition how CT can be provided by OCSP-Stapling.I think this was what je meant with OCSP.
[/quote]I’m referring to https://www.certificate-transparency.org/how-ct-works OCSP Stapling paragraph.
I.e. once LE adds SCT to its OCSP response, a client will get it too (via OCSP Stapling)


I would also like to see this. After going to all the trouble to log the certificates, having it visible in the certificate makes it special.


@jsha If I code X.509v3 extension support for CT with an additional flag required (e.g. --embed-sct at the LE client), will it get accepted by LE or not? Because there is no reason for me to try to do that if LE isn’t going to accept it after all…


We’re getting close: see @hlandau’s pull request. If you’d like to contribute code to the implementation, I’d suggest coordinating with him to make sure you don’t duplicate work.