The 90-day lifetime is actually a little awkward. 93 days would be right for doing 4 replacements per year – you could set a cron job to be run every 3 months – but, I’d go for 95 or 100 to allow some overlap. That way, if something goes wrong, you still have a few days to get the new certificate in place. It also works out a bit better for anybody who, for whatever reason, can’t/won’t do the automated installs.
Similarly, I’d not do 180 days but 183 or 190; and not 360 or 365 (or 366!) but 370 or 375.
As it is, with 90 days, I’d go for a cron job every two months or some careful setup to get a new cert every 73 (occasionally, 74) days.
Currently I support longer expiry, although its entirely possible my view may change.
The issue I have right now is I am not keen on non interactive certificate cycling, if an error occurs during a swap out of certificates it can have very bad consequences.
In addition this also means having a very short HPKP lifetime to allow time between the short warning of upcoming expiry from lets encrypt and new certificate deployment.
It is good lets encrypt has encouraged me to write scripts to automate certificate tasks, such as creating CSR’s and copying of certificates to production configurations, but I am only ok running these scripts currently interactively, not via crontab’s. There is also the matter that certian software such as directadmin is designed to be interactive only for installing certificates, expecting the certificate to be pasted into the UI by the end user. If the UI is bypassed and the certificate is copied directly to the configuration folder, it is reverted when directadmin next update’s its templates.
So in the long term, I think automated deployment is a good thing, but I think these very short expiries are too soon. I would think its better to start off at 12 months and then every couple of years reduce it progressively, so e.g. in 2 years 6 months, then 2 years after 3 months.
Also a final note the official lets encrypt tool doesnt work properly on my FreeBSD servers and I am using an unofficial one which doesnt do any auto installing, it just generates the cert (hence me writing scripts), so this doesnt help matters either.
For sure the email alerts for expiring certs need to be at 30-45 days not 17 days.
So I just had to pay for a SSL certificate for a shared host for one of my domains.
They are a smaller shared host, and very interested in Let’s Encrypt. Right now the way they have their servers set up they say it is difficult for them to implement the auto renewal process for site owners at this time, but they are looking into it.
They have good prices and great support, so I don’t want to leave them after 13 years of service. They don’t have a problem with installing Let’s Encrypt certificates, they just don’t want to deal with manually installing them for everyone every 90 days. If they can work out an implementation for the auto renewal to work for their setup, then it wouldn’t be an issue.
So perhaps make 90 days the standard lifetime, with a CLI Option for a 1 year lifetime?
It would have saved me some money spent on a “B” rated certificate, when I could have had a Let’s Encrypt Certificate with an “A” rating instead, like the one I installed on my VPS hosted server (Rating comparison from Qualys SSL Labs).
The problem with offering certificates with a lifetime of one year is that it will fail to motivate users to automate their process. The goal of this project is not just to give everyone a free certificate, but to encourage best practices - which includes short certificate lifetimes to make revocation less of an issue, as well as favouring automated processes as opposed to manual, error-prone ones - so adding a one-year option would go against those goals.
Note that the SSL Labs rating is mostly about your server configuration (allowed TLS ciphers, security headers, etc.), and not really about the certificate (unless it's essentially broken, at which point you'd get worse than a B).
the certificate area is literally a hit or miss, either you get full or no points (when you get no points you usually have marks like T or M for trust and mismatch when there’s something wrong along with an info what mark you would have gotten if that part would have been ignored, I often had a T/A or T/B with CACert.) there are parts in the cert that will concern the other parts but that are mostly under your control, for example your keylength.
[quote=“My1, post:306, topic:4621, full:true”]actually replacement is recommended every 60 days[/quote]Yes… and against that I have much the same argument. A 60-day interval doesn’t map onto cron configuration very well, whereas a two-month interval does. For that reason, the recommendation should be for replacement every two months.
I’d be highly unsurprised if that 60 days turns out to have been widely interpreted as two months, despite it only being so for any 60-day period which includes the last day of February in a leap year…
It doesn't matter, it really doesn't. They actually recommend you set up cron to renew every day, because nothing will happen unless you have less than 30 days before expiry.
Why is this an issue for you? I don't understand the problem, I have no idea how "93 days" fixes anything for you. You can renew at absolutely any time you want with the -renew-by-default flag, or at any time once you've hit that last 30 days. There's even a flag designed for cron use to ensure the renewal attempt is silent unless there's a problem.
Since all the software that uses the certificates (e.g. Apache, Postfix, Dovecot, etc) should be pointing to the "live" symlinks, it's a set and forget system. Once configured, you never have to do anything regarding the certificates ever again.
I have cron attempting renewal once a week. That gives me three or four attempts just in case Let's Encrypt's servers are down, and of course I get the cron email along with the rest of the weekly system reports, giving me weeks to fix any issue.
What is all this "mapping" talk about? If using cron is so difficult, just pay for a year long certificate and be done with it.
wasnt that actually one of the problems with manual issuance (or rather a "problem" that ppl brought up, I think that's junk because getting a cert from Startssl or even CACert [I know they aint trusted yet, just as comparison] is fairly easy) that ppl may forget how to get a new cert or when the responsible ppl change.
when there's a sys crash and LE has to be set up all-new ppl might forget that even more because it might have run years b4 that.
especially considering automation getting a LOT harder when having multiple webroots for a SAN.
Is Let's Encrypt really that difficult to wrap your head around?
...or restored from the backup you made. You are making backups, aren't you? Oh well, I guess you'll have to start from scratch, and spend a whole 5 minutes refreshing your memory with "letsencrypt --help".
The time-consuming part of starting fresh is configuring the OS, or Apache, or Postfix, not obtaining the certificate. It sounds like you're saying other CAs are better because they require more maintenance. I know I'd rather spend minutes reacquainting myself with Let's Encrypt once every several years instead of being required to regularly maintain something that doesn't actually require change.
I'm genuinely baffled by this comment.
Do you know what it takes to automate renewal of a single domain in a single certificate?
"letsencrypt renew"
Do you know what it takes to automate renewal of multiple domains in a single certificate?
"letsencrypt renew"
Do you know what it takes to automate renewal of multiple domains in a multiple certificates?
"letsencrypt renew"
How is this getting a LOT harder?
I'm not trying to be insulting here, but this thread has over 300 comments where people like you are basically pretending that doing nothing is impossibly difficult and confusing.
the whole verification part. I have yet to see a way for the official client to support multiple webroots for one SAN cert.
also having to do each and every subdomain for verification is especially painfil if your system doesnt have an LE client (official LE client only supports Linux and when using it in full auto mode with serrver integration even that gets limited down to like 2 or 3 distros. Also all dedicated windows clients are IIS only, making Windows Server + Apache only possible with a manual mode (as I tried with my raspi where I SSH’ed in and had to copy the text into a file and save it with the specific filename making this overly complicated, when you have a lot of subdomains but not many root domains to take care of. in Startssl or CAcert I get a email in the whois or admin address enter the code/click the link from there and I can work on the whole domain including subdomains)
There's also --webroot-map, which accepts a JSON dictionary mapping domains to webroots.
I think we can all agree that certificates with short lifetimes are only practical with clients available for most major platforms (that's including OS and server software). However, I disagree with the idea that policy decisions should be made based on a lack of clients for a small subset of platforms. This project hasn't been live for even a year, and we already have more than 30 clients (on the client wiki alone) for nearly every platform and use-case. If there's enough demand, I'm sure someone will write a client for apache on Windows. In the meantime, many existing clients for Windows already support something like the webroot plugin, so as long as you're willing to do some scripting, it's fairly easy to use this with any web server that has the concept of a DocumentRoot. Here's an example for letsencrypt-win-simple and apache: How to install a Let’s Encrypt Certificate supports SAN to Apache on Windows. – o6asan's soliloquy.
The official client is now being shipped as a package in a number of linux distributions (Debian, upcoming Ubuntu, etc.) Those packages are frozen at whichever version of the client was available at the time. Many of those distributions have support cycles of > 4 years. I'm sure introducing changes that would break compatibility with any of those clients is out of the question.
I use the official client, and I used multiple webroots for a single SAN cert.
How did I learn the this incredibly complex and mind-bending skill? Perhaps I read the Getting Started page where it provides the example: letsencrypt certonly --webroot -w /var/www/example -d example.com -d www.example.com -w /var/www/thing -d thing.is -d m.thing.is
Or maybe I read the full documentation where it provides the webroot example: letsencrypt certonly --webroot -w /var/www/example/ -d www.example.com -d example.com -w /var/www/other -d other.example.net -d another.other.example.net
Or maybe I saw the moderators provided webroot advice to scores of people asking for help instead of spreading FUD about how it can't be done.
Or maybe I sacrificed a goat to the dark lord under the light of a blood moon in order to garner favour with the forces of black magic.
I did read the getting started page when I got into the private beta stage on 16.11.2015 obviously the option was not there. and I cant always check the docs and stuff for changes. I am usually in the forum and read announcements about that stuff (as long as it’s pinned)
I use the official client, and I used multiple webroots for a single SAN cert.