Debugging Traefik Certificate Issues When Let's Encrypt Rate Limits Hit Your Domain

Why I Hit Let's Encrypt Rate Limits

I run a test environment on Proxmox where I spin up multiple VMs for different projects. Each VM gets its own subdomain under a shared domain I control. For a while, I was letting Traefik handle certificate requests automatically for every new VM. This worked fine until I started testing more aggressively.

One afternoon, Traefik stopped issuing certificates. The logs showed rate limit errors from Let's Encrypt. I had hit their 50 certificates per registered domain per week limit. My workflow was creating a new subdomain every time I spun up a test VM, and each one triggered a new certificate request. I didn't think about the cumulative effect until it broke.

What I Was Doing Wrong

My setup looked like this:

• Main domain: example.com
• Test subdomain pattern: test-1234.lab.example.com
• Each VM requested its own certificate through Traefik
• VMs were created and destroyed frequently during testing

Every time a new VM came up, Traefik made a fresh certificate request to Let's Encrypt. Since these were unique subdomains, they didn't qualify as duplicate certificates. They all counted against the 50-per-week limit for example.com.

I didn't realize how fast this added up. In one heavy testing week, I spun up over 60 VMs. That put me well over the limit, and suddenly nothing worked.

Switching to a Wildcard Certificate

The fix was to use a single wildcard certificate for *.lab.example.com instead of individual certificates for each subdomain. This meant one certificate could cover all test VMs, regardless of how many I created.

Here's what I did:

Manual Certificate Generation

I used certbot locally to request the wildcard certificate:

certbot certonly --manual \
  --preferred-challenges dns \
  -d "*.lab.example.com"

This required adding a DNS TXT record to prove I controlled the domain. I use Cloudflare for DNS, so I added the record manually through their dashboard. After verification, I downloaded the certificate files.

Installing the Certificate on VMs

I stored the certificate and key in a shared directory accessible to all VMs. During VM provisioning, I copied the files into place and configured Traefik to use them instead of requesting new certificates.

This worked, but it wasn't automated. Every 90 days, I had to manually renew the certificate and redistribute it to all VMs. That was fine for a temporary fix, but I wanted something better.

Automating Renewal with Traefik

Traefik has built-in support for requesting and renewing Let's Encrypt certificates. I wanted to use this for the wildcard certificate, but I ran into a problem: Traefik needs to handle DNS challenges for wildcard certificates, and that requires integration with my DNS provider.

I configured Traefik to use Cloudflare's API for DNS validation. Here's the relevant section from my traefik.yml:

certificatesResolvers:
  letsencrypt:
    acme:
      email: [email protected]
      storage: /letsencrypt/acme.json
      dnsChallenge:
        provider: cloudflare
        resolvers:
          - "1.1.1.1:53"
          - "8.8.8.8:53"

I also set environment variables for Cloudflare authentication:

[email protected]
CF_DNS_API_TOKEN=my-cloudflare-token

With this setup, Traefik could request and renew the wildcard certificate automatically. The certificate was stored in acme.json and shared across all VMs that needed it.

What Didn't Work

My first attempt at automation failed because I didn't understand how Traefik handles certificate storage. I tried to have each VM run its own Traefik instance and request the wildcard certificate independently. This didn't work because:

• Each Traefik instance made a separate request to Let's Encrypt
• Even though they were requesting the same certificate, the requests counted toward rate limits
• I hit the duplicate certificate limit quickly

The solution was to centralize certificate management. I ran one Traefik instance as a reverse proxy for all test VMs. It requested the wildcard certificate once and served it to all subdomains. Individual VMs no longer needed to handle certificates at all.

Understanding Let's Encrypt Rate Limits

After dealing with this, I spent time reading Let's Encrypt's rate limit documentation. Here's what matters for my use case:

• 50 certificates per registered domain per week: This is the main limit I hit. Every unique subdomain certificate counted toward this.
• Duplicate certificates: If you request the exact same certificate (same set of domain names) multiple times, you can issue up to 5 duplicates per week. This didn't help me because my subdomains were always different.
• Wildcard certificates: A single wildcard certificate counts as one certificate, no matter how many subdomains it covers.

The key insight: if you're creating many subdomains under the same domain, use a wildcard certificate. It's the only way to avoid rate limits in high-volume scenarios.

Current Setup

My current workflow looks like this:

1. One Traefik instance runs on a dedicated VM
2. Traefik requests and manages a wildcard certificate for *.lab.example.com
3. All test VMs route traffic through this Traefik instance
4. New VMs are added by updating Traefik's dynamic configuration, not by requesting new certificates

This setup hasn't hit rate limits since I switched. The wildcard certificate renews automatically every 60 days, and I don't have to think about it.

Key Takeaways

• Let's Encrypt rate limits are real and easy to hit if you're not careful
• Wildcard certificates are the right choice for dynamic subdomain environments
• Centralized certificate management is simpler than distributing certificates to individual VMs
• Traefik's DNS challenge support works well once you configure it correctly
• Always test certificate workflows in Let's Encrypt's staging environment first

If you're running a similar setup, don't wait until you hit rate limits. Switch to wildcard certificates early, and automate the renewal process from the start.