Using Let's Encrypt / ACME with ocserv

[Kevin Cernekee]

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.