=================================================== Awkward Certificate Management Environment (ACME) =================================================== I'm using ACME and Let's Encrypt since it became available, and quite happy that it is available, which is a large improvement over the scammy and manually operated CAs. Yet the ACME clients were awkward, and they stay that way still: the primary one wanted to run as root, and to edit configurations of other services; for some reason on CentOS a man page wasn't included, and on Debian it's just the --help output (which, for some reason, certbot prints with a perceivable delay). Everything is roughly the same still, but at least with some manual hacks it can run as an unprivileged user. And then there are alternative clients, which were/are incomplete and/or broken, leading to even more awkwardness. The only time I saw a person actually using certbot's nginx configuration capability (and running it as root, even though it's not necessary to edit configuration) was when they've also installed it on Debian from an Ubuntu PPA repository (while it was available from system repositories). I think it was a person who wanted to use Docker to deploy static files on a single server. I found it all to be quite fitting: "heavy-handed" describes both certbot's and that person's behaviours well. Actually there's quite a few people who like to do all the things as root, and generally to drop even basic security and safety measures in favour of convenience. The alternatives that I'm aware of and that are commonly available in system repositories don't seem to be much better though: I don't recall any that support RFC 2136 (dynamic DNS, for ACME's DNS challenge) on their own (without custom/external software), while it seems to me like the most sensible thing to support; certbot supports it with a plugin that is available from both CentOS and Debian repositories. Some clients are written as shell scripts, which made sense when it was new (ease of deployment, minimal dependencies), but doesn't make much sense now, when they are included into system repositories. I'd prefer a nice small ACME client, with good system integration, documentation, possibly only supporting the DNS challenge and RFC 2136, well-maintained, and included into system repositories. Upon looking around and not finding any, it crossed my mind to write one, so I went to check the ACME protocol specification (RFC 8555) more thoroughly. More awkwardness awaited there. The protocol's task seems simple: a client should be able to request and revoke certificates, proving control over the domain(s) it is for, and there already are standard CSR formats. ACME solves it by, among other things: - Adding account registration and authentication. With acceptance of ToS, which is probably the reason for that. - Including a directory service to provide URLs for various standard operations. That actually may include more (per-command) ToS, and assists with using external accounts (which are also supported by the protocol). - Including "url" parameter into JSON payloads, apparently to help ACME servers with sorting it out. And generally aiming to use common nowadays web-related technologies; it reads a bit like an ad hoc web service's documentation. - Implementing something akin to TLS-over-JSON-over-HTTP-over-TLS: handling replay attacks and authentication in a custom protocol while TLS is capable of that. Apparently it's assumed that a CA may accept connections from a third-party MitM service that would handle TLS connections on its behalf. - Extensively using base-64 encoding to encode binary data that should be included in a human-readable serialization format (JSON), inside human-readable network protocol packets (HTTP), both of which were chosen mostly to transfer that binary data. With base-64-encoded strings inside base-64-encoded strings in some cases. The feeling after reading it is similar to the one I had after using certbot and reading its documentation: it does the job, and it's not too bad overall if you take into account the target audience and other not-quite-technical aspects. But it's still pretty awkward, so I'm not happy to use it. I've ranted in an XMPP conference about it yesterday, and was reminded that TLS is an awkward/hacky way to achieve transport security in the first place. Indeed, IPsec is a generally nicer alternative to this. It's quite far from a viable option to rely on right now, but is worth looking forward to, and certbot/ACME then look more like temporary hacks until we are there. IPsec can rely on DNS (with DNSSEC), using either IPSECKEY (RFC 4025) or DANE's IPSECA (there's just a draft), and employ at least opportunistic encryption (RFC 4322). TLS can do a similar thing, with DANE's TLSA (RFC 6698), without relying on CAs; though I doubt that major web browsers and other potential clients currently support it. Though IPsec has its own problems, and criticized for being overly complex. But there is some hope for neat setups for secure networking in the future, and one can already start adopting some aspects of it. It may be particularly nice for protocols like Gopher and telnet, providing some security without changing them. ---- :Date: 2020-11-11