3 ms·

There is a conceptual work around on wildcard certs, which is to provision on demand essentially, since the process is automated and free. Issues with this app

by mey 10y ago

There is a conceptual work around on wildcard certs, which is to provision on demand essentially, since the process is automated and free. Issues with this approach, complexity of implementation, throttling (only so many certs per I think week are allowed per ip address)

drdaeman 10y ago
Yes, I know, I've followed IETF ACME WG mailing list on the subject, as well as ACME GitHub account issue tracker. It's being worked on and is probably coming someday, but not here yet. Which makes LE infeasible for some use cases. For now.
tokenizerrr 10y ago
It's actually worse. The current rate limits are: > The current rate limits are 20 certificate issuances per domain per 7 days, 5 certificates per unique set of FQDNs per 7 days, 500 registrations per IP per 3 hours, 300 pending authorizations per account per week and 100 subject alternative names per certificate. See https://community.letsencrypt.org/t/rate-limits-for-lets-encrypt/6769 https://community.letsencrypt.org/t/rate-limits-for-lets-enc... for more. Which means that you can add at most 20 subdomains a week. Any more than that, and you are SOL.
- dspillett 10y ago
  > Which means that you can add at most 20 subdomains a week. Any more than that, and you are SOL. Though the use cases for needing 21+ new subdomains in a week are few and far between I expect, and probably all cases where a wildcard cert would be a better choice (which LE doesn't yet support). Note that it is 20 certificates though, not 20 sub-domains, and LE lets you include more then sub-domain per certificate. So if you can group the sub-domains together you can get many more then 20 in the period.
  - tokenizerrr 10y ago
    You're right, I glossed over that distinction. My use case is provisioning domain names for servers/containers the moment they come up, and it's not really feasable to batch that.
    - dspillett 10y ago
      And if other people have control over the resulting containers in that circumstance a wildcard wouldn't be suitable either, unless it is only used for HTTPS (and the local LAN/VLAN can be trusted) in which case you can put a proxy in front of the containers to handle it to avoid each container needing a copy of the private key. I can see why limits are in place though, it protects them from abuse by badly written integration code and actions that are less accidental. Perhaps they'll lift the the limits a bit as the service grows and stabilises. Or introduce a cheap-but-not-free service for people requiring something beyond the standard submission rate limits.

by mey 10y ago

drdaeman 10y ago

Yes, I know, I've followed IETF ACME WG mailing list on the subject, as well as ACME GitHub account issue tracker. It's being worked on and is probably coming someday, but not here yet. Which makes LE infeasible for some use cases. For now.

tokenizerrr 10y ago

It's actually worse. The current rate limits are: > The current rate limits are 20 certificate issuances per domain per 7 days, 5 certificates per unique set of FQDNs per 7 days, 500 registrations per IP per 3 hours, 300 pending authorizations per account per week and 100 subject alternative names per certificate. See https://community.letsencrypt.org/t/rate-limits-for-lets-encrypt/6769 https://community.letsencrypt.org/t/rate-limits-for-lets-enc... for more. Which means that you can add at most 20 subdomains a week. Any more than that, and you are SOL.

dspillett 10y ago
> Which means that you can add at most 20 subdomains a week. Any more than that, and you are SOL. Though the use cases for needing 21+ new subdomains in a week are few and far between I expect, and probably all cases where a wildcard cert would be a better choice (which LE doesn't yet support). Note that it is 20 certificates though, not 20 sub-domains, and LE lets you include more then sub-domain per certificate. So if you can group the sub-domains together you can get many more then 20 in the period.
- tokenizerrr 10y ago
  You're right, I glossed over that distinction. My use case is provisioning domain names for servers/containers the moment they come up, and it's not really feasable to batch that.
  - dspillett 10y ago
    And if other people have control over the resulting containers in that circumstance a wildcard wouldn't be suitable either, unless it is only used for HTTPS (and the local LAN/VLAN can be trusted) in which case you can put a proxy in front of the containers to handle it to avoid each container needing a copy of the private key. I can see why limits are in place though, it protects them from abuse by badly written integration code and actions that are less accidental. Perhaps they'll lift the the limits a bit as the service grows and stabilises. Or introduce a cheap-but-not-free service for people requiring something beyond the standard submission rate limits.