Will you support 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

1 Like

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.

1 Like

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.

1 Like

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.

1 Like

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

1 Like

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

1 Like

[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…

1 Like

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.

1 Like

Apologies, I was skimming messages too fast and misinterpreted this one. We’re not planning to offer embedded SCTs by x509v3 extension anytime soon. We’re going to stick with the OCSP stapling method for now.

Well, although my preference would be a x509v3 extension, it shouldn’t really matter: OCSP Must Staple is on the horizon and everyone in “TLS land” should be eager to implement it (because revocation checking is de facto defunct as it is right now…) So I’m good with the OCSP stapling method. Hopefully https://github.com/letsencrypt/boulder/pull/1224 can land soon!

Unfortunately, my feature request for Chromium isn’t really taking off… :confused:

By the way, from https://github.com/letsencrypt/boulder/pull/1397#issuecomment-173685359:

My understanding is that Let’s Encrypt is not very interested in precertificate-based SCT stapling since it requires each certificate to be issued twice, putting pressure on HSMs.

Currently, only 3⅓ % of the load on the Intermediate cert HSM would be for signing the original certificate. 96⅔ % of the load comes from OCSP signing. (OCSP is signed every 3 days, 90 days lifetime = 30 OCSP signs per certificate, compared to 1 signing of the certificate itself.) So if you’d increase the original certificate signing with one, i.e. doubeling it, it would approx. require 6.5 % of the load (2:31) compared to 93.5 % for the OCSP signing in that scenario.
Ofcourse, there would be some increase in pressure, but would it matter a lot, if you look at those numbers?

1 Like

FYI for anyone coming across this thread today, the answers have changed. We never implemented OCSP-based SCT delivery. We did implement precertificate-based SCT delivery. More discussion at Generate a certificate without Certificate Transparency.