On 05/08/15 13:11, Thorsten Glaser wrote: > Bas Wijnen <wijnen <at> debian.org> writes: > >> Certificates are placed in /etc/ssl/certs/. > > No, in /etc/ssl. /etc/ssl/certs/ is for Root CA certificates *only*. >
Now that Let's Encrypt is progressing (they are almost in beta[1] now), I thought it would be a good time to revive this thread Some thoughts which come to mind: - how does this relate to the way we store certificates and keys on a Debian system? Do we need to clean up the documentation[2] (also mentioned on debian-devel[3]) about the current state of things before we even consider the impact of something new like this? - should Debian have an abstraction layer on top of the letsencrypt command line tool? Let's Encrypt tell us that their tool provides a plugin API[4], so we could assume the tool is an abstraction layer that other CAs could support in future. - how to support this in postinst, without forcing anybody to use it? - is there any generic mechanism for a delayed/asynchronous action to be initiated from a postinst script? Such a mechanism could be used to allow the postinst to finish promptly, but later on, when the certificate is ready, the service would be started in a predictable and safe manner. - if postinst really needs to start services, should services be run with Snake Oil certificates on a temporary basis until the system receives a real certificate and automatically restarts the service somehow with the real certificate? I'm not keen on that idea, clients of the services may be more upset by the Snake Oil certificate than a connection refused error, but maybe it could be permitted with an administrative option. 1. https://letsencrypt.org/2015/11/12/public-beta-timing.html 2. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=790943 3. https://lists.debian.org/debian-devel/2015/07/msg00024.html 4. https://letsencrypt.readthedocs.org/en/latest/contributing.html#writing-your-own-plugin
