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

121–130 of 158 posts

Re: Decreasing Certificate Lifetimes to 45 Days

#121

Post by kassner »

phasmantistes wrote: post #110
kassner wrote: post #104

How do people here deal with distributed websites? I’m currently issuing one certificate on my machine and then Ansible-ing it into all the servers. I could issue one certificate for each server, but then at any given time I’d have dozens of certs for the same domain, and all must be valid. That doesn’t sound right either.

Organizations with many frontends/loadbalancers all serving the same site tend to adopt one of four solutions: - Have one node with its own ACME account. It controls key generation and certificate renewal, and then the new key+cert is copied to all nodes that need it. Some people don't like this solution because it means you're copying private keys around your infrastructure. - Have one node with its own ACME account…

Thank you for writing it!

> What you're doing right now makes sense for your scale, IMO

Absolutely. I use DNS validation, and I’m fine running it manually every quarter, but I’m sure I’ll be quite annoyed to have to do it every month.

Re: Decreasing Certificate Lifetimes to 45 Days

#122

Post by dmm »

ectospheno wrote: post #106
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.

Why dont providers offer dns api keys restricted to txt records?

desec.io allows you to create (through the api) tightly-scoped tokens that can only update the "_acme-challenge.subdomain.example.com" domain needed for DNS-01 challenges.

I switched to them from cloudflare dns for that specific functionality and it works great.

Re: Decreasing Certificate Lifetimes to 45 Days

#124

Post by dmatech »

ectospheno wrote: post #106
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.

Why dont providers offer dns api keys restricted to txt records?

https://dns.he.net/ does. Each record can have its own secret. You can also use this for things like A records to do dynamic DNS.

Re: Decreasing Certificate Lifetimes to 45 Days

#125

Post by jeroenhd »

phasmantistes wrote: post #105
jeroenhd wrote: post #89

Earlier quoted context omitted.

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…

Please don't suggest pinning a publicly-trusted intermediate. The CA may change which intermediate they're using at any time for any reason with no warning, and then the app which pinned that intermediate is hosed.

It depends what intermediate you pin, but the CA can also choose to change the root certificate they use at any time like Let's Encrypt did in 2024 when the CA that signed their cross signed certificate stood to expire. Plus, depending on where you get your certificates from, the reseller certificate may already be an intermediate rather than its own root.

You should probably pin the highest certificate in the chain that's going to stay current for as long as possible. Or, if the goal is just "I don't want people snooping around in my app's traffic" rather than "I want to protect against a rogue CA being used to hijack my customers' traffic", reuse the private key in the CSR and pin that, it'll get the job done.

Re: Decreasing Certificate Lifetimes to 45 Days

#126

Post by jeroenhd »

nickf wrote: post #98
jeroenhd wrote: post #89

Earlier quoted context omitted.

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.

You can prepare CSRs with new public keys years in advance. It'll take some certbot/ACME scripting to use them instead of aurogenerating new ones on the fly, but that way you can pin your future certificates. Add pins as you prepare new CSRs and drop them as the certificates expire, and depending on the size of the list you choose you should be good for months or years without app updates.

Plus, if you do any key pinning, you'd probably do well to also pin a backup public key you haven't used in case your CA/infra collapses and you quickly need to redo your HTTPS setup.

Re: Decreasing Certificate Lifetimes to 45 Days

#127

Post by riffic »

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")…

There's a slew of RFC documents that cover these related protocols so imagine that now means "requests for compliance".

Re: Decreasing Certificate Lifetimes to 45 Days

#128

Post by basscomm »

crote wrote: post #45
schmuckonwheels wrote: post #7

Earlier quoted context omitted.

> 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…

The change in validity does not in any way alter the protocol itself. As mentioned in the linked blog post: if you've already got automated cert renewal, it'll almost certainly require zero change. After all, the logical approach is to schedule a daily cron job for your renewal process, which only contacts the server when the current cert has less than X days of validity remaining. Scheduling a one-off cron job every…

> the point is to force companies to automate renewal

Cool. I'm a small-time webmaster with a couple of hobby sites with no more than a handful of visitors. Why do I need to set up automation to renew certs every 45 days, too?

Re: Decreasing Certificate Lifetimes to 45 Days

#130

Post by nickf »

jeroenhd wrote: post #126
nickf wrote: post #98

Earlier quoted context omitted.

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

You can prepare CSRs with new public keys years in advance. It'll take some certbot/ACME scripting to use them instead of aurogenerating new ones on the fly, but that way you can pin your future certificates. Add pins as you prepare new CSRs and drop them as the certificates expire, and depending on the size of the list you choose you should be good for months or years without app updates. Plus, if you do any key pin…

You can, but it’s still dangerous. You don’t have control over if those certs are revoked or keys blocklisted.

It’s best to simply not use public certs for pinning, if you really must do it.

Post reply on HN