fwiw, I host a free little service that can check certs once daily and email you if they're about to expire - https://ismycertexpired.com/check?domain=ismycertexpired.com
Decreasing Certificate Lifetimes to 45 Days
51–60 of 158 posts
Re: Decreasing Certificate Lifetimes to 45 Days
#52I'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…
In circles I'm running in, automatic certificate renewal has not caused a single problem over 7 years of using it, and whatever time was spent on setting it up, has paid many times over, both in saving effort on renewal, and in putting out fires when (not if) someone forgets to renew a certificate. You just have to be careful picking your automation — I haven't been impressed with certbot, for example.
Also, everything is using https now. Living in a low-income country, certificates were too expensive to use them where they weren't absolutely required, but not anymore. This is orthogonal to automation, I'm just pointing out that LE is not as demonic as you make it out to be.
I'm afraid enterprise users are on their own, probably approximately no-one else is interested in going back to the old ways of doing it. (Maybe embedded.)
Re: Decreasing Certificate Lifetimes to 45 Days
#53Earlier quoted context omitted.
Effectively single-vendor. I'm not aware of any ACME-compatible CAs that don't have pernicious limits on their free plans (and if there are, I'd love to hear!), and here in the EU we've even recently lost a rather big player...
"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.
Re: Decreasing Certificate Lifetimes to 45 Days
#54Since 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?
The certificates will expire, but (as far as I'm aware), you're still allowed to use the same private key for multiple certificates, so as long as you pin to the public key instead of to the certificate itself, you should be fine. The real modern way to do certificate pinning is to not do certificate pinning at all, but I'm sure that you've already heard this countless times before. An alternative option would be to…
> The certificates will expire, but (as far as I'm aware), you're still allowed to use the same private key for multiple certificates, so as long as you pin to the public key instead of to the certificate itself, you should be fine.
It's allowed, but the intent of short cert expiration is to also have short private key lifetimes, so that point in time key compromises have time limited forgery potential. If the same key is used for a long period, someone who got the key once can download your public certificate and use that with the key they have.
> The real modern way to do certificate pinning is to not do certificate pinning at all, but I'm sure that you've already heard this countless times before. An alternative option would be to run your own private CA, generate a new public/private keypair every 45 days, and generate certificates with that public key using both your private CA and Let's Encrypt, and then pin your private CA instead of the leaf certificates.
The tricky thing here is you need to serve your private CA signed cert to pinned clients and a PKI cert to browser clients. If you want cert pinning for browsers (which afaik, is very limited availability), you should pick at least two CAs that you are pretty sure will continue to issue you certs and won't be delisted; bonus if you're also confident they won't issue certs for your domains without your explicit consent.
I would also recommend two private CAs, if you're doing private CAs. Store them physically separate, so if one is compromised or becomes unavailable, you can use the other.
Re: Decreasing Certificate Lifetimes to 45 Days
#55I'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…
> A standard protocol with nonstop changing profile requirements at LE's whim. Who's going to keep updating the software every 3 months to keep up?
It really doesn't change that often. And whether this is a "breaking" change is something that's debatable (you shouldn't hard-code the cert lifetime, but I suspect many programs do, so de-facto it may or may not be a breaking change).
If you look at the Go implementation for example (https://github.com/golang/crypto/commits/master/acme), then there haven't been any major changes since it was first written in 2018: just bugfixes and basic maintenance tasks. Maybe I missed a commit but it certainly doesn't require 3-month update cycles. You can probably take that 2018 code and it'll work fine today. And since it doesn't hard-code the 90 days it will continue to work in 2028 when this change is made. So it's more "you need to keep updating the software every decade to keep up".
Re: Decreasing Certificate Lifetimes to 45 Days
#56Earlier quoted context omitted.
Effectively single-vendor. I'm not aware of any ACME-compatible CAs that don't have pernicious limits on their free plans (and if there are, I'd love to hear!), and here in the EU we've even recently lost a rather big player...
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...
Re: Decreasing Certificate Lifetimes to 45 Days
#57Earlier 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...
I think that refers to something else (manual non-acme certificates)? Many other pages says it's unlimited. E.g. https://zerossl.com/documentation/acme
Re: Decreasing Certificate Lifetimes to 45 Days
#58Re: Decreasing Certificate Lifetimes to 45 Days
#59Earlier 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.
When I was working with Digicert a decade ago, it was expensive, but they also had knowledgable support and with a wildcard cert, they would issue all sorts of 'custom duplicates' by request that were super handy. No incompetent sales, but certainly you do need to make sure accounting will pay.
Re: Decreasing Certificate Lifetimes to 45 Days
#60Since 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?
I think the suggestion of pinning the public key and keeping the same private key across certs is the best option. But if you don't want that, perhaps this is a (high complexity, high fragility) alternative:
- Make sure your app checks that enough trusted embedded Signed Certificate Timestamps are present in the certificate (web browsers and the iOS and Android frameworks already do this by default).
- Disallow your app to trust certificates that are more recently requested than N hours. This might be hard to do.
- Set up monitoring to the certificate transparency logs to verify that no bad actor has obtained a certificate (and make sure you are always able to revoke them within N hours).
- Make sure you always have fresh keys with certificates in cold storage older than N hours, because you can't immediately use newly obtained certificates