Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Decreasing Certificate Lifetimes to 45 Days

letsencrypt.org

Post reply on HN
Print view View original

91–100 of 158 posts

Re: Decreasing Certificate Lifetimes to 45 Days

#91

Post by redrove »

bananapub wrote: post #70
redrove wrote: post #16

Earlier quoted context omitted.

Big news for both the lazy homelab admin that can set a TXT once and ultimately be more secure without spraying DNS Zone Edit tokens all over their infra AND for the poor enterprise folks that have to open a ticket and wait 3 weeks for a DNS record.

a perhaps non-obvious option is to CNAME (or NS) the `_acme_challenge` record from your main zone to another zone you can control better and can't affect production traffic the same way the main zone could. `acme-dns` is a neat little tool for exactly this, that has an https api for your ACME client to request a cert from, and a dns server to respond to dns-01 challenges from your provider.

Absolutely, this works well. Where it's approved :)

Re: Decreasing Certificate Lifetimes to 45 Days

#92

Post by electroly »

ZeroConcerns wrote: post #56
arp242 wrote: post #47

Earlier quoted context omitted.

Doesn't ZeroSSL do this? acme.sh has been using it as the default for the last few years. As I understand it, it basically offers the same as Let's Encrypt.

https://zerossl.com/pricing/ suggests a 3-cert limit on the free tier, as well as a huge influx of expected spam...

The "ACME Certificates" are free and unlimited. The 3 free "ZeroSSL Certificates" are old-fashioned manual certs: this is a strictly more generous offering than Let's Encrypt!

> If you have a server or other device that requires automatic issuance of certificates and supports the ACME protocol, you can use our free 90-day ACME certificates on all plans.

Re: Decreasing Certificate Lifetimes to 45 Days

#93

Post by nickf »

raizer88 wrote: post #23

Since we're on the topic of certificates, my app (1M+ logins per day) uses certificate pinning with a cert that lasts for one year, because otherwise it would be a nightmare to roll the cert multiple times in production. But what would be the "modern" way to do smart and automated certificate pinning, now that short-lived certs are becoming the trend?

Don't. Don't pin to public certificates. You're binding your app to third-party infrastructure beyond your control. Things change, and often. Note that pinning to a root or intermediate seems 'sensible' - but it isn't. Roots are going to start changing every couple of years. Issuing/intermediate CAs will be down to 6 months, and may even need to be randomised so when you request a new cert, there's no guarantee it'll be from the same CA as before.

Don't pin to certs you don't control.

Re: Decreasing Certificate Lifetimes to 45 Days

#94

Post by nickf »

Snakes3727 wrote: post #25

As someone who works at a company who has to manage millions of SSL certificates for IoT devices in extremely terrible network situations I dread this. One of the biggest issues is handling renewals at scale, and I hate it. Another increasingly frusturation is challenges via DNS are not quick.

I would strongly suggest that these certs have no reason to be from a public CA and thus you can (and should) move them to a private CA where these rules don't apply.

Re: Decreasing Certificate Lifetimes to 45 Days

#95

Post by ForHackernews »

schmuckonwheels wrote: post #7
ZeroConcerns wrote: post #2

I'm all for it -- it's hard to understate the extent to which LetsEncrypt has improved the WebPKI situation. Although the effective single-vendor situation isn't great, the "this is just something you only do via an automated API" approach is absolutely the right one. And certificate lifetimes measured in days work just fine with that. The only things that continue to amaze me are the number of (mostly "enterprise")…

> The only things that continue to amaze me are the number of (mostly "enterprise") software products that simply won't get with the times Yeah, no one's rewriting a bunch of software to support automating a specific, internet-facing, sometimes-reliable CA. Yes it's ACME, a standard you say. A standard protocol with nonstop changing profile requirements at LE's whim. Who's going to keep updating the software every 3…

I'll happily take failed automation with errors I can fix over being totally screwed when we find out the guy who did it every year left the company this year and nobody else knows anything about it.

Re: Decreasing Certificate Lifetimes to 45 Days

#96

Post by nickf »

jakeogh wrote: post #17
charcircuit wrote: post #12

Earlier quoted context omitted.

They've been slowly moving the time lower and lower. It will go lower than 45 days in the future, but the reason why we don't go immediately to 1 hour is that it would be too much of a shock. >So every small site that took the LE bait needs expensive help to stay online. It's all automated. They don't need help to stay online.

re too much shock, how so?

I'd say two big reasons: 1) A lot of people/enterprises/companies/systems are not ready. They're simply not automated or even close to it.

2) Clock skew.

Re: Decreasing Certificate Lifetimes to 45 Days

#98

Post by nickf »

jeroenhd wrote: post #89
raizer88 wrote: post #23

Since we're on the topic of certificates, my app (1M+ logins per day) uses certificate pinning with a cert that lasts for one year, because otherwise it would be a nightmare to roll the cert multiple times in production. But what would be the "modern" way to do smart and automated certificate pinning, now that short-lived certs are becoming the trend?

Pinning the intermediate CA should work. Alternatively, calculate the cost of updating the cert pinning mechanism if it's custom and compare it to paid, 1 year certificates (though those will go away eventually too). On the other hand, if you're using an app specific server, there's no need for you to use public certificates. A self-generated one with a five or ten year validity will pin just as nicely. That breaks i…

It'll be tough when ICAs rotate every 5/6 months and may even randomise.

Re: Decreasing Certificate Lifetimes to 45 Days

#99

Post by pmontra »

ZeroConcerns wrote: post #53
dmurray wrote: post #42

Earlier quoted context omitted.

"multiple vendors, but only one of them is nice enough to give the product away for free" is not "effectively single-vendor". The other CAs aren't prohibitively priced for anyone who has a business need for lots of certificates, in case Let's Encrypt disappears or goes rogue.

> other CAs aren't prohibitively priced Not if you look at the per-cert pricing, but if you factor in the cost of "dealing with incompetent sales" and "convincing accounting to keep the contract going", they absolutely are.

It's not only the sellers of the other party. You have to work with the buyers of your company too. Stuff that costs no money and needs no contracts move faster than stuff that must be negotiated, agreed upon, paid for.

Re: Decreasing Certificate Lifetimes to 45 Days

#100

Post by kyledrake »

crote wrote: post #49
kyledrake wrote: post #22

Earlier quoted context omitted.

Without getting into specific stuff I've run into, automated stuff just, breaks. This is a living organism with moving parts and a time limit - you update nginx with a change that breaks .well-known by accident, or upgrade to a new version of Ubuntu and suddenly some dependency isn't loading correctly, or that UUID generator you depended on to generate the name for the challenge doesn't get loaded, or certbot becomes…

The same happens with manual processes done once a year - you just aren't aware of it until renewal. Consider the inevitable need for immediate renewal due to an incident. Would you rather have this renewal happen via a fast, automated and well-tested process, or a silently broken slow and manual one?

The manual process was annoying but it wasn't complicated.

You knew exactly when it was going to fail and you could put it on your calendar to schedule the work, which consisted of an email validation process and running a command to issue the certificate request from your generated key.

The only moving part was the issued certificate, which you copied and pasted over and reloaded the server. There are a lot less things to go wrong on this process, which at one point I could do once every two years, than in a really complicated automated background task that has to happen within 15 days.

I love short duration automated free certs, but I think we really need to have a conversation about how short we can make them before we make it so humans no longer have the time required to fix problems anymore.

Post reply on HN