4 ms·

I've changed my mind about the short lived cert stuff after seeing what is enabled by IP address certificates with the HTTP-01 verification method. I don't even

by bob1029 9mo ago

I've changed my mind about the short lived cert stuff after seeing what is enabled by IP address certificates with the HTTP-01 verification method. I don't even bother writing the cert to disk anymore. There is a background thread that checks to see if the current instance of the cert is null or older than 24h. The cert selector on aspnetcore just looks at this reference and blocks until its not null. Being able to distribute self-hostable software to users that can be deployed onto a VM and made operational literally within 5 minutes is a big selling point. Domain registration & DNS are a massive pain to deal with at the novice end of the spectrum. You can combine this with things like https://checkip.amazonaws.com https://checkip.amazonaws.com to build properly turnkey solutions.

cube00 9mo ago
Pretty risky given the rate limits of Let's Encrypt are non negotiable with no choice but to wait them out.
- muvlon 9mo ago
  They are quite literally negotiable: https://isrg.formstack.com/forms/rate_limit_adjustment_request https://isrg.formstack.com/forms/rate_limit_adjustment_reque... There are also a bunch of rate limit exemptions that automatically apply whenever you "renew" a cert: https://letsencrypt.org/docs/rate-limits/#non-ari-renewals https://letsencrypt.org/docs/rate-limits/#non-ari-renewals. That means whenever you request a cert and there already is an issued certificate for the same set of identities.
  - dextercd 9mo ago
    Your comment is 100% correct, but I just want to point out that this doesn't negate the risks of bob's approach here. LE wouldn't see this as a legitimate reason to raise rate limits, and such a request takes weeks to handle anyway. Indeed, some rate limits don't apply for renewals but some still do.
  - cube00 9mo ago
    If you’ve hit a rate limit, we don’t have a way to temporarily reset it. [1] From your link move the adjustments to production twice monthly. I don't know about your use case but I couldn't risk being unable to get a new certificate for at least a fortnight because my container was stuck in a restart loop. [1]: https://letsencrypt.org/docs/rate-limits/ https://letsencrypt.org/docs/rate-limits/
inahga 9mo ago
You should persist certs somewhere. Otherwise your availability is heavily tied to LE’s uptime.
- tialaramex 9mo ago
  Technically, because Let's Encrypt always publishes all requested certificates to the logs (this isn't mandatory, it's just easier for most people so Let's Encrypt always does this) your tool can go look in the logs to get the certificate. You do need to know your private key, nobody else ever knew that so if you don't have that then you're done.
  - xyzzy_plugh 9mo ago
    Now you depend on CT log providers uptime, which as far as I can tell is worse than LE.
    - pests 9mo ago
      Google, Cloudflare, Let's Encrypt, DigiCert, GlobalSign and others run logs. Here is the list Chrome checks: https://www.gstatic.com/ct/log_list/v3/log_list.json https://www.gstatic.com/ct/log_list/v3/log_list.json While they do not have direct SLAs, they still have to comply with rules enforced by browser vendors, as they will remove you from CT checks and you'll be marked retired/untrusted (you can find some in the above list). This means a 99% uptime on a 90 day rolling average, a 1 minute update frequency for new entries (24 hours on an older RFC). No split views, strict append-only, sharding by year, etc. I think OP's original idea would work.
      - plagiat0r 9mo ago
        X509 certificates published in CT logs are "pre-certificates". They contains a poison extension so you don't be able to use them with your private key. The final certificate (without poison and with SCT proof) is usually not published in any CT logs but you can submit it yourself if you wish. OP idea won't work unless OP will submit final certificate himself to CT logs.

by bob1029 9mo ago

cube00 9mo ago

Pretty risky given the rate limits of Let's Encrypt are non negotiable with no choice but to wait them out.

muvlon 9mo ago
They are quite literally negotiable: https://isrg.formstack.com/forms/rate_limit_adjustment_request https://isrg.formstack.com/forms/rate_limit_adjustment_reque... There are also a bunch of rate limit exemptions that automatically apply whenever you "renew" a cert: https://letsencrypt.org/docs/rate-limits/#non-ari-renewals https://letsencrypt.org/docs/rate-limits/#non-ari-renewals. That means whenever you request a cert and there already is an issued certificate for the same set of identities.
- dextercd 9mo ago
  Your comment is 100% correct, but I just want to point out that this doesn't negate the risks of bob's approach here. LE wouldn't see this as a legitimate reason to raise rate limits, and such a request takes weeks to handle anyway. Indeed, some rate limits don't apply for renewals but some still do.
- cube00 9mo ago
  If you’ve hit a rate limit, we don’t have a way to temporarily reset it. [1] From your link move the adjustments to production twice monthly. I don't know about your use case but I couldn't risk being unable to get a new certificate for at least a fortnight because my container was stuck in a restart loop. [1]: https://letsencrypt.org/docs/rate-limits/ https://letsencrypt.org/docs/rate-limits/

inahga 9mo ago

You should persist certs somewhere. Otherwise your availability is heavily tied to LE’s uptime.

tialaramex 9mo ago
Technically, because Let's Encrypt always publishes all requested certificates to the logs (this isn't mandatory, it's just easier for most people so Let's Encrypt always does this) your tool can go look in the logs to get the certificate. You do need to know your private key, nobody else ever knew that so if you don't have that then you're done.
- xyzzy_plugh 9mo ago
  Now you depend on CT log providers uptime, which as far as I can tell is worse than LE.
  - pests 9mo ago
    Google, Cloudflare, Let's Encrypt, DigiCert, GlobalSign and others run logs. Here is the list Chrome checks: https://www.gstatic.com/ct/log_list/v3/log_list.json https://www.gstatic.com/ct/log_list/v3/log_list.json While they do not have direct SLAs, they still have to comply with rules enforced by browser vendors, as they will remove you from CT checks and you'll be marked retired/untrusted (you can find some in the above list). This means a 99% uptime on a 90 day rolling average, a 1 minute update frequency for new entries (24 hours on an older RFC). No split views, strict append-only, sharding by year, etc. I think OP's original idea would work.
    - plagiat0r 9mo ago
      X509 certificates published in CT logs are "pre-certificates". They contains a poison extension so you don't be able to use them with your private key. The final certificate (without poison and with SCT proof) is usually not published in any CT logs but you can submit it yourself if you wish. OP idea won't work unless OP will submit final certificate himself to CT logs.