Does anyone know of a “set it and forget it” alternative to Let’s Encrypt?
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.
Regardless of what you end up using you need to have your own monitoring if you care about availability.
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.
Same here. I had them running for a small informational website, and they took the site down for several days via surprise cert problems. I may switch to a paid provider.
The big cloud services offer solutions for that, although with some caveats. AWS for example creates a cert free of charge with automatic renewal, but it won't give out any private keys. So TLS is terminated at their load balancer, which you would have to use to my knowledge. I just hope Amazon is too rich to conduct widespread industrial espionage.
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.
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)
But I think it would be far better for them to focus on alerting webmasters if someone does manage to get a new certificate issued for a domain before the old one expires.
Certbot should reference the old certificate when doing a renewal. If someone registers a new certificate while an old one is valid and without referencing the old one, the owner of the old certificate should be notified loudly (sms, different-domain email, etc). Same if they register a certificate through a different provider.
Today all of the above is possible with certificate transparency logs, but nobody looks in them, so they're useless.
>Today all of the above is possible with certificate transparency logs, but nobody looks in them, so they're useless.
I check mine once or twice a month manually, but it is pretty trivial to monitor it automatically as well, e.g. there are APIs for crt.sh or they even offer direct public read access to their database.
I believe certificate users should remain responsble for their own monitoring. Alerting as you say would be very annoying since you couldn't preemptively replace certs without getting alerted unecesarily, and it would divert Let's Encrypt developer resources away from more useful projects.
How can someone "reference" an old certificate with CT data? CT logs only contain precerts and certs, right?
I suppose one could compare the public key of two leaf certificates, but reusing the private key is also a bad practice.
From CA end, it could check if the certificate is requested from the same account key. One can even use a DNS record to public the account keys (CAA + TLSA).
For readers interested in understanding the technical details about potential BGP attacks on domain validation, which serve as a motivation for Let's Encrypt's multi-perspective validation deployment, see the following paper from USENIX Security: https://www.usenix.org/conference/usenixsecurity18/presentat...
I don't see how this resolves BGP hijacking attacks? If I announce a more specific route all four locations should still land on my hijacked network... Or is this trying to race the BGP propagation?
It doesn't "resolve" BGP attacks. The point is an attacker would have to pull off three or four successful attacks at once, which is harder than pulling off just one, especially if they hope to go unnoticed.
If the domain is hosted on a /24, then more specific routes will be filtered out by default in most ASes. Also, with the increasing adoption of RPKI, in conjunction with its maxlength option, more specific attacks will be a challenge for adversaries.
I may be naive, but it seems like it might be more secure if the first step was to deploy a self-signed cert on the server, step 2, give Let's Encrypt the public key of the self signed cert, so Let's Encrypt can validate who you are, then proceed with Let's Encrypt's regular validation process, obviously replacing your self-signed cert with the one issued by Let's Encrypt at the end.
We'll see how it works in practice. After reading the intro to what they're doing I think I'll update a few certs before they expire to make sure it works, but from what I've read I don't anticipate any problems.
FYI, Last week, before I unblocked my firewall, when I tried to get certs from LE, it tried to knock me some 5 or 6 times from different IPs. Checked some ASNs, one was from AMAZON, the other one I don't remember.
It's not going to make it easier, but if you can already answer challenges - then it won't make it any harder.
You just don't stop answering challenges until the cert gets issued.
I don't know why anyone would have stopped answering challenges after the first request anyway. Surely the default assumption should be that everyone has network & processing failures, and hey maybe ACME would need to check again if something broke before the cert was signed.
No changes are required, unless you had some kind of IP restriction on who your server may be contacted by. Which your simple static site is probably fine with.
The first paragraph already highlights the issue I have with it. I don't want to loosen my firewall, some countries and their IP ranges just need not access my server.
I have my certs issued to a VM this is not accessible via HTTP(S) anyway, just DNS. It runs a small DNS server which answers to _acme-challenge.* requests "forwarded" via CNAME. As that is the only part of is visible to the rest it has a very small security surface to worry about. It then pushes out the keys & certs to the places that need them (directly in the case of local machines, less directly for some others).
I set that up originally for a wildcard, as http validation is not supported for them and I didn't fancy mucking about automating updating the main bind instances, but it is convenient for the others too and will be unaffected by these changes.
Not a perfect solution for everyone of course, copies of all the keys are in one place for one thing, and it all in one place could be bad or good for maintenance (single point of failure, but single service to monitor & maintain), but worth considering if you expect problems with http validation.
> some countries and their IP ranges just need not access my server
I'm guessing that they won't be using locations that are commonly blocked in this way anyway. And if they do happen to use one, you may be fine as only two of the three external checks need to be responded to.
And how does filtering on the IP range of a country prevent traffic from that country? Or are you also blocking every known proxy and VPN service? Are you sure that your strict firewall even provides the security you wish it did?
Either way, letsencrypt will probably have a somewhat fixed pool of these challenge validation IP addresses/ranges, so adding those to a white list should probably work with a strict firewall.
It took me three tries with scripts enabled; perhaps they're overloaded.
(Taking 5MB and 2s to send 500 words of text can do that, but since the primary audience of Let's Encrypt is web folks, there's some schadenfreude in my weltschmerz.)
[+] [-] jaas|6 years ago|reply
https://letsencrypt.org/2020/02/19/multi-perspective-validat...
Maybe we can get the link changed?
[+] [-] hedora|6 years ago|reply
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.
[+] [-] stevekemp|6 years ago|reply
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.
[+] [-] wiremaus|6 years ago|reply
[+] [-] raxxorrax|6 years ago|reply
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.
[+] [-] Crosseye_Jack|6 years ago|reply
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)
[+] [-] puzzlingcaptcha|6 years ago|reply
[+] [-] driverdan|6 years ago|reply
What happened? Was it their fault or yours?
[+] [-] sandGorgon|6 years ago|reply
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.
[+] [-] londons_explore|6 years ago|reply
But I think it would be far better for them to focus on alerting webmasters if someone does manage to get a new certificate issued for a domain before the old one expires.
Certbot should reference the old certificate when doing a renewal. If someone registers a new certificate while an old one is valid and without referencing the old one, the owner of the old certificate should be notified loudly (sms, different-domain email, etc). Same if they register a certificate through a different provider.
Today all of the above is possible with certificate transparency logs, but nobody looks in them, so they're useless.
[+] [-] waste_monk|6 years ago|reply
I check mine once or twice a month manually, but it is pretty trivial to monitor it automatically as well, e.g. there are APIs for crt.sh or they even offer direct public read access to their database.
I believe certificate users should remain responsble for their own monitoring. Alerting as you say would be very annoying since you couldn't preemptively replace certs without getting alerted unecesarily, and it would divert Let's Encrypt developer resources away from more useful projects.
[+] [-] Ayesh|6 years ago|reply
I suppose one could compare the public key of two leaf certificates, but reusing the private key is also a bad practice.
From CA end, it could check if the certificate is requested from the same account key. One can even use a DNS record to public the account keys (CAA + TLSA).
[+] [-] mittalprat|6 years ago|reply
[+] [-] dgacmu|6 years ago|reply
http://www.cs.cmu.edu/~dga/papers/perspectives-usenix2008.pd...
[+] [-] spydum|6 years ago|reply
[+] [-] jaas|6 years ago|reply
[+] [-] mittalprat|6 years ago|reply
[+] [-] Rebles|6 years ago|reply
[+] [-] smw|6 years ago|reply
[+] [-] kardos|6 years ago|reply
[+] [-] foota|6 years ago|reply
[+] [-] sysashi|6 years ago|reply
[+] [-] oblib|6 years ago|reply
LE has been great for me.
[+] [-] jve|6 years ago|reply
[+] [-] creeble|6 years ago|reply
[+] [-] progval|6 years ago|reply
[+] [-] eric_b|6 years ago|reply
[+] [-] paranoidrobot|6 years ago|reply
You just don't stop answering challenges until the cert gets issued.
I don't know why anyone would have stopped answering challenges after the first request anyway. Surely the default assumption should be that everyone has network & processing failures, and hey maybe ACME would need to check again if something broke before the cert was signed.
[+] [-] GuyPostington|6 years ago|reply
[+] [-] teraflop|6 years ago|reply
[+] [-] certera|6 years ago|reply
https://docs.certera.io
[+] [-] snapetom|6 years ago|reply
[+] [-] polyphonicist|6 years ago|reply
I run a simple static website served with Nginx. I would like to know if this change has any impact on me.
[+] [-] mcpherrinm|6 years ago|reply
[+] [-] craftyguy|6 years ago|reply
[+] [-] Avamander|6 years ago|reply
[+] [-] dspillett|6 years ago|reply
I set that up originally for a wildcard, as http validation is not supported for them and I didn't fancy mucking about automating updating the main bind instances, but it is convenient for the others too and will be unaffected by these changes.
Not a perfect solution for everyone of course, copies of all the keys are in one place for one thing, and it all in one place could be bad or good for maintenance (single point of failure, but single service to monitor & maintain), but worth considering if you expect problems with http validation.
> some countries and their IP ranges just need not access my server
I'm guessing that they won't be using locations that are commonly blocked in this way anyway. And if they do happen to use one, you may be fine as only two of the three external checks need to be responded to.
[+] [-] elmo2you|6 years ago|reply
Either way, letsencrypt will probably have a somewhat fixed pool of these challenge validation IP addresses/ranges, so adding those to a white list should probably work with a strict firewall.
[+] [-] vegardx|6 years ago|reply
[+] [-] ahyattdev|6 years ago|reply
[+] [-] cm2187|6 years ago|reply
[+] [-] scarejunba|6 years ago|reply
[+] [-] sergiotapia|6 years ago|reply
[+] [-] MrStonedOne|6 years ago|reply
[+] [-] kps|6 years ago|reply
(Taking 5MB and 2s to send 500 words of text can do that, but since the primary audience of Let's Encrypt is web folks, there's some schadenfreude in my weltschmerz.)
[+] [-] thenewnewguy|6 years ago|reply
Edit: Ah, upon testing it breaks if you have 1st party JS allowed but not 3rd party. This is pretty reasonable in my opinion.
[+] [-] GuyPostington|6 years ago|reply
[+] [-] codegladiator|6 years ago|reply
[+] [-] zzo38computer|6 years ago|reply
[+] [-] xfalcox|6 years ago|reply