I’m all for making things more secure, but they’ve broken all of my certs in the last 12 months (in different ways, at different times), and I’m sick of it.
I’m all for making things more secure, but they’ve broken all of my certs in the last 12 months (in different ways, at different times), and I’m sick of it.
My own monitoring always alerts if certificate chains don't validate, HTTP->HTTPS redirection is dead, or if the certificate is due to expire in less than 10 days.
The various tools for interacting with Lets Encrypt might fail sometimes, but if you have monitoring you can fix them up as required - and without monitoring you'll in trouble regardless of who you use.
OCSP out of the box is a call back to the issuing CA to verify that your certificate is still valid. Let's Encrypt like a lot of popular CAs implements this by having a CDN answer all live OCSP queries with bulk produced generic "This is still fine" answers for all the still-good certificates. But that means for any clients which check OCSP (some browsers do) that CDN is now on your critical path.
You can instead have your web server obtain (and periodically refresh) OCSP answers and "staple" them to its certificate when it answers HTTPS connections so that CDN isn't on your critical path any more.
However, some popular servers (most notably Apache HTTPD) do such a bad job of implementing OCSP Stapling that you're more likely to destroy your availability than improve it by enabling stapling (this is one of the things IIS actually gets right for a change), so make sure you understand what you're getting into. You will also need monitoring of the stapled response, because now if it's bad that might be a problem with your systems that you need to fix - whereas if Let's Encrypt OCSP is broken for the world you can be sure somebody else's on-call engineers are wrestling with it.
Edit: personally I also have a script that runs every day and checks the validity of all the certs in my live directory and pings me when they are due to expire as a second measure.
I actually don't know if that works with domains not managed by them, but I believe so.
Sadly, certs from big CAs are pretty expensive these days... Let's encrypt is really awesome service to counter that.
Yeah you can use domains not managed by them, just have to throw a txt record given by them on on to the DNS for the domain to validate that you have control of the domain.
They use the same acme system as LE so depends on what failed for you for it to be a viable alternative (if the certbot failed for example then it might of failed using buypass in the same way as it would of failed under LE)
What happened? Was it their fault or yours?
For example you could buy a Sectigo (previously Comodo) certificate for 2 years for like 17$ or so. Wildcard for 2 years is like 100$.
Its worth less than a broken certificate.
We are going to repurchase all of our certs in Digicert this year with which I’ve had a much much better experience. They are well integrated with Azure Key Vault which allows us to automate certificate renewal and our AKS clusters will automatically get the new certs without us doing anything.
https://www.theregister.co.uk/2018/03/01/trustico_digicert_s...
if you are using your cloud certificates (built into lb, etc), then this is a moot point. You dont even need letsencrypt then.
Am I looking in the wrong place?
[1] https://www.comodoca.com/ssl-certificate-comparison?key5sk1=...
Also, with Sectigo you're more likely to get an actual broken certificate. They misissued nearly every certificate starting from 2002 until late 2019 [1].
Sure about the broken, but the alternatives are worse with possible leaked private keys.
If you only have one certificate you may get away with it. But if once you have hundreds or thousands this is absolutely going to break down the human factor.
And even if you do have a single (or few) certificate(s), there are other factors that are going to complicate maintaining this system:
* What if a certificate needs to be revoked by your CA? Generally CAs are obligated to revoke certificates within tight deadlines (ex. 24hr for key compromise). That doesn't give a human a lot of time to replace the certificate.
* What's going to happen when 2-year certs are no long available? Ballot SC-22 failed, but it would've reduced certificate lifetimes to 1 year. Some CAs are moving in this direction anyway, and it's worth noting that Sectigo supported this ballot.
* What happens when the person responsible for renewing them leaves the company and forgets to hand-off the responsibility?
I almost see the infrequency of certificate rotation as a negative since it means the process is infrequently tested and easy to forget about.Sure tools like cerbot can break, but if you know that it's renewing certificates 30 days out then setup alerting for whenever a certificate expires in less than 30 days. You should have this alerting anyway in case the human responsible for manual rotation forgets.
If you ended up in a state where you were serving an expired certificate then the key issue is your alerting.
[1] https://twitter.com/chosensecurity/status/123025334823601357...
However 99% of people have no more than a handful - especially if you have wildcard certificates. And the incidental complexity of running certbot (even without the validation changes) are not worth it.
You are the perfect usecase for certbot. The rest of us aren't.
I'm not sure what you mean that the process can break. The way to use certificates are through haproxy/nginx/apache which are definitely more tested and stable than certbot. Half the internet still uses them and they support much more legacy than LE.
Letsencrypt was disruptive because it was free. It was not disruptive because of certbot.
There is probably a list of sites which forgot that there was a process. I saw that happening in Crédit Lyonnais (a french bank). On a Saturday night.