Conceptual Issues with operational handling of letsencrypt

1

Hi there

Let’s encrpypt is finally in open beta so I can test this out. I have a background in operations and I have already configured and deployed certificates in the past. As an operations guy I have to maintain multiple servers and so I want my stuff to be mostly automatic and provide monitoring in case something goes wrong.

What I found out so far makes me wonder if I want to ever use Let’s encrypt again sadly. Maybe you can help me out in giving some insights, perhaps I misunderstood the concepts behind it:

  1. The python client is all well and good, but boy it installs gcc on my servers as a dependency. Build utils on a server? Come on. I know this is probably used by some crypto libraries within python (that needs to compile c code). Is there any way to disable this automatic dependency checking and virtual env. creating and just use the tool? I hate software that updates itself because this potentially can break dependency chains for other software I run on my servers. WHen I do updates I wan’t to be in control of it. And did I mention it installs gcc?

  2. So if I have multiple servers what do I do with my registration keys? I suspect that as soon as I enter a email address the key is bound to the email address and vice versa. So if I start the client on a different box with the same email address I will get an error, unless I copy the registration key to that machine also? So in the end I copy my private key that is used for authentication in ACME to potentially many sites that can be attacked. Doesn’t that increase the attack vector for that key? Isn’t that really bad? Because this key doesn’t change at all (in contrast the key of the cert change often, because of the 90 day lifecycle)

  3. What I really would enjoy if there is some possibility to have a central way of creating and monitoring certificates. Currently I have to install and run letsencrypt on all of my servers. What I want (for ease of operations really) to have all in one place (which would make point 2) also fairly more operation friendly), that I can also put somewhere safe (behind firewalls and shit). That way I can also monitor everything from there. As a operations guy I’m really happy if I can do monitoring and operations from one point and don’t have to login to 30+ servers every 90 days just to update certificates. I probably can fiddle around here and do “webroot/certonly” requests and mount all directories on one machine and do everything from there. But I rather don’t do that.

  4. As far as I understood, currently the client is not renewing anything automatically? Which defeats the whole points about that 90 day lifecycle. Also I want to monitor in case something went wrong during renewal process. Yes I can create scripts and do this stuff, but come on, should your software do this? That’s what’s advertised: one tool for everything. Currently it isn’t.

  5. What about appliances, where I can only upload key/cert via a webinterface to secure them? I definitely don’t want to do that every 90 days?

That’s mainly the points I found out during my (albeit it somewhat limited) testing. As I said I’m looking at this from an operational point of view, as a guy that has to operate more than one site, and already has a running config (I don’t want letsencrypt fuzzing in my config) . Maybe I’m not in the focus group of this project and I’m a fringe case nobody cares about.

I really like the idea of a free CA (currently I’m using certificates from some Chinese CA that are free, but I’d rather not do that anymore). If I have to renew my certificates every 90 days, I really want no additional operational cost. Currently the cost is too high, I have to do too much manually, which I don’t like. Of course everything is in beta, but that shouldn’t be an excuse. But this may be also a showstopper for others to adopt letsencrypt as their CA.

What I want from my client is basically:

  • one binary without dependencies (or very little)
  • monitoring to some central service
  • automatic renewal
  • use webroot/certonly for certificate creation
  • if possible: central utility (meaning I can control certificate renewal for all my servers from one point)

Maybe there’s a client tool out there already that does this, but I didn’t find any. I probably go and create one myself if there’s isn’t any and if maybe someone is also interested in something like this.

1 Like
2

There are a number of other clients, some of which will probably suit your requirements much better, a list is at

1 Like
3

There are multiple other clients, many without automatic dependencies.

Nothing is bound. You can update your email at any time (the official client doesn't have support for that yet). Additionally, you can have multiple accounts with the same email.

There's a suggestion for account key roll-over, but I don't think it made it into the standard yet. Generally, your domain keys are not necessarily new ones everytime, it's just the official client that defaults to it.

You can totally script that so you can use it in a central way. With webroot authentication, you just need to script the file provisioning.

Just put it into a cron running every 60 days. This will improve before the beta label is removed.

You have to wait until these either support ACME and make the interface obsolete or script it.

1 Like
4

Thanks for your clarifications. I now found acme-tiny to fit my needs the most. The official client seems to want to do a bit too much then. Oh well. It’s beta after all :slight_smile: I still have to work out some bits and pieces about monitoring and centralization (I want to do as little scripting as possible as this always introduces another factor for errors). Maybe there’s something I can produce, that can benefit the community back.

Thanks again guys.

1 Like
5

I wonder if this means LE has less than 89 days now to get auto renewals working in LE clients ? @bmw @jcjones what if some folks don't update their LE clients (3rd party included - fragmentation of 3rd party client concerns) to latest one that supports auto renewal and they haven't setup their own auto renewal process ? They would reply on the email notification for renewal right ? But as email rego is not compulsory what about folks who didn't register an email address and do not have notifications nor did they update their LE clients ?

6

Those people just have to monitor it themselves. But a cron every 60 days isn’t the right way anway, because it would make the certificate expire in case of a single downtime.

1 Like
7

You can do, each N (for example 5) days, check how many days until the cert expires (even bash has a function for this), if is lower than 30 do a renew.

8

Sure, but currently you have to do that yourself.

9

Since monitoring seems to be the trickiest part currently I whipped up some simple program, where you can enter all your domains and it regularly checks the certificates.

You can get it under: https://github.com/drtoful/certinel

It even provides you with a simple API were you can get all the needed information. Especially the remaining days a certificate is valid.

2 Likes
10

I just created a script as well - https://github.com/srvrco/checkssl - I’ll have a quick look at yours and see if we can combine etc.

1 Like
11

indeed I am doring the same as @Octal, i setup a cronjob to run every 9 days to check all SSL certificates on the server and if cert expiry date is less than 30 days run webroot based auto renewal

1 Like