121–130 of 197 posts
And most of that is because LE [still] doesn't issue wildcard certs, nor does it really plan to :(
Earlier quoted context omitted.
What's the justification of traditional providers to charge for the certificates? Do they offer services or extended certificates that "Let's encrypt" doesn't or is it just a matter of "no one tried to offer it for free before"?
No-one did free which works in all browsers before.
Earlier quoted context omitted.
Currently their only upside is that they provide wildcard (and EV) certificates. EV certs can't be automated for obvious reasons, but LE doesn't support wildcard certs because they don't believe there's a secure way of providing an automated way of getting them. Given that traditional CA models don't actually have much more security than LE (in fact from personal experience they're far less secure), I wonder whether…
Why is providing wildcard certs not secure???? Amazon seems to do it?
There are vanishingly few reasons to ever share private keys across multiple automated systems. This is not one of them. (Are your systems not automated? Fix that.)
Earlier quoted context omitted.
Let's Encrypt's renewal notifications don't cover cases where a new certificate was issued, but for some reason isn't being used by a server, perhaps because the ACME client ran into a problem, or because the server wasn't reloaded. It's useful, but it doesn't quite replace actual certificate expiration monitoring.
This smells like a problem in your server configuration management tooling, yeah?
Genuine question: Are the other smaller cert-issuing services going out of business? If not, what has been their response to LetsEncrypt? Not that all of them should survive, there are a lot of crappy services that deserved this. But I'm just trying to place myself in their CEOs position and wondering how the game plan should be.
Earlier quoted context omitted.
This smells like a problem in your server configuration management tooling, yeah?
Not monitoring something you rely on - like the expiration date of your certificate - would be the problem. Assuming that the entire process is bug-free sounds like a bit of a gamble.
SSL certificate from a traditional provider valid for a year: $10. SSL certificate from a traditional provider valid for two years: $20. Automated SSL certificate generation and deployment via LetsEncrypt with zero human intervention and more importantly zero human intervention to renew it going forward - priceless . --- That's the real value for me. At $10/cert, that's not even a rounding error. But manually generat…
That also means one can make effectual suggestions to webmasters.
I told a webmaster who maintains a forum about LetsEncrypt a few months ago and that I'd help them set it up just so that users aren't practicing the bad habit of logging in over http. I just went back to check and the forum is now https by default using LetsEncrypt certificate.
I couldn't have achieved that a few years ago. The pain of setting up SSL would have inescapably digressed into a low-quality flamewar about how PKI is broken.
Earlier quoted context omitted.
Not monitoring something you rely on - like the expiration date of your certificate - would be the problem. Assuming that the entire process is bug-free sounds like a bit of a gamble.
If your CM tooling is working correctly (because you wrote tests, yeah?), it should scream and fail in this situation. "I should never have a cert that's out of date."
Earlier quoted context omitted.
If your CM tooling is working correctly (because you wrote tests, yeah?), it should scream and fail in this situation. "I should never have a cert that's out of date."
Again, you're assuming whatever automation you built is bug-free. Practice shows that sufficiently-complex software is never bug-free, no matter how many tests you wrote. Checking the expiration date on a certificate is easy, so why not have that safety net?
I'm saying, you're putting it in the wrong place. It's not a monitoring problem, it's a configuration management problem--"I have defined a policy, am I in compliance with that policy?". And, from experience consulting with a pretty wide range of clients, putting it in the monitoring stack encourages manual work instead of automation. Instead of having active and self-correcting systems, you create passive and manually reactive ones. Monitoring is for stuff you have to react to. Automation and automation testing is for stuff you should never be reacting to.