Queries on rate limiting and wildcard certificate

We recently hit rate limits on our test environment so I switched over to using a wildcard cert manually (I generated the cert locally and it's installed on all the test vms at build) I'd like to automate the renewal and provisioning of the cert using Traefiks inbuilt support. Our workflow is this:

  1. User requests test env
  2. VM spins up
  3. Traefik requests the wildcard cert for test-$number.subdomain.main.tld ($number always increments we don't reuse ids)

Would this trigger the rate limit if the wildcard cert already exists (but isn't on the vm)? My gut feeling is yes and I'd have to build an automation outside of this.

What do you mean when you say this?

Certificates for test-$number.subdomain.main.tld

Or *.test-$number.subdomain.main.tld

You'll hit the "certificates per registered domain" faster then the "duplicate certificates" rate limit.

On the other hand, if traefik can use a single certificate for *.subdomain.main.tld, that would be pretty safe.

5 Likes

Sorry! That's not very clear at all.

I have a wildcard cert for *.subdomain.main.tld

This then applies to test-1234.subdomain.main.tld where 1234 increments and we have multiple test envs spun up (we also have test-1234-eu, test-1234-us as well but not included those)

Traefik can handle requesting and renewing the *.subdomain.main.tld cert. I guess my question can be rephrased as will I hit rate limiting if traefik requests the wildcard cert multiple times a day and when attempting to renew.

yes, you will hit the 5/day duplicate certificate rate limit, if traefik does not reuse the certificate it already has. You should tell traefik to use the certificate it already has (it should be the default behavior, if persistence is working).

if working properly traefik won't try to renew a non-expiring certificate.

5 Likes

If Traefik is stupid enough to renew a perfectly fine certificate, then yes.

If Traefik is smart enough to re-use the already perfectly usable certificate without renewing it, then no.

1 Like

This is an anti-pattern. There is no reason to be constantly generating new certificates for ephemeral domains like this.

The certificate should be saved and loaded from persistent storage. Some servers and proxies support this natively. Other people will provision it from a central or cloud resource within the VM build script.

5 Likes

Yeah this is the conclusion I came to after all the helpful replies. I inherited this system so I'm working with what I've got.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.