Using Let's Encrypt / ACME with ocserv

[Nikos Mavrogiannopoulos]

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