188 points by SGran 2 days ago | 147 comments
rickette 2 days ago
ryandrake 2 days ago
outworlder 2 days ago
I's only inconvenient because it isn't properly automated. That's by design.
When this can be a acme.sh script cronjob, there isn't much of an excuse. Even my Raspberry Pi dedicated to my 3D printer is happily renewing certificates.
At least with this thing breaking every 90 days you have it fresh on your mind. One year away you may not even remember what you have to do.
Needless to say, you have a bug to fix.
theoreticalmal 1 day ago
sanswork 16 hours ago
jeroenhd 2 days ago
I think keeping the validity long just removes incentives for people to bother fixing their setups. We've seen the shift from "Craig needs to spend a few days on certificate renewal every year" to full automation in most environments when the 90 day validity period was introduced, and shortening it to a week will only help further automation.
You'll always have the option to skip the hassle (for a small fee, unless a Let's Encrypt competitor joins the market), but I feel the benefits outweigh the downsides.
I personally would've preferred something like DANE working, but because the best we've got is DNSSEC and most of the internet doesn't even bother implementing that, I doubt we'll ever see that replace the current CA system.
raxxor 23 hours ago
Some software now uses short lived certificates and even with decent configurations, there is an elevated level of problems specifically because of certificates. Especially in networks that use a lot of segmentation with very restricted network traffic.
I think a short lifetime can be a security benefit, but it should not become a dogma. It should be employed where it really makes sense but as a general rule inconvenient describes it quite well.
patrakov 19 hours ago
atomicnumber3 15 hours ago
jeroenhd 20 hours ago
FWIW you should run most ACME clients more often than that, just in case there's a performance issue or bug at Let's Encrypt's side. The tooling won't replace your certificates unless they're almost expiring anyway. Certbot's instructions will have you set up a cron job that runs twice a day.
> Some services do not load certificates while running and must be restarted
This is exactly the kind of software that needs fixing. Luckily for the critical, nine nines uptime cases where 5 seconds of downtime for the web server restarting is unacceptable, there are services that will sell you certificates valid for a full year or even longer.
I doubt year long certificates are going away soon. We're already years off Let's Encrypt ending their 90 days offering, for sure. The convenience factor isn't going away, at some point it'll just cost a bit more.
arielcostas 1 day ago
hulitu 17 hours ago
The best certificates should expire after 20ms. /s
tasuki 2 days ago
I also have hobby-level serving needs. I've been using LetsEncrypt since whenever it was they started. I have two top level domains and a whole lot of subdomains.
I've never had to babysit certificate renewal, nor had to log in manually to fix anything. Not once. How comes?
5d41402abc4b 1 day ago
erincandescent 21 hours ago
crtasm 20 hours ago
ryandrake 21 hours ago
MaKey 2 days ago
Clearly it's not working correctly, so a longer certificate lifetime wouldn't address the root cause - you would just have to fix your setup less often.
duskwuff 2 days ago
tialaramex 2 days ago
I think the drop-dead date for this product was like April 2015 or so. The ideal customer for a product like this (lazy and also incompetent but with plenty of money) is also likely to leave it too late. I won't guarantee we'd have caught that, but unlike forbidden steps taken to avert a bigger mess of ones own making (as happened for SHA-1 deprecation, some notable financial outfits secured certs which should not have existed, to cover for the fact they hadn't properly managed their own technical risks) this seems like a product category thing, nobody was openly selling certs that would just break in Chrome, that's a bad product.
[Why would such certificates break in Chrome? Google hate these long lived certs so Chrome treats certificates which have validity exceeding what the BRs authorise as immediately invalid, if you want to moan to Google about why your prohibited certs don't work you're basically admitting you violated your agreement with them so it's like showing up to claim your stolen rucksack full of cocaine from the cops...]
KronisLV 1 day ago
Surely there are tradeoffs in having to rotate the certs that often, right? Notably, considerable load on their infrastructure. I get that urging people to automate their renewals makes sense (though I've also heard people unironically saying: "I want it to be a manual process, so I know how it works instead of relying on some black box"), but it seems that shorter and shorter cert lifetimes might put more strain on a service that nigh everyone seems to just be using for free.
Edit: at least there are a lot of prominent companies here https://letsencrypt.org/sponsors/
raihansaputra 1 day ago
apitman 2 days ago
boringproxy needs to provide a callback redirect_uri to the oauth server in order to retrieve it's token, which it can then use for setting DNS records. However, it can't provide an HTTPS endpoint until it can set up those DNS records and get a cert. Chicken/egg. Currently the spec requires the server to implement a `GET /temp-domain` endpoint which creates a DNS record like 157-245-231-242.example.com which points at the client's IP. This lets boringproxy bootstrap a secure OAuth2 callback endpoint.
IP certs would remove an entire step from this process.
[0]: https://github.com/takingnames/namedrop-protocol-spec
[1]: This is actually broken in boringproxy at the moment, but there's a demo video here: https://www.youtube.com/watch?v=9hf72-fYTts
captn3m0 2 days ago
I am gonna try to run a DoH resolver on this and see how it goes.
prdonahue 2 days ago
I remember calling Clint and Jeremy at DigiCert and asking: "hey we have this cool IP address—what are the odds you guys can issue a certificate for it?"
I'm not sure if they had to dust off some code or process to do it, but they got it done really quickly once the demonstration of control was handled.
DonHopkins 2 days ago
yegle 2 days ago
snailmailman 1 day ago
Because if zero pages load, but that one does, the issue is DNS.
Ping is easy too of course, but I can ask people to type four ones with periods between into their search bar over the phone. No command line required.
ray_v 2 days ago
Arnavion 1 day ago
https://community.letsencrypt.org/t/post-to-new-order-url-fa...
If they do start providing 6-day certs I hope their turnaround on issue reports is faster than that (and ideally have something better for reporting issues than a community forum where you have to suffer clueless morons spamming your thread).
mholt 2 days ago
That, and extended week-long outages are extremely unlikely.
deathanatos 2 days ago
You only need the outage to last for the window of [begin renewal attempts, expiration], not the entire 6d lifetime.
For example, with the 90d certs, I think cert-manager defaults to renewal at 30d out. Let's assume the same grace, of ~33% of the total life, for the 6d certs: that means renew at 2d out. So if an outage persisted for 2d, those certs would be at risk of expiring.
mholt 2 days ago
bmicraft 2 days ago
mkj 1 day ago
cyberax 2 days ago
arianvanp 2 days ago
pilif 2 days ago
zzyzxd 2 days ago
ncruces 2 days ago
https://letsencrypt.org/docs/rate-limits/
For the “exact same set of hostnames” (aka. renewals) the rate limit is 5 certificates every 7 days.
So you could do it every other day, if you can make sure there's only one client doing it.
And they're very clear this is a global limit: creating multiple accounts doesn't subvert it.
So you'll need to manage this centrally, if you have multiple hosts sharing a hostname.
Cerium 1 day ago
ncruces 17 hours ago
pilif 2 hours ago