4 ms·
ACME is a standardized protocol (RFC8555) and there are more providers than Let's Encrypt, and you can switch transparently. That combined with the standard pro
by tlamponi 5y ago
ACME is a standardized protocol (RFC8555) and there are more providers than Let's Encrypt, and you can switch transparently. That combined with the standard procedure of renewing a few weeks before the expiration date lets one handle even a total failure rather nicely.
Some other ACME providers I know of:
- ZeroSSL.com
- BuyPass.com
- SSL.com
(most of those provide free certs in some form, but some with limitations and may then ask for money if you want more features).
https://datatracker.ietf.org/doc/html/rfc8555 https://datatracker.ietf.org/doc/html/rfc8555
- kouteiheika 5y ago> and you can switch transparently > ZeroSSL.com I kinda wish people would stop recommending them. This might have changed, but last time I tried ZeroSSL (~a year ago) it was not RFC 8555 compliant (specifically section 7.3.1), and you were basically supposed to use their own proprietary API to deal with the issue. So you can't always switch transparently. If you need an alternative use Buypass. Also free, and they're actually RFC 8555 compliant.
- tlamponi 5y agoFWIW: I'm not recommending anything, just listing a few providers that claim to be ACME conform, to be specific I took the list from the acme.sh: https://github.com/acmesh-official/acme.sh#supported-ca https://github.com/acmesh-official/acme.sh#supported-ca But it seems that acme.sh got bought by zero ssl, which would explain that it's their default now.. Out of honest interest, where did they fail to honor "7.3.1 Finding an Account URL Given a Key"?
- kouteiheika 5y ago> Out of honest interest, where did they fail to honor "7.3.1 Finding an Account URL Given a Key"? Well... it doesn't work. Let me quote the RFC: > If the server receives a newAccount request signed with a key for which it already has an account registered with the provided account key, then it MUST return a response with status code 200 (OK) and provide the URL of that account in the Location header field. With ZeroSSL you could only call `newAccount` once; any subsequent call will fail, while according to the RFC it should return the URL of the account. So you have to either a) use their proprietary API to recover the URL (I sent them a bug report for this and that's what they basically told me), or b) save the URL along with the account key (which you don't have to do for any other ACME provider).
- iostream23 5y agoBuypass saved the day last month. We were suddenly not working in older browsers due to rhe expired root cert, and just one server flag on the certbot invocation and now we are good until 2040. Yay ACME protocol and yay Buypass
- gsich 5y agoWhats the issue with that? I use ZeroSSL and never had to use their non-ACME-API.
- pronoiac 5y agoSwitching to ZeroSSL helped me when some clients failed to handle the root cert switchover did Let's Encrypt at, what, the end of September? The ZeroSSL root goes waaay back: https://help.zerossl.com/hc/en-us/articles/360058294074-ZeroSSL-Compatibility-List https://help.zerossl.com/hc/en-us/articles/360058294074-Zero...
- jraph 5y ago> you can switch transparently Unless you use some sort of certificate (authority) pinning.
- tialaramex 5y agoHowever, your pinning strategy, at whatever level, should have planned fallbacks. That can mean if you pin keys you have a second pinned key that exists only on a HSM in somebody's safe ready for emergencies, or in this case it means picking an extra CA and pinning them too, ready for such scenarios. If your pinning doesn't account for such things you sacrificed availability for security which is likely a bad choice.