Support ACME v2

[babolivier]

Currently Synapse only supports ACME v1, which has been discontinued for new accounts, meaning that the built-in ACME support is broken for everyone who weren't already using it before Nov 2019.

This is likely something we'd like to fix soon since we mandate valid TLS certs for federation and it doesn't feel great to not have a working way to automatically provision one.

In the meantime, users can use other ACME clients such as certbot which allow them to retrieve a valid Let's Encrypt certificate. They can then make Synapse use that certificate (and its private key) by setting, in Synapse's configuration file, the config options tls_certificate_path and tls_private_key_path to the path of the certificate (with its full chain) and the path of its private key respectively.

[botto]

Does it make sense for synapse to be doing this? Considering there are many options out there already that take care of it automagically? I'm thinking of traefik or alike.

[babolivier]

Does it make sense for synapse to be doing this? Considering there are many options out there already that take care of it automagically? I'm thinking of traefik or alike.

Sort of, yes, imho. Since we mandate that every federating server use a valid certificate, and we want the process of setting up Synapse to be as smooth and frictionless as possible, it sounds like a nice thing to have (especially since most people put a reverse proxy for the client traffic but not necessarily the federation one). Plus Synapse already has the code architecture for this (just that we somehow missed the warning about ACME v1 being deprecated), this is more about fixing a broken feature than implementing a new one.

[michaelkaye]

I found this out while updating gitlab, note that just moving to the v2 api is not enough; we also have to deal with a breaking API change that is currently applied to the staging environment only, and plans to be applied to the live environment by November 2020 -

https://community.letsencrypt.org/t/acme-v2-scheduled-deprecation-of-unauthenticated-resource-gets/74380

The upstream library (txacme) does not support API v2, and we should ensure we don't move to another library when working on this task without checking that library has fixed the above API issue - we could end up with a change that works for a few months before renewals start breaking.

[aaronraimist]

The error message to make this issue more searchable:

Account creation on ACMEv1 is disabled. Please upgrade your ACME client to a version that supports ACMEv2 / RFC 8555

[babolivier]

So we came to the conclusion that implementing ACME v2 ourselves, either in txacme (which is the library we're currently using for ACME v1) or in a library of our own, is non-trivial and, considering the amount of tools for generating and managing certificates out there, it's probably not worth it.

However, as of yesterday, there's been some progress on the txacme side to implement this (twisted/txacme#151 (comment)), so our plan is to update Synapse to support ACME v2 through txacme if it lands before June 2020 (which is when ACME v1 will definitely be shut down by Let's Encrypt). In the meantime, we'll update our documentation to let people know about the current state of the feature and how to deal with it.

[babolivier]

The docs have been updated so I'll move that to Done on our project board, but I'll keep this issue open in case there's a timely update of txacme we can support.

[richvdh]

let's close it for now and open a new issue if we decide more work needs doing.