4 ms·
Anyone know what, if anything, this means for the rate limits on issuing certs on a given domain? That was the one thing that was stopping us from making SSL co
by azdle 11y ago
Anyone know what, if anything, this means for the rate limits on issuing certs on a given domain? That was the one thing that was stopping us from making SSL completely automatic on our customer's domains.
- mholt 11y agoThey recently raised the rate limit on certificates per domain per week from 5 to 20. https://community.letsencrypt.org/t/rate-limits-for-lets-encrypt/6769/2?u=mholt https://community.letsencrypt.org/t/rate-limits-for-lets-enc...
- joshmoz 11y agoIt's also worth pointing out that you can have up to 100 SANs in a certificate, so you can technically issue for up to 20x100 (2000) subdomains per week.
- shawabawa3 11y agoWhen I hit a rate limit on sub1.example.com, it let me create a certificate with a SAN for sub1.example.com and sub2.example.com So I think it's actually essentially unlimited, you just can't request the exact same certificate more than 20 times per week
- nsgi 11y agoThere are separate rate limits for FQDNs and domain names. The former is 5, the latter is 20.
- stanmancan 11y agoForgive my ignorance, but can anyone please explain this a bit more? I've only configured SSL on small, single server sites, but when I buy a SSL cert once a year. I believe LE certs expire after 6 weeks? Why would you ever even need to issue 5 certs for the same domain in a week?
- Spivak 11y agosubdomain1.mywebsite.com subdomain2.mywebsite.com subdomain3.mywebsite.com ... An extreme example would be DDNS providers like No-IP.
- e12e 11y agoAnd/or to expand on Spivak's answer: static.example.com api.example.com db1.example.com db2.example.com www.example.com www2.example.com loadbalancer.example.com etc [ed to add:] Note that while you can just use example.com, or add alternate names, that would mean that a compromise of www1.example.com also compromised the key used for db1.example.com etc - which would largely defeat the purpose of splitting up different services across different vms/zones/machines in terms of security compartmentalization, because you'd only need one copy of the key to mitm all services. (For some setups, where everything is a set of web apps/services, and TLS is terminated at the load-balancer/reverse proxy, this is a moot point -- but that's not always a good idea. See eg: how Google suddently rushed to encrypt their intranet after it turned out NSA had been happily snooping on everything from the "inside" via datacenter links that I assume were across rented "dark"/dedicated fiber).