Support for static certificate transparency files

[lenovouser]

Like this module allows it for NGINX

[mholt]

Thanks for your feature request! I need to brush up on the latest CT technology, but I think @sleevi_ has some good insight on this. It'll be important to consider the long-term effects of implementing this feature into Caddy.

[alex]

(Let me know if this should be a separate issue)

I think Caddy can do one better than static SCT files -- in the same way Caddy made TLS easier than any other server -- Caddy could automatically submit certificates to CT logs, and include SCTs in the TLS handshake, all without requiring any additional configuration from server operators.

[alex]

Looks like all you need to do to server SCTs from Golang's TLS is to include them in this struct: https://golang.org/pkg/crypto/tls/#Certificate

The only other step then is agreeing how we get our SCTs. I'm in favor of Caddy automatically submitting certs to logs (possibly only if there aren't already SCTs embedded in the cert itself), and using those SCTs to serve.

There's a small compilation in agreeing on which CT logs to submit to, but that's a small detail :-)

[lenovouser]

Sounds nice, even though the option for static generated *.sct's would be nice because I am not using Let's Encrypt because they don't support wildcard certificates yet 😄

[mholt]

Yes, I agree with @alex that Caddy should take care of this automatically if there aren't already embedded SCTs.

I'd be happy to discuss which logs to submit to as well.

@lenovouser

I am not using Let's Encrypt because they don't support wildcard certificates yet

Do you use the certificates for things other than your website?

[alex]

The first challenge, I think, is that different certs need to go to different logs -- for Google logs, Let's Encrypt go to Icarus, while everyone else goes to Pilot/Rocketeer/Aviator (this is all from memory, so I'm sure I got some of the names wrong).

Further, for non-publicly-trusted certs, submitting them to CT doesn't make sense -- they'll get rejected if they're not from a public issuer.

Perhaps for v1 of this we should have people opt into which logs (which no one will actually know how to do probably) with a default for Let's Encrypt (which will work automatically)?

If that sounds good, I can try to make some cycles for this.

[lenovouser]

Sounds good, I use the certificates only for websites and things like a mailserver @mholt

I've tested all transparency servers listed on certificate-transparency.org/known-logs for Let's Encrypt and these ones accept their certificates:

ct.googleapis.com/pilot
ct.googleapis.com/icarus
ct.googleapis.com/rocketeer
ctlog.api.venafi.com
ctlog.wosign.com

[mholt]

@alex

Perhaps for v1 of this we should have people opt into which logs (which no one will actually know how to do probably) with a default for Let's Encrypt (which will work automatically)?

That's reasonable -- I wonder how this would be exposed, maybe a ct subdirective in the tls directive? And yeah, I think we can definitely have it "just work" for Let's Encrypt certs, which is I bet 90-95% of Caddy users that don't meddle with the TLS configuration that much or use their own certs anymore.

[mholt]

I have a gut feeling this feature would be supplanted by SCTs embedded into certificates, like Let's Encrypt will start doing hopefully this year, so I think that would eliminate the need for us to need to implement this. :)