Expect-CT, SCT and Let's Encrypt

Hi There

Hoping for some help here.

I was relooking at HTTP Public Key Pinning but noted that Expect-CT was recommended as an alternative.

Then did some Research and it seems Expect-CT is now being deprecate in favor of SCT.

I found an article on this here: https://letsencrypt.org/2018/04/04/sct-encoding.html

From a longer term view is SCT the way to go and does anyone know if it's a config on web servers or clients to verify the certificate is authentic.

Andrei

3 Likes

Expect-CT and SCT are not competing technologies. The basic keyword here is Certificate Transparency (CT). CT is the process of publicy logging all certificates issued by a particular CA. This gives the entire certificate ecosystem more transparency and can help in detecting mis-issuance and other problematic practices.

Every publicy trusted CA nowadays logs their Certificates in a CT Log (multiple actually). These logs can be queried so that all certificates issued can be inspected. To have cryptographic proof that a certificate has in fact been logged to some CT Log, we use a technology called Signed Certificate Timestamp (SCT). These are delivered to the browser so that the browser knows immediatly "this certificate has been publicy logged". SCT's are delivered to the client (browser) either via a TLS extension, or are directly embedded into the certificate. The first solution requires manual configuration from TLS server operators, the latter solution doesn't need any configuration from the subscriber's perspective (e.g you). Let's Encrypt currently embeds SCT's directly into all certificates, so all Let's Encrypt certificates are automatically CT compliant, without additional configuration from server operators.

Browsers can choose to reject certificates that are not logged. Chrome does this for newer certificates. There was a transition period, which will end sometime this year, where the logging requirements only applied to some certificates - older ones didn't need CT yet, newer ones do. Once the transition period has passed, everything must be logged. The Expect-CT technology is a HTTP Header that webservers can send to indicate "this service is already CT compliant". This was useful in the early days of the transition to CT. Nowadays CT is already widely implemented and mandated, so the HTTP Header is currently being phased out. For Let's Encrypt certificates CT requirements already apply, so the header probably doesn't do anything anymore for these certificates.

A bit more info and detail about the CT system can be found here: https://www.certificate-transparency.org/how-ct-works

PS: I'm not sure how CT is supposed to replace the functionality of (HTTP) public key pinning. CT is not a pinning method.

10 Likes

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