SCT feature support

Regarding @jsha’s announcement at

https://community.letsencrypt.org/t/signed-certificate-timestamps-embedded-in-certificates/57187/2

I looked at newly issued certificates in CT and didn’t see the SCTs themselves but rather a “CT Precertificate Poison” extension. This makes sense because what’s submitted to the CT logs with this technology is not the certificate itself but rather the precertificate.

When I visited a site with a newly-issued certificate, I confirmed that it did have the 1.3.6.1.4.1.11129.2.4.2 OID. So, it superficially looks like this is working smoothly for a randomly-chosen certificate (though I didn’t attempt to validate the contents of the extension). Unfortunately, Chromium didn’t provide an apparent way to confirm that the SCT is valid—I would have thought that feature would already have been rolled out even before the SCT enforcement took place.

https://dev.ssllabs.com/ssltest/ does test it (the “Certificate Transparency” line)

image

Example: https://dev.ssllabs.com/ssltest/analyze.html?d=letsencrypt.org&s=23.194.83.30

1 Like

Great tip! I tried it with a random recently-issued certificate and it also came up successful (although I don’t know for sure if it just verifies the presence of the OID vs. verifying the content of the SCT or what).

1 Like

Chrome does provide this, but it’s a little bit confusing to find. There are instructions at https://www.certificate-transparency.org/certificate-transparency-in-chrome.

In particular: the CT status is not provided as part of the Certificate Viewer, it’s part of the Security pane of DevTools. Once you open DevTools, reload the page, then click on the main origin on the left side. Then scroll down to the bottom on the right side.

1 Like

Awesome, that method also worked for me and validated properly on a new LE certificate. I didn’t realize that you had to click on the origin in order to see that additional data.

Indeed!

(and that section is absent when there is no CT information)

You can choose to log the certificate as well, RFC6962bis will create a new document type explicitly for pre-certificates so that this "poison" extension isn't needed and we can avoid all the acrobatics needed in documentation to say that these sort of are and sort of aren't "real" certificates. (e.g. Mozilla wants to be able to smack CAs that log a crap certificate even when they insist they never "really" issued it after logging it, but on the other hand we don't want to require that pre-certificates have the wrong serial number in them even though two X.509 certs with the same serial number is a problem...)

I don't think there's any particular reason for Let's Encrypt to log the finished certificate, certainly not in 3rd party logs, but nothing stops other people sending them in, and if your log partners are OK with you doubling their input volume you could harmlessly do this.

1 Like

One reason that's recently been endorsed on ct-policy or somewhere is that it allows people to survey the ecosystem and see what logs are actively in use to help see, for example, how disruptive it is to distrust a particular log.

(I don't think Chrome will block a certificate using embedded SCTs from a later-distrusted log, though?)

1 Like

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