Short of IdenTrust's (offline) root key being compromised (i.e. the "security flaw/short-term fix" case), I don't see a switch like that happening without significant advance notice. There's no real SLA, so from a business/legal point of view it wouldn't make much of a difference (not a bad topic for discussion, but to be honest I haven't seen much regarding SLAs in the CA industry in general).
It comes down to what's being promised here and in the documentation. I think a significant change like that would definitely fall into the "advance notice" category. As an example for the commitment on backwards compatibility, an upcoming change in boulder that could break renewal for about 0.1% of all domains Let's Encrypt has issued certificates for was implemented with an exception list for all affected domains in order to prevent that.
This is an excellent point, @jvanasco, and you've crystallized it quite well. I agree that Let's Encrypt should provide more formal guidance on which platforms we intend to support, and how much advance warning we'll give when that is going to change. I'll talk with the team about what that guidance should be. It may take a little while to finalize it.
I don't either. But there's a difference between "what an established community member feels an official rep's blog post means" and "a bulletpoint on the policy page of the dot-org". There's also a difference between how developers commit to backwards compatibility in practice, and what the org's stated protocols are. Finally, IdenTrust could potentially immediately end the relationship from their end, and possibly even revoke ISRG's certs - which would create a window that is at-most 60-90 days.
ISRG is unofficially doing many things the right way, but should be making those practices official policies.
You said that way better than I did. I'm glad I got this point across!
Just for a bit more perspective on this -- keep in mind that there are massive secondary markets for mobile devices and computers in other parts of the world. A lot of companies now take a US/Euro centric approach and don't support things that are more than a few years old, and that can disproportionately limit benefit to these areas.
This thread, again, got far too long to read it completely.
As far as I see there never was any response of the responsible people, right?
There may be many advantages of this “auto renew” thing but even if they exist, this mechanism shouldn’t be forced.
There are many users that can’t use this auto renew process (as they are not allowed to install such services in shared hosting, for example) or don’t want to do as they want to do such administrative tasks on their own without trusting some automatic process.
If you really want to help to encrypt all pages on the web you should make this as easy as possible. This also includes to help people that don’t want the automatic update process by allowing longer certificate lifetimes.
This situation shouldn't exist, cPanel/WHM now support LE with the AutoSSL feature. The onus is on hosting providers to keep up with this or lose customers.
I don’t think so. At least for me HTTPS is not a that big priority. I could use it if it would be easy to use, but I won’t change my hoster just for LE. The idea behind LE is great (free certificates for everyone) but at least for me it is a bad decision to force people into the automatic certificate generation process.
Obviously, or you'd have seen that the issue you raised has already been discussed ad nauseum. Automation is central to Let's Encrypt's model. If you are unable or (more likely) unwilling to use an automated solution for cert issuance and renewal, Let's Encrypt just isn't for you.
Wow. I’ve been aware of Let’s Encrypt for a while but came to take a better look at it due to Mozilla killing off StartCom certs. I had no idea this 90 day time limit was such an embattled issue. Personally, I’ve got no problem with automating 90 day rotating certs on systems that are open enough to do so. And if you can convince hardware manufacturers to implement let’s encrypt clients into their devices, more power to you. But I’ve got this nice Brother laser printer I bought last year with a StartSSL cert that needs replacing. And it’s a serious PITA to install certs on it. And it will never have a let’s encrypt client on it. The same can be said for a fair number of embedded devices in my house from my zigbee electric meter reader to my environmental sensor system. And if Let’s Encrypt decides they only want to secure general purpose web servers and not special purpose/embedded web servers, or even SSL applications that aren’t web servers, because they don’t fit their model of how they think certificate deployment should work, well, I guess that’s their privilege given it’s their service. It doesn’t really seem those bits are any less worthy of being protected on the wire though… And it’s not like the use cases are going to go away just because you don’t like them. I can’t even get HP to support loading intermediate certificates on their embedded iLO server management interfaces, I would love to hear somebody try to talk to them about including a let’s encypt client ;).
So, anybody know of a StartSSL replacement without so much of an agenda? Not looking to change the world at this point, just want to encrypt stuff without paying through the nose to the snake oil companies.
Part of the point of LE is to make certificate replacement more automated so it's much easier to do for every interface. It's not going to happen overnight, but maybe with some time and more support from other providers, makers may move in this direction.
Alternately, you could see if there is a way to program (or hire someone to program) a tool that would automatically update the certs by emulating the right interactions.
If you don't need public access to your devices, you could always make your own internal CA and issue five year (or ten or more) certs to your devices. You'd just need to add trust for your private CA to avoid certificate warnings.
I'm not aware of any widely-supported option. There's CACert, but they've had unending problems passing the audits needed to be added to many certificate stores.
Alternately, you can find some resellers (like NameCheap / SSLs.com) that issue basic single-domain certificates for $10/yr or less. If you need a certificate with public acceptance and LE won't work for you, it's not a high price.
I’ll add another problem with the 90-day lifetime. I have the following:
Linux Server with Apache which uses: PEM, CERT, CHAIN
Within my Linux server I have several Java programs which use: JKS
A Windows Server - PFX (with password for private key)
A media server on a different Windows 10 machine - PFX (no password)
As I’m sure you can imagine, I’m not really interested in keeping these various parts updated every 90 days.
The problem, to me, is that the Let’s Encrypt use case is a single server or, I guess, many servers all running the same operating system and all referencing the exact same SSL certificate. In that case, sure, there’s no big deal for a 90-day auto renew.
But what about my use case? Multiple machines with different OSes none of which speak the same SSL language. All of a sudden, it’s not such an automatic process at all but rather a tedious manual one.
For the automation to work, at least in my case, Let’s Encrypt would need to not only renew the certificates but convert and properly propagate them as well. As this seems like a large ask at this point, a longer timeframe seems like a reasonable alternative. Doing this once every two or three years, okay. Every 3 months? Ugh, forget it.
I have similar scenarios @mobamoba and I’ve automated it with scripts. It takes a little longer to do first time, but then it’s automated and has worked automatically for many months now ( coming up to 12 months in many of my cases).
@serverco If you feel comfortable sharing those scripts, I’d appreciate it as maybe they could help me get started on my own. If I recall, the conversions were hair pulling (the JKS was especially bad in my memory). It’s too much of a fantasy I guess to hope that there could just be a single format for SSL that every operating system could understand. Sigh, one day…
I strongly support the option for people to choose a 1 year certificate if they so desire. I agree with all of the Cons mentioned, and as for the Pros:
This should simply be down to the server admin to decide on whether to take that risk. I consider my server to be very secure and I have never had an SSL cert compromised. It's not much of an argument for forcing 90 day certs on everyone.
This is a very weak argument. Any competent server admin is not going to "forget" to renew their SSL cert. As for warning-blindness in end-users, that might have applied back in the days when they merely got a popup window. Nowadays, however, in most browsers they get a big red warning about expired certs that actually makes it quite hard for them to visit the site. This is another reason, by the way, that a server admin is not going to forget to renew their cert. Not for long, anyway. Their site traffic will plummet.
[quote]Let's Encrypt's total capacity is bound by its OCSP signing capacity, and LE is required to sign OCSP responses for each certificate until it expires. Shorter expiry period means less overhead for certificates that were issued and then discarded, which in turn means higher total issuance capacity.
[/quote]
I don't understand why a shorter expiry period means less overhead; perhaps someone could explain.
I seem to recall reading a comment somewhere stating that (and I'm paraphrasing and possibly misremembering) while Let's Encrypt provides a service for website owners and/or server administrators, that's not really who they're working for - they're working for users to allow them to communicate securely with websites. If you think about it from that perspective, it makes sense to opt for the safer setting rather than let server admins make a choice that could potentially harm them and their users.
As for never having been compromised - if your server software used OpenSSL in any way (which would be the case for pretty much any mainstream web server on Linux), you were likely vulnerable to Heartbleed at some point, and would've potentially benefited from shorter certificate lifetimes. Just because it hasn't happened to you yet doesn't mean it's not worth thinking about.
That doesn't match my experience, which is closer to "any manual recurring process will be forgotten or messed up at some point." There's news of some high-profile site having their certificates expire every couple of months (though I feel like it's been getting better in the last 1-2 years or so).
OCSP responses are only valid for a certain period. Let's assume you accidentally issued 20 certificates for your domain while implementing Let's Encrypt for the first time. With a one-year lifetime, Let's Encrypt would have to sign OCSP responses for each certificate every couple of days (typically ~3) for a whole year. I think even in case they're revoked, response signing would need to continue until the expiration date. With 90-day certificates, that's significantly less load over the course of a year.
Note that if you were vulnerable to Heartbleed, you could have had your private key stolen and not know it happened. With a long-lived certificate where you didn't revoke it manually, that's a lot of time for a potential attacker to have access to private data.
Where I work (medical startup) we had a client that ignored our warnings that their provided certificate was near expiration until it actually expired after hours in the middle of a week. Suddenly, it was an emergency as they had a customer needing to use the service the next day. We've moved the subdomain they use over to Let's Encrypt and won't have to worry about that kind of mess with them anymore.
Suffice to say, it isn't always the admin that "forgets" to renew. Also, sometimes circumstances delay action and that can create an issue where the certificate doesn't get renewed in time. Automating renewals resolves the problem of needing human intervention as a matter of course.
Obviously this isn't directly related to certificate lifetime. You can automate for one or three year expirations, but the process is more likely to fail since it's run so rarely. Besides that, if you can automate why not also gain the security benefits of short lifetimes?
That's my understanding as well. The OCSP servers have to respond that the certificate is revoked until past the expiration date. This means that signing still has to take place.
) - I don’t mind sharing scripts - I’ll PM you.
There's news of some high-profile site having their certificates expire every couple of months (though I feel like it's been getting better in the last 1-2 years or so).