Caddy keep trying to create SSLs of existing domains that already have SSL

1. Caddy version (caddy version):

v2.4.3

2. How I run Caddy:

  1. We have 5 servers running behind an AWS network load balancer.
  2. They share the same storage using AWS EFS.
  3. Every server has the same Caddyfile but he doesn’t locate it in the shared storage (EFS). Just in the local storage of the server.

a. System environment:

Ubuntu 20.04.2 LTS (GNU/Linux 5.8.0-1041-aws x86_64)
Simple install without Docker

b. Command:

Auto Caddy services are running in the background

d. My complete Caddyfile or JSON config:

    {
        #debug
        storage file_system {
                root /mnt/efs/caddy_data
        }
        log HHHH {
            output file /var/caddy_log/requests.log {
                roll_size 200mb
                roll_keep 3
                roll_keep_for 24h
            }
            level WARN
        }

        # TLS Options
        email HHHH @ HHHH .com
        on_demand_tls {
                ask      https://www. HHHH .com/isDomainValid.php
        }
    }

    https://

    tls {
        on_demand
        issuer acme {
                email HHHH @ HHHH .com
        }
        issuer zerossl HHHH {
                email HHHH @ HHHH .com
        }
    }

    reverse_proxy 76.223. HHHH . HHHH {
        header_down -proxy-cache
    }

3. The problem I’m having:

From the logs, I can see that Caddy try to bring SSL for domains that get SSL weeks ago. It looks like you can find them in the EFS and then try to request them from the ACME providers. Without success (anyway, Letsencrypt block us all the time because of that).
Example 1 (this domain already have an SSL and is working and don’t need to renew):

Feb 06 14:13:47 ip-172-30-0-105 caddy[478]: {"level":"info","ts":1644156827.5849168,"logger":"tls.issuance.acme","msg":"done waiting on internal rate limiter","identifiers":["userdomain . com"],"ca":"https://acme-v02.api.letsencrypt.org/directory","account":"noam @ myaccount .com"}
Feb 06 14:13:47 ip-172-30-0-105 caddy[478]: {"level":"error","ts":1644156827.8435564,"logger":"tls.obtain","msg":"could not get certificate from issuer","identifier":"userdomain . com","issuer":"acme-v02.api.letsencrypt.org-directory","error":"HTTP 429 urn:ietf:params:acme:error:rateLimited - Error creating new order :: too many new orders recently: see https://letsencrypt.org/docs/rate-limits/"}
Feb 06 14:13:47 ip-172-30-0-105 caddy[478]: {"level":"info","ts":1644156827.8480592,"logger":"tls.issuance.acme","msg":"waiting on internal rate limiter","identifiers":["userdomain . com"],"ca":"https://acme.zerossl.com/v2/DV90","account":"noam @ myaccount .com"}
Feb 06 14:13:47 ip-172-30-0-105 caddy[478]: {"level":"info","ts":1644156827.8862772,"logger":"tls.issuance.acme","msg":"done waiting on internal rate limiter","identifiers":["userdomain . com"],"ca":"https://acme.zerossl.com/v2/DV90","account":"noam @ myaccount .com"}

Example 2 (this domain already have an SSL and is working and don’t need to renew):

Feb 06 14:13:47 ip-172-30-0-105 caddy[478]: {"level":"info","ts":1644156827.3583622,"logger":"tls.issuance.acme","msg":"done waiting on internal rate limiter","identifiers":["userdomain . com"],"ca":"https://acme-v02.api.letsencrypt.org/directory","account":"noam @ myaccount .com"}
Feb 06 14:13:47 ip-172-30-0-105 caddy[478]: {"level":"error","ts":1644156827.5857646,"logger":"tls.obtain","msg":"could not get certificate from issuer","identifier":"userdomain . com","issuer":"acme-v02.api.letsencrypt.org-directory","error":"HTTP 429 urn:ietf:params:acme:error:rateLimited - Error creating new order :: too many new orders recently: see https://letsencrypt.org/docs/rate-limits/"}
Feb 06 14:13:47 ip-172-30-0-105 caddy[478]: {"level":"info","ts":1644156827.5882902,"logger":"tls.issuance.acme","msg":"waiting on internal rate limiter","identifiers":["userdomain . com"],"ca":"https://acme.zerossl.com/v2/DV90","account":"noam @ myaccount .com"}
Feb 06 14:13:47 ip-172-30-0-105 caddy[478]: {"level":"info","ts":1644156827.6695735,"logger":"tls.issuance.acme","msg":"done waiting on internal rate limiter","identifiers":["userdomain . com"],"ca":"https://acme.zerossl.com/v2/DV90","account":"noam @ myaccount .com"}

Thanks

More details that maybe can give more details.
In my Caddyfile I changed the storage with:

        storage file_system {
                root /mnt/efs/caddy_data
        }

But when I type “caddy environ” this is what I’m getting for the folder:

caddy.HomeDir=/home/ubuntu

caddy.AppDataDir=/home/ubuntu/.local/share/caddy

caddy.AppConfigDir=/home/ubuntu/.config/caddy

caddy.ConfigAutosavePath=/home/ubuntu/.config/caddy/autosave.json

I must say that sometimes SSL is generate and it’s working good but most of the time he just try to give SSL to domains that already have SSL in the SSL folder.

Of course, in my system this folder: /home/ubuntu/.local/share/caddy not exist.

That shows the environment of your current user, but Caddy runs as a different user. Don’t run that to see the environment Caddy will eventually have, when Caddy is running as a service.

The systemd service file uses the --environ flag to run with. Check Caddy’s logs right before it starts up, you’ll see its environment there in the logs.

I don’t really see anything wrong in what you showed. It makes no sense that Caddy would continually renew the same certificates. Are you watching the file modification time of those certificates? Are they constantly being updated?

1 Like

No change on the folder.
Now I took another look at my logs and it looks like all the requests are to domains without “www.”, but all those domains are pointing to our servers only with “www.”.
So why is Caddy trying to get SSL for those domains?! that way the validation fails all the time for them, and also I’m over the rate limit of Letsencrypt.

Does it need to work like that?

I found the issue, my ASK sends 200 responses also for domains without WWW.
Those domains are not pointing to my Caddy servers but I believe the ACME try them with the CADDY IP I send him.
It’s also the issue that gets me to the rate limit all the time.

Thanks for the help.

1 Like

Hmm… someone must have tried to hit your server with those domains though, because Caddy wouldn’t attempt to issue certificates for them unless it sees that domain in the TLS handshake.

Glad you found the issue though.

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