Not impressed, far too many serious problems

Help
1

The standard acme client is way too convoluted, complex and performs too many unwanted operations. I correctly assumed that the client was not suited at all for use on a production system.

The following issues are a no-go in my perspective, most performing unwanted operations:

  • Requiring sudo
  • Automatically update the package list
  • Automatically install packages
  • Automatically (and repeatedly) cloning external repositories
  • Automatically adding entries in /etc, /var/log, ~/.local/share and /var/lib
  • Automatically performing configuration changes
  • Too many arguments needed for basic operation
  • Unreadable, nonsensical error messages
  • No ability to clean up installed files

Many of these issues have already been expressed in previous topics but only for specific installations. To be honest a client should never ever perform the first 5 issues listed above. In regards to the 6th issue, a client should never assume “I are vebserver!” and either try to mess up your existing configuration or tell you to shut down the existing instance (seriously?).

The final command I used which borders insanity was:

./letsencrypt-auto -a manual -d domain.tld --agree-dev-preview --server https://acme-v01.api.letsencrypt.org/directory certonly -v --debug

Incidentally, the same command failed for the second domain I tried to register due to some UTF-8 conversion issue in it’s own configuration files. Removal of /etc/letsencrypt was required to proceed.

Simply trying to get the list of available command line options (ie. ./letsencrypt-auto --help) triggers full-blown system update and package installation.

Experience once again proves not to trust anything written in Python… Although I eventually succeeded in obtaining the relevant certificates, I will not be using letsencrypt in the foreseeable future. I thank you for making me spend 2 hours cleaning this mess from my system.

4 Likes
2

Just a couple of points:

  • The goal is to deliver letsencrypt the same way you get most of your software, via your distribution's software repository. This will solve a lot of your problems, especially dependency management, updates and cleanup.
  • The official client is actually more like a certificate manager. Its goal is to not only get you a working certificate, but to manage renewal and revocation and, if you wish, also your TLS server configuration. In that sense it is more like a system daemon than a client you run just once. This drives the need for sudo, and explains why it stores configuration and log files.
  • Two of the arguments you passed to the client are specific to the beta phase. The last two are used to get more verbose logs and stacktraces. Without all of those, you're down to 3 arguments. I wouldn't call that bordering on insanity.

Finally, this is where you lose me:

(Aside from Python being successfully used by any number of tech giants)
You signed up for the private beta of a CA and used a client that - to quote the README page

[..] is a DEVELOPER PREVIEW intended for developers and testers only.

Some of the issues you mentioned are completely valid, and should be looked into, but if you weren't willing to put time into this, you simply shouldn't have signed up for a beta and waited for GA.

3 Likes
3

The goal is to deliver letsencrypt the same way you get most of your software, via your distribution’s software repository. This will solve a lot of your problems, especially dependency management, updates and cleanup.

Ok, so why use pip instead of a PPA or a proper repo?

The official client is actually more like a certificate manager. Its goal is to not only get you a working certificate, but to manage renewal and revocation and, if you wish, also your TLS server configuration.

What you describe is no longer a client. Call it what it is: a certificate manager.

In that sense it is more like a system daemon than a client you run just once. This drives the need for sudo, and explains why it stores configuration and log files.

I fail to see why a client would need to behave as a daemon. Mind you that (unless you are a reseller) obtaining certificates is a once-in-a-blue-moon operation, it does not make sense to daemonize such sparse operations.

Two of the arguments you passed to the client are specific to the beta phase. The last two are used to get more verbose logs and stacktraces.

I’m aware, I required them for troubleshooting.

(Aside from Python being successfully used by any number of tech giants)
You signed up for the private beta of a CA and used a client that - to quote the README page

[…] is a DEVELOPER PREVIEW intended for developers and testers only.

I was not expecting a finished product or even a beta. However I do not think the direction that the reference client implementation is heading is a good one. I was expecting something that would simplify obtaining SSL certificates, not make it considerably more complicated.

I think the method used (ACME) for obtaining certificates is great. It allows full automation while at the same time provide authenticity of the requester. However, I don’t think that replacing a CURL one-liner with 33.100 lines of Python is the way to go.

1 Like
4

This is a DEVELOPER PREVIEW intended for developers and testers only.

Once the client is stable enough, distributions will probably start building packages and including them in future releases, as happens with most OSS.

Fair enough.

LE certificates are limited to 3 months. That's not just for the beta phase, and might become even shorter in the future. One of the project goals is to automate certificate deployment and push shorter certificate lifespans (so as to not having to rely on flaky revocation processes when keys are stolen). Maybe it's comparable to DHCP leases - no one has to think about those once your system is up and running, and there's probably some kind of DHCP client running as a daemon on your system.

That's the beauty of an open protocol like ACME, if your goal is to simply get a CSR signed, there are other, much simpler clients out there which do just that. The official client has a different target audience, and its complexity stems from being much more than that.

1 Like
5

Once the client is stable enough, distributions will probably start
building packages and including them in future releases, as happens with
most OSS.

Ok.

LE certificates are limited to 3 months. That’s not just for the beta
phase, and might become even shorter in the future. One of the project
goals is to automate certificate deployment and push shorter certificate
lifespans (so as to not having to rely on flaky revocation processes
when keys are stolen). Maybe it’s comparable to DHCP leases - no one has
to think about those once your system is up and running, and there’s
probably some kind of DHCP client running as a daemon on your system.

Interesting proposal, it would make revocation chains obsolete. How will you deal with offline installations (think appliances)? It is not uncommon to see some of these boxes with (often self-signed) certificates that expired 5-10 years ago.

That’s the beauty of an open protocol like ACME, if your goal is to
simply get a CSR signed, there are other, much simpler clients out there
which do just that. The official client has a different target
audience, and its complexity stems from being much more than that.

Fair enough.

1 Like
6

I see two options here.

  1. ACME becomes the de-facto standard for most CAs, and the manufacturers of various appliances which use TLS start implementing clients. This would be viable for stuff like routers or IOT devices with internet access. Solving challenges automatically would still be a bit difficult in that environment, but since solved challenges allow you to issue certificates for the next 10 months IIRC, you could automate the renewal and intervene manually once a year by solving new challenge.
  2. Your appliance provides some way to provide new certificates via an API of some sort. That way, the appliance doesn't need direct internet access. A separate host with access to both the internet and your appliance acquires the certificate and uses said API to push it to the appliance.

Hopefully, with TLS becoming basically mandatory in the future, that's not just wishful thinking on my part. :smiley:

1 Like