On Mon, 2016-01-25 at 09:13 -0800, Kevin Cernekee wrote: > 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 All the described methods look quite complex to use for a simple server. The SNI thing it requires the server to generate a self signed certificate for this connection which is not the simplest thing to do. No wonder they use plugins to the server to make that work. It is certainly do-able but it is not trivial to add that support, and I find their selected protocol quite questionable. > 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. I would not like to introduce a dbus dependency just for that. occtl could be used to provide that input, but still the webroot that you mention below is far much simpler. > 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. Well the webroot thing can be combined easily with ocserv as it only requires the HTTP port. Isn't running a temporary HTTP server in parallel with ocserv a simpler solution? regards, Nikos
