search

hlandau / acmetool

:lock: acmetool, an automatic certificate acquisition tool for ACME (Let's Encrypt)
https://hlandau.github.io/acmetool/
2.06k stars 129 forks source link

Investigate support for storing SCT in a file #3

Open hlandau opened 9 years ago

hlandau commented 9 years ago

What webservers can consume this, besides HAProxy?

wiktor-k commented 8 years ago

Nginx with a custom plugin:

https://github.com/grahamedgecombe/nginx-ct

hlandau commented 8 years ago

That's two.

Still, at some point LE will start stapling SCTs to OCSP responses (which can be stapled themselves): https://github.com/letsencrypt/boulder/issues/592 So I wonder about the utility of this.

wiktor-k commented 8 years ago

Yep, it's a low priority IMHO.

Last time I checked some CA considered distributing SCT via TLS extensions to be the "correct approach" though. See: https://forum.startcom.org/viewtopic.php?p=21381&sid=3ca262ae78a1e69f299c08ff9990e015#p21381

grahamedgecombe commented 8 years ago

I've been using a live-updated hook to achieve this together with ct-submit.

Here's the hook:

https://gist.github.com/grahamedgecombe/a9d662911c45445001ee93378d011ac9

It's not a perfect solution: the live symlink has already been swapped by the time live-updated is called. If one of the log servers you submit to is down, you could end up using the certificate without having the desired number of SCTs.

It only supports the SCT file format used by Apache and the nginx-ct module. HAProxy uses a different format and isn't supported.

It'd also be nice if it used a human-readable file name for the .sct files, instead of the SHA-256 hash of the log URL.

hlandau commented 8 years ago

Neat. I've added a mention to the user guide's third-party resources section.