Seems LetsEncrypt treat westus.azurecontainer.io as one domain and has a limit on it. One of my new domain got this error:
Error: urn:ietf:params:acme:error:rateLimited :: There were too many requests of a given type :: Error finalizing order :: too many certificates already issued for: westus.azurecontainer.io: see https://letsencrypt.org/docs/rate-limits/
I’m wondering if LetsEncrypt can treat subdomain like mydomain.westus.azurecontainer.io as one and set rate limit for each one of them.
In this case, it happened automatically because azurecontainer.io is on the Public Suffix List, so Let’s Encrypt basically treats it like a TLD for rate limiting purposes. In other words, just like abc.com and xyz.com are separate because com is a public suffix, abc.azurecontainer.io and xyz.azurecontainer.io are separate because azurecontainer.io is a public suffix.
You’d have to talk to Microsoft about updating their Public Suffix List entries. It seems like a good idea, under the circumstances.
Edit: You could also talk to Microsoft about requesting a rate limit increase from Let’s Encrypt. But in both cases, Microsoft has to take action.
We are experimenting on how to properly use LetsEncrypt with Azure Container Instance. I guess because Azure File Share cannot handle symlink, so every time we launch containers, certbot will request a new certificate. That’s why we consumed 5 certificates in two days.
This is bad and a wrong configuration. The account informations (public + private key + account url) and the certificates (public and private keys) should always stored outside of containers.
So you are able to reuse these files.
There is a limit of 5 identical certificates per week. Create a new certificate, use it 60 days, then create a new. If every user of letsencrypt would create certificates daily (instead of one certificate every 60 days), that would be terrible.
Yes, we understand that. We consumed all certificates by mistake when experimenting it because symlink problem on mounted storage. Certbot not working as expected when the mounted storage cannot handle symlink.
For information, you can use the staging option for experiments: certificates generated on it are NO publicly trusted, but it has higher rate limits, so once you found the suitable configuration, you can generate your real (publicly trusted) certificates: https://letsencrypt.org/docs/staging-environment/