Automagic x509s via ACME


Privacy matters.

A few years ago Let's Encrypt launched, the ACME protocol became a standard and the Internet landscape changed drastically due to the easy availability of x509 certificates signed by a trusted authority.

A once manual and cumbersome process was turned into magic.

This fact meant that more websites could deploy TLS and better protect the memes and cat images they were serving their users.

Kore has always had TLS enabled by default but there was no easy way to manage your certificates and keys. For the upcoming Kore4 release I wanted to change that.

Since a few days ago, the master branch has gotten ACMEv2 (RFC 8555) support via this commit.

When enabled, Kore will automatically obtain x509 certificates for the domains you have configured and will auto renew them when required.

Currently it only supports the new tls-alpn-01 challenge. This challenge comes with the benefit you do not need another open port on your machine or talk to external DNS services. I may consider adding http-01 in the future and maybe dns-01 so that wildcard certificates can be obtained.

Security matters.

If you design a highly complex feature that parses untrusted data from the internet or handles private keys, and it is not implemented with privilege separation from the start, it is wrong and you should feel bad.

Having said that, the ACME implementation in Kore is of course fully privilege separated.

The way this works is that Kore will fork a new process (acme) at startup which is specifically used to communicate with the ACME provider you configured.

All Kore processes run inside of a restricted environment, be it pledge+unveil on OpenBSD or seccomp system call filtering on Linux. This also applies to the acme process.

This means the acme process is restricted in what it can do. As of right now the only thing the acme process can do is talk to the internet.

If the acme process needs to do anything that involves a private key (signing with the account key, generating a CSR, etc), it would ask the keymgr process to do so.

The keymgr process in Kore has existed since version 2 and has always held the private keys for your domains. During a TLS handshake the worker processes would ask the keymgr to sign the relevant data of the handshake to prove certificate ownership.

The tls-alpn-01 challenge certificates are also generated on the keymgr process and are installed in the normal worker processes who terminate incoming TLS connections.

Whenever the certificate becomes available, the acme process will download it and send it to the keymgr so it can write it down to disk. Once that is done it will instruct the worker processes to reload the certificates for said domain, and voila!

Look for acme support in the upcoming Kore4 release!

kore-blog v0.2