5 ms·
ACME / Let's Encrypt go in the direction of making expiry happen so often that renewal gets automated, rather than a being a rare manual process that can be for
by kam 7y ago
ACME / Let's Encrypt go in the direction of making expiry happen so often that renewal gets automated, rather than a being a rare manual process that can be forgotten about.
Not sure that's viable for a signing certificate like this, but that's the way to solve it for the web PKI.
- SomeHacker44 7y agoThis is just abusive to the vast majority of users who do not care but still want to use SSL for their servers, frankly. I should be allowed to choose a near unlimited lifetime for my server's certificate if I don't care about the risks that may present.
- httpsterio 7y agoAs the service provider, you shouldn't get to decide. I think it's the users who can decide how long lived certs they're willing to trust.
- Godel_unicode 7y agoThat's cool and all, but what percentage of users do you think even know certs expire? I'd put the over/under at 1%.
- lugg 7y agoSecurity tends towards the lowest common denominator. I'd rather you just figured out how to run a cron job. The problem comes if your keys ever get compromised or cracked all your historical traffic becomes vulnerable instead of just the most recent window.
- gboudrias 7y agoYeah "just" a cron job except the implementation changes several times a year. Somehow this automated process was more time-consuming than the previous, manual one.
- lvh 7y agoMany cloud providers will make this process pretty much entirely automated. But let's say you don't want to do that: when is the last time the way you run caddy changed? Or the last time python-certbot-nginx changed?
- gboudrias 7y agoThis was a few years ago, so things may have changed by now. But as they say, once bitten twice shy, and the wisdom of "just cron it" doesn't work with highly experimental tools like LE was for what I estimate to be the majority of its lifetime.
- lvh 7y agoI'm sure there's a way to make your LE experience consistently suck but the way to run caddy for a static website has been the same for about as long as caddy has had support for automatic HTTPS, and that's also true for python-nginx-certbot. But more importantly: we can argue about what it was 4 years ago, or we can just observe that it's really easy now.
- lugg 7y agoA tool not working well or being "experimental" does not dismiss the premise that frequently run automated tools are a better than infrequently run manual tasks when those manual tasks can take down your infrastructure if done improperly, missed or forgotten. All it being new means is that depending on your risk ratio you need to decide whether updates to the software need testing or whether you need to invest in your own solution - or, how about just wait until it matures and keep the old process until then. Waiting doesn't invalidate the premise either. It just means you lack the resources to implement it safely and that's ok.
- MrStonedOne 7y agoIt's not your risk to decide on. You will not always own that domain name, and allowing you to still have a valid cert for it afterwards is silly.
- pmontra 7y agoActually it could be not negligence but a way to perform an attack. Register a domain, get a certificate lasting forever, let the domain expire and somebody buy it. Then somehow redirect all or part of the traffic to that domain to your own server with a valid certificate. Chances are that few people will notice something has changed in the details of the certificate. However you'll have left traces all over the place: credit cards, phone numbers, etc.
- dev_dull 7y agoIt’s funny to me that people talk about this limitation as if it were some kind of virtue.
- tty2300 7y agoIts also more secure. Long lived certs risk the possibility that someone who used to own the domain got a certificate on it and it still works after the domain is resold. Once you automate it there is no downside to short lived certs.
- Godel_unicode 7y agoIf only there were a way to revoke certificates. Like, some kind of list.
- yjftsjthsd-h 7y agoIf only such a list were actually effective rather than the majority of clients not bothering to check it.
- lvh 7y agoCRLs do not work in practice, and major clients routinely ignore them.
- dwaite 7y agoRevocation lists get huge, ultimately becoming another reason to limit cert lifetime (you don't have to tell people you revoked a certificate which is expired naturally). Very few things check revocation, unfortunately - it puts an extra hop on the fast path of connecting to a server. OCSP stapling is pretty much the only thing a browser would care about - having the server fetch a signed OCSP response that is good for a limited period of time (say, hours), and send that along with the certificate during negotiation. Or, you could just have the server fetch a certificate thats good for a limited period of time.
- MrStonedOne 7y agoRevocation requires the private key
- jetrink 7y agoSee also: GPS vs GLONASS time encoding. GPS rolls over every 19 years, so devices, cars and even Boeing aircraft saw their GPS-based clocks turn back to 1999 last month. Meanwhile, GLONASS epochs are only four years long, so every device that uses it as a time reference is built to handle rollover.