I set up a con job on a Linux server to renew the Let’s Encrypt certificates with certbot, but having given it more thought, I am going to disable the cron job.
In order to update the certificate, the following has to happen.
Get new certificate.
Shut down Apache
Install new certifcate
Hope Apache restarts.
If there’s a problem with any of the certificates, Apache is likely to not start. So my company website would remain down.
There’s also the remote possibility someone is making a purchase on the website, as the server is shut down.
Given it is possible to revoke certificates, I really fail to see the need to have a 90 day expiration date. Perhaps let people have the option of a 90 day certificate, but a longer period should in my opinion be the default.
Given all the main CA (Comodo, Verisign etc) offer certificates of one or two years, I really can’t see why Let’s Encrypt should have this 90 day limit. I read
and it talks about automation. Am I the only one to think the website administrator should take down the webserver and check its working?
I’ve written an email to the members of my club, saying we will have to buy a certificate, as I can’t risk automatic renewals. With it possible to get 1-year certificates for less than $6, the money Let’s Encrypt will save is not enough to warrant the risks that automated updates cause.
Why does it need to happen like that? That's not a requirement of the authentication process. It is however a possible method of authentication, but that most likely is a choice made by you.
Apache can do reloads instead of restarts. Of course, the single processes of Apache need to restart with a "reload" too, but it will be done in a graceful manner so current connections won't be interrupted and there won't be any downtime. Also, most reload-scripts run a configuration check and won't reload Apache when there's a configuration error.
How do you mean that? There's no reason to take down the webserver to configure renewed certificates.
Further more, there has been a TON of discussion about the 90 days limit. You're not the first one obviously. Search the community if you like. And even with the amount of discussion in the past, the 90 days limit stands. There's not a very likely chance anything would convince Let's Encrypt to change that. Even more, Google was thinking of a certificate life time of only a few days, so there wouldn't be a reason for revocation checking, as revocation checking is mostly flawed anyway.
As @Osiris says, only (1) on that list has to happen. There's absolutely nothing to do to "install" the new cert (with any of the popular clients, and certainly with certbot, the path to the cert and key files remains constant through renewals). If you insist on shutting down apache, the list would look like:
Get new certificate
Restart apache.
...which would give you about 2 seconds of downtime while apache restarted. But a better approach yet would be:
Get new certificate
Reload apache
...in which case you have no downtime at all.
What sort of problem do you anticipate that would cause this? If issuance fails, /etc/letsencrypt/live/yourdomain/cert.pem and the other related files will still point to the last-issued cert, so Apache runs just fine.
Yeah, I think you probably are.
Edit: But if you're convinced that you need to manually test and install each new cert, then I think you're right that you'd be better off with a different CA. LE is explicitly designed around the idea of automated issuance and renewal, and makes few (if any) concessions for manual use.
It’s weird to see a post against automation, it’s one of the best ways to achieve predictable and verifiable outcomes in operations. Most configuration failures are the human’s fault.
Just to add to the others, Certbot already performs configuration tests and rollbacks in its installers (Apache, nginx), so while external factors may cause it to be unable to perform a renewal (and you’ll eventually be notified of that by email), it should never break your web server on its own.
Yeah, I think that's a new one. We've seen, of course, posts arguing that the 90-day lifetime makes manual issuance/deployment more of a pain (over and over and over, oblivious to the fact that LE simply doesn't care about this use case). But I think this is the first post trying to claim that automated issuance/renewal is in itself a bad thing.
There are different use cases. For your domain, a EV-certificate makes sense. There is one company.
But in other use cases, an EV isn't a good idea.
Sample: I have customers, every customer has his own subdomain. There are "hidden customers", so a certificate per subdomain isn't a good idea (because of certificate transparency). So I use a wildcard-certificate.
But this is only domain-validated. Because it would not be a good idea if one of my customers would have a subdomain with the name of my service as EV-name.
The manual change is terrible. So ACME-v2 is wonderful. 90, 100 or 180 days? Not really relevant.
Personal, I would prefer certificates with a 110-day-lifetime and a regular renew after 90 days. But this is not really important.
That would be a silly way to get an EV cert; it would rather be issued in the customer's name. For whatever value there is to EV certs in the first place (and I question what that value is).
If renewal is automated, why does it matter? What difference does it make to you if the certs are good for seven days, and (by default) renew after four?
Okay, I was mistaken. I thought that the server had to be restarted, but reading the Apache documentation, it would appear it can be reloaded, and most (but not all) configuration errors would be detected.
Also, the reload can be triggered by the ACME client only upon successful renewal. So there’s no reason that an automated reload or restart has to happen following an unsuccessful renewal attempt. This is the default behavior in most ways of using Certbot.
I want to point out that when we started writing Certbot, I actually specified something like what you suggest and even wrote some code for it. The idea was that there was going to be a separate “renew” and “deploy” step which by default would be separated in time by one week. Both of these steps would default to being automated, but the system administrator could choose to examine the freshly renewed certificate and configuration in between, and potentially take some action to prevent the new certificate from being put into use. If the system administrator took no action after one week, the certificate would (by default) be automatically “deployed”.
I took this approach because I thought that many of our users would basically have the same preference that you’ve expressed, coming from non-automated certificate environments, and would frequently want to examine the new certificate to make sure that it was what they wanted and expected, as well as potentially controlling the timing of its entry into production.
This distinction no longer exists in Certbot because we found almost nobody who ended up expressing this preference. As well, the usual behavior of certbot renew can fail (without causing downtime or spurious restarts), but it rarely produces changes that annoy sysadmins. (I guess an exception is with cert pinning, where the subject public key would change at a random and unpredictable time due to automated renewal, prior to my recent belated work on the --reuse-key feature.)
Anyway, your preference turned out to be extremely uncommon, at least in light of the way that our client works, but not only does it not seem silly to me, it’s actually what I first assumed most users would want! Although Certbot no longer includes a complete implementation of this, it should be relatively easy to make various ACME clients give the sysadmin an opportunity to be more involved in the renewal process, whatever that means to the individual sysadmin (perhaps receiving an e-mail with the output of openssl x509 -text for the new certificate before it gets used, perhaps receiving a note that the certificate exists but hasn’t been reinstalled, perhaps performing an Apache configuration parsing test, or whatever). I can see that the 90-day validity period could make this quite a bit more annoying compared to a longer validity period, but hopefully each sysadmin can still find a balance between control and convenience that suits his or her own preferences. That is, the automation of certificate renewal doesn’t have to be done in a one-size-fits-all way.
One way to replicate that original behavior in the current setup would be to have a weekly cron job, and reload the server before obtaining a new cert. A paranoid administrator can always examine the certificate at their leisure, and change the symlink back if they feel something’s wrong.