> And, per other comments, this will make LE the only viable option to modernize, and thus much more of a central point of failure than before.
Let's Encrypt isn't the only free ACME provider, you can take your pick from them, ZeroSSL, SSL.com, Google and Actalis, or several of them for redundancy. If you use Caddy that's even the default behavior - it tries ZeroSSL first and automatically falls back to Let's Encrypt if that fails for whatever reason.
> If you use Caddy that's even the default behavior - it tries ZeroSSL first and automatically falls back to Let's Encrypt if that fails for whatever reason.
No, that's false. It's the other way around.
“If Caddy cannot get a certificate from Let's Encrypt, it will try with ZeroSSL”. Source: https://caddyserver.com/docs/automatic-https#issuer-fallback
Which makes sense, since the ACME access to ZeroSSL must go through an account created by a manual registration step. Unless the landscape changed very recently, LE is still the only free ACME that does not require registration. Source: https://poshac.me/docs/v4/Guides/ACME-CA-Comparison/#acme-ca...
My bad, I misremembered the order. You're right that ZeroSSL requires credentials to get free certificates, but Caddy has special-case support for generating those credentials automatically provided you specify an email address in the config, so it's almost transparent to the user.
https://caddy.community/t/using-zerossls-acme-endpoint/9406
Correction: the default behavior is to use Let's Encrypt alone, but if you provide an email then it's Let's Encrypt with fallback to ZeroSSL.
LE has some gnarly rate limiting rules, so I use ZeroSSL. Works out great for my purposes.
That's the reason I switched. I had an issue where a path was not mounted correctly and we blew through our limits.
Oh, on LE the Rate Limit Adjustment Request forms the contractual things (if that's what they are?) do not load: https://isrg.formstack.com/forms/rate_limit_adjustment_reque...
Hm, it's supposed to be https://letsencrypt.org/docs/integration-guide/ - but it looks like the link is broken. I'll fix it.
How are all those free CAs financed?
Let's Encrypt is a non-profit funded by donations and corporate sponsorships.
ZeroSSL, SSL.com and Actalis offer paid services on top of their basic free certificates.
Google is Google.
Ah, that makes sense. Thanks!
> Google is Google.
So your "free" ssl certs are provided by surveillance capitalism, and paid for with your privacy (and probably your website user's privacy too)?
The ethical side is up to you, but in a strictly technical sense I don't think there's much that Google could do to intrude on your users privacy as a result of them issuing your SSL certificate, even if they wanted to. AIUI the ACME protocol never lets the CA see the private key, only the public key, which is public by definition anyway.
A more realistic concern with using Googles public CA is they may eventually get bored and shut it down, as they tend to do. It would be prudent to have a backup CA lined up.
> The ethical side is up to you, but in a strictly technical sense I don't think there's much that Google could do to intrude on your users privacy as a result of them issuing your SSL certificate, even if they wanted to.
I'm not sure that's technically true. As a CA they definitely have the power to facilitate a MitM attack. They can also issue fraudulent certificates.
> AIUI the ACME protocol never lets the CA see the private key, only the public key, which is public by definition anyway.
That has more to do with HTTPS end to end encryption, not the protocol of issuance.
It absolutely has to do with ACME. There used to be CAs that would generate a service certificate including private key for you. This is obviously a terrible idea, but it is made impossible by ACME only allowing exchanging CSRs for certs.
Ah, I see
> and paid for with your privacy (and probably your website user's privacy too)?
That's not really how ssl certs work - google isn't getting any information they wouldn't have otherwise had by issuing the ssl cert.