5 ms·

I like Let's Encrypt's free certificates! But I don't like centralization where failure in a centralized service may render millions of websites inaccessible...

by pulse7 5y ago

I like Let's Encrypt's free certificates! But I don't like centralization where failure in a centralized service may render millions of websites inaccessible... It is somehow against the spirit of the "inter-net" where many independent networks and computers are connected and work even if some fail...

kenniskrag 5y ago
That's why we renew our certs more than one day in advance.
- cblconfederate 5y ago
  I assume most people have a cron job to do that. The thing is, if it fails for a number of consecutive times then you won't be able to renew it for a period of time IIRC.
  - kenniskrag 5y ago
    The cron should run always. They have a rate limit for the amount of renewed certs. This doesn't apply if you don't reach their servers or don't get a cert. But if you have a problem with a CA just switch to another which supports your bot (e.g. acme compliant CAs).
    - tialaramex 5y ago
      Right, if your scripts can screw up, after the CA issued a certificate, their costs are locked in, (and thus Let's Encrypt rate limits apply here) and you should make effort to be able to recover the key and certificate if you fail rather than start over. The private key only you have, so that's the thing you most need to avoid throwing away over and over due to a bug. If you lose the certificate, that's a public document, you can just get another copy manually if necessary.
  - iso1631 5y ago
    If you renew 30 days ahead of schedule, your monitoring presumably goes red at least 2 weeks before expiry so you have plenty of notice to fix it.
- ajsnigrutin 5y ago
  Some people renew them after someone calls them that the page is inaccessible... ...not naming names, but I can see one above the bathroom sink. (yes yes, I know, I know...)
zinekeller 5y ago
I mean it still doesn't fully solve the problem, but I've set-up mine so that it connects to both Let's Encrypt and ZeroSSL's certificate chain (with LE getting priority), and considering adding BuyPass into the mix. I know that this isn't the true solution (some proposed a DNS-based system of sending public certificates, which unfortunately can be intercepted if your zone cannot use DNSSEC because your TLD manager didn't bother them).
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 ago
    FWIW: 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).
foepys 5y ago
No problem, since ACME is an open protocol, you can use multiple providers at the same time. I didn't use them but apparently ZeroSSL and SSL.com issue free certs as well.
mschuster91 5y ago
> But I don't like centralization where failure in a centralized service may render millions of websites inaccessible Clients are encouraged to renew their certificates a couple of days prior to expiration, precisely to make sure that in the case of a disruption there is still some buffer in time to prevent expired certs being served.
- marcan_42 5y ago
  Standard practice is to renew 30 days before expiry. This gives you plenty of time to deal with issues.
jayflux 5y ago
Certs renew like a month before expiry if using the bot, so it would need to be down a long time before sites became inaccessible. (It was down for 20 mins) There are also other services that offer this sort of thing, they’re just lesser known.
deleted 5y ago
[deleted]
the_mitsuhiko 5y ago
If only there was a way to use a different CA on renewal!

by pulse7 5y ago

kenniskrag 5y ago

That's why we renew our certs more than one day in advance.

cblconfederate 5y ago
I assume most people have a cron job to do that. The thing is, if it fails for a number of consecutive times then you won't be able to renew it for a period of time IIRC.
- kenniskrag 5y ago
  The cron should run always. They have a rate limit for the amount of renewed certs. This doesn't apply if you don't reach their servers or don't get a cert. But if you have a problem with a CA just switch to another which supports your bot (e.g. acme compliant CAs).
  - tialaramex 5y ago
    Right, if your scripts can screw up, after the CA issued a certificate, their costs are locked in, (and thus Let's Encrypt rate limits apply here) and you should make effort to be able to recover the key and certificate if you fail rather than start over. The private key only you have, so that's the thing you most need to avoid throwing away over and over due to a bug. If you lose the certificate, that's a public document, you can just get another copy manually if necessary.
- iso1631 5y ago
  If you renew 30 days ahead of schedule, your monitoring presumably goes red at least 2 weeks before expiry so you have plenty of notice to fix it.
ajsnigrutin 5y ago
Some people renew them after someone calls them that the page is inaccessible... ...not naming names, but I can see one above the bathroom sink. (yes yes, I know, I know...)

zinekeller 5y ago

I mean it still doesn't fully solve the problem, but I've set-up mine so that it connects to both Let's Encrypt and ZeroSSL's certificate chain (with LE getting priority), and considering adding BuyPass into the mix. I know that this isn't the true solution (some proposed a DNS-based system of sending public certificates, which unfortunately can be intercepted if your zone cannot use DNSSEC because your TLD manager didn't bother them).

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 ago
  FWIW: 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).

foepys 5y ago

No problem, since ACME is an open protocol, you can use multiple providers at the same time. I didn't use them but apparently ZeroSSL and SSL.com issue free certs as well.

mschuster91 5y ago

> But I don't like centralization where failure in a centralized service may render millions of websites inaccessible Clients are encouraged to renew their certificates a couple of days prior to expiration, precisely to make sure that in the case of a disruption there is still some buffer in time to prevent expired certs being served.

marcan_42 5y ago
Standard practice is to renew 30 days before expiry. This gives you plenty of time to deal with issues.

jayflux 5y ago

Certs renew like a month before expiry if using the bot, so it would need to be down a long time before sites became inaccessible. (It was down for 20 mins) There are also other services that offer this sort of thing, they’re just lesser known.

deleted 5y ago

[deleted]

the_mitsuhiko 5y ago

If only there was a way to use a different CA on renewal!