Maximum (and minimum) certificate lifetimes?


#170

That is part of what LE is about. Many of us were drawn to LE because of other parts. Also, everything I saw beforehand suggested that manually creating certs was also possible and viable, when really, they just aren’t with the 90 day renewal period that was then dropped on us later on. We were drawn in by the idea of a free, open CA sponsored by the likes of Mozilla and the EFF, with the plan to help push widespread TLS use. Then we get here, and get told about this limitation which directly goes against the major goal as we (at least I) had been led to understand it.

Sure, it’s part of their mission statement, but it’s not the entire mission statement, and not what many of us thought to be the main driving force of it.


#171

Do you understand what you are suggesting? If LE would provide intermediate certificates to end users, every user could generate certificates for www.google.com or www.microsoft.com How long would it take before LE would be blacklisted by every serious root certificate store? The current certificate system is fragile enough as it is…

Also: No matter what you do, you have to rely that the CA you chose is working no matter if it uses email, a web frontend or “some client”.


#172

I feel your pain and believe me, I’ve been there. But I got over it and i am happy for the work and money that LE is going to save me. It is just not a solution for all my problems.

The problem with a mission statement is that all points are important and have to be fulfilled. You argue to drop the automatation. What’s next? How would you feel if someone wants to drop the “Free” or the “Secure” part?


#173

the automation shouldnt be dropped but to each his own there’s stuff where automation wont work and there the 90 days certs are a serious pita…


#174

Automation should be a feature. Not a usage requirement.


#175

Yes, and LE’s goal is having automation. If this does not work for you, you are free to choose another CA. LE does not have to fit in all usecases.

@nneul
Some thoughts about it being non-optimal: Getting Bad Vibes and Getting Bad Vibes


#177

well they arent exactly self-signd they are signed by an intermediate they got from geotrust, to be exact.


#178

Not quite. Check the links in my post above + this one. I’ll even quote a bit for your convenience:


#179

well if you dont use a 1024bit key and sha1 then even a year should be relatively secure.


#180

I don’t though. I argue to drop the 90 day maximum. Having automation for those that want/can use it is great, but we were told that manual mode was possible, and it was made to seem just as feasible. I’m not suggesting they drop it, I’m suggesting they actually make it practical to a wider group in order to increase TLS adoption, which was the main goal stated in a lot of places. As @nneul so succinctly put it, “Automation should be a feature. Not a usage requirement.”

I entirely understand wanting automation, and I can see its use for some people, but it’s just not practical for everyone, and works against what I consider the far more important goal of more widespread TLS.


#181

you mean maximim,dont you?

^<- THAT!


#182

Wow, just wow. I was really looking forward to the going live of Let’s Encrypt, but it seems to me as if it is only targeted at a fraction of service providers (namely service providers that have some really bad habits when it comes to TLS).

I saw people mentioning that one could reuse a key pair for several certificates to ease the renewal process. At my workplace this a complete no-go. Every certificate gets a new key pair. No matter of discussion.

Then there are people mentioning that automating the renewal is an easy task. I don’t see how you can say this when at the same time you deny that Let’s Encrypt poses a security threat. You allow some fully automatic process to access your private keys? We restrict access to private keys to the root user - that way services can read them during startup, before dropping privileges, but never again. Renewing certificates therefore requires a full restart. But as it seems you either do not protect your private keys or you are okay with automatic processes that run as root. Neither case is desirable.

Another thing: have you ever thought about not-just-kidding-around environments? For example networks that employ TLS-off-loading within firewall or loadbalancer appliances? Are you going to tinker with these devices, lose your support, so that you can live with certificates that are only valid for 90 days? I’d really like to see how your automation looks like in real life environments.

And finally, has anyone thought about the Internet of Things? How do you want to automate certificate renewal on these devices? At the moment it’s difficult to find devices that support TLS - but the number of devices is rising. Do you really think that anyone will use Let’s Encrypt certificates in this area?

tl;dr: With certificates that are only valid for 90 days you’re actively killing the idea behind Let’s Encrypt for serious users and for emerging technologies alike.


#183

Bravo. Very well stated. Wish I could give you nK likes.


#184

@kenny re-use of keys is a pure option by default it does what you guys do anyway, and that is making a new pair.


#185

I’s rather say for those who CAN.


#186

+nK



#187

On the subject of automation… specifically, why automation is such a big part of the LE mission.

