On Mon, Jan 25, 2016 at 1:46 AM, Nikos Mavrogiannopoulos <n.mavrogiannopoulos at gmail.com> wrote: > On Sun, Jan 24, 2016 at 10:17 PM, Kevin Cernekee <cernekee at gmail.com> wrote: >> I set this up earlier today and ran into two issues: >> >> 1) `occtl reload` doesn't reload certs/keys, since they live in the >> perm_cfg. It would be nice if it did, just to avoid kicking off >> connected clients during the cert refresh every ~60-90 days. > > The difficult part when doing that, is to have some workers spawned > before reload with the old certificate in memory and accessing the > security module after reload with the new key. If the certificate > update process kept the old key, that would work, but if a new key was > issued not. We could of course make these fail with a temporary http > error. > >> 2) I added a new worker-http-handler to ocserv that would allow it to >> answer ACME challenges using the widely-supported "webroot" method, >> only to find that webroot is forbidden on TLS connections: >> https://github.com/letsencrypt/letsencrypt/issues/2150 >> Ideally, a VPN gateway could implement ACME without having to open up >> port 80. Has anyone found a way around this restriction? > > No idea. But if there is something that ocserv could do to automate > this certificate issuing let me know. I think that could be an > interesting thing to add. The other option is to set up ocserv to respond with a special self-signed cert to incoming connections that use a special SNI value: https://letsencrypt.github.io/acme-spec/#rfc.section.7.2 The special SNI value and the special cert are dynamically generated during the ACME exchange. If you wanted to build support into ocserv, you could accept the Z value through dbus and autogenerate the cert + SNI name. Not sure how "invasive" all of this is, though. One downside is that many ACME clients only support webroot. So I guess this would probably be implemented as a plugin for the reference client.