This issue has two sides: support and security.

With respect to support, I suspect that the folks who conceived of this project saw automation as a solution to a very basic problem for a free CA: how to support a large number of users with no staff. That is to say, LE is currently (and probably always will be) a very small organization. They don’t have staff to support users. So I imagine that their hope is that by building a community of users for whom everything is automated, then the need for active, live support staff will be limited.

And the other side of the coin is security: specifically, how to maximize the security of their systems. A short certificate lifetime has a very basic security advantage: if something gets compromised, you don’t have to wait long before browsers start rejecting the cert, even if no action is taken (FWIW, this is the same reason why credit cards have expiration dates). However, as so many have pointed out in this thread, a short cert lifetime is a major pain in the you-know-what. For these folks, a longer lifetime is going to be necessary to avoid that pain. But at the same time, these folks are going to miss out on the security benefits of a shorter lifetime.

Now, I’m not affiliated with LE in any way. I’m not even in the beta program - I’m waiting for the public beta (and to get the project I’m working on into a state where it’s ready to deploy). But the reasoning for the decisions that have been made seems clear to me:

If you can build a community of users who are automating certificate renewals (to reduce or eliminate the need for support), you can also implement short cert lifetimes and thereby improve security.

Is automation going to work for every use case? No, certainly not. Is the security improvement gained from short cert lifetimes substantial? I don’t know - I’d love to hear what others think on this point.

In the end, all we can do is individually determine if LE will meet our needs. We can, of course, continue to push for changes to their policies. I suspect that, in the short term at least, requests for longer cert lifetimes will be refused because of the rationale I’ve described here.


#188

that’s why I always say, wutomatic where possible together with the 90 days, and everyone else (who uses manual) may get longer lifetimes of their certso it’s not so annoying.


#189

As mentioned in another thread, I doubt that this short time span will increase security. If you get attacked in a manner that you lose your key pair, chances are that you will also lose your renewed key pair 60 days later. If someone is aware of a problem/attack, then they should also be able to revoke the corresponding certificate.

IMHO it’s even worse - the automation that takes places has to provide an externally available entry point (challenge-response). I’m certain that the day will come, when hosts get hacked because they employed a vulnerable Let"s Encrypt automation script.


#191

Can you elaborate on those bad habits?

The argument for shorter certificate lifespans (or, well, one of them) is basically that you don’t have to rely on the flaky revocation process actually working when your key gets compromised. Asking for longer certificate lifetimes and arguing against reusing keys at the same time doesn’t make sense from a security POV (or any other POV I can think of).

I don’t see how this is any different from e.g. your webserver having access to your private keys. The client will eventually be delivered through the same channels you probably get your webserver from (i.e. your distribution’s repository, using signed packages), which probably also has an update mechanism where you won’t manually review every single update down to the source code. It’s not as if the ACME spec requires a client to provide remote code execution for the server, so that they could simply update something on their end and suddenly get all your keys. Additionally, there are plenty of verification options within the existing ACME spec (with more to come), some of them make it fairly easy to run your certificate provisioning from a completely separated system.

There’s no technical reason why a service that uses privilege dropping somehow requires a full restart to reload certificates. Graceful reloading has been a thing in many webservers for a long time. If your threat model includes malicious updates to your ACME client, simply switch to one that doesn’t require root (e.g. letsencrypt-nosudo) and automate the certificate reloading in some other way. It’s entirely possible without downtime. Additionally, if you’re worried about going down for about a minute every 60 days, you should have multiple loadbalancers in place either way and operate with rolling upgrades.

It is not necessary for hardware loadbalancers to include an ACME client directly to be able to automate renewal with letsencrypt. All you need is an API allowing you to provision new certificates, I would hope those are available on the better products out there. If that’s not possible, I guess that’s one of the rare cases where sticking with your current CA offering longer lifetimes is a good idea. I don’t think supporting every corner case should be letsencrypt’s mission.

My answer would be the same as for the previous point, but I would add that something like letsencrypt actually would vastly improve the situation for IoT. I think there are two possible outcomes there: Either TLS will never become a thing for the majority of IoT endpoints and their security remains terrible, or devices will start adopting some kind of automation, and CAs supporting ACME are probably the best option out there right now. Or do you really think someone’s going to manually renew the certificate on their IoT toaster (forking over money!) when it expires 3 or 5 years after they bought it? That doesn’t sound realistic to me at all.