Caddy not generating one specific certificate on one server

[kwypchlo (Karol Wypchło)]

1. Caddy version (caddy version):

v2.4.3 h1:Y1FaV2N4WO3rBqxSYA8UZsZTQdN+PwcoOcAiZTM8C0I=

2. How I run Caddy:

caddy run --config /etc/caddy/caddy.json

a. System environment:

docker

b. Command:

Paste command here.

c. Service/unit/compose file:

Paste full file contents here.
Make sure backticks stay on their own lines,
and the post looks nice in the preview pane.

d. My complete Caddyfile or JSON config:

{
  "apps": {
    "tls": {
      "automation": {
        "policies": [
          {
            "subjects": [
                    "siasky.dev", "*.siasky.dev", "*.hns.siasky.dev"

                ,

                    "dev1.siasky.dev", "*.dev1.siasky.dev", "*.hns.dev1.siasky.dev"
            ],
            "issuers": [
              {
                "module": "acme",
                "challenges": {
                  "dns": {
                    "provider": {
                      "name": "route53",
                      "max_retries": 100
                    }
                  }
                }
              }
            ]
          }
        ]
      }
    }
  }
}

3. The problem I’m having:

Caddy is not generating dev1.siasky.dev certificate.

This is the certificates directory /data/caddy/certificates/acme-v02.api.letsencrypt.org-directory/

siasky.dev
wildcard_.dev1.siasky.dev
wildcard_.hns.dev1.siasky.dev
wildcard_.hns.siasky.dev
wildcard_.siasky.dev

Is there a way to force caddy to do a full recheck on the certificates?

Obviously I know that dev1.siasky.dev would be covered by *.siasky.dev certificate but I need to hardcode the certificate path in nginx since I’m using caddy only to manage certificates and those domains are based on environment variables so I don’t want to rely on using the existing wildcard certificate and want a separate one.

4. Error messages and/or full log output:

caddy              | {"level":"info","ts":1629547292.7039404,"msg":"using provided configuration","config_file":"/etc/caddy/caddy.json","config_adapter":""}
caddy              | {"level":"info","ts":1629547292.7050283,"logger":"admin","msg":"admin endpoint started","address":"tcp/localhost:2019","enforce_origin":false,"origins":["localhost:2019","[::1]:2019","127.0.0.1:2019"]}
caddy              | {"level":"info","ts":1629547292.705257,"logger":"tls.cache.maintenance","msg":"started background certificate maintenance","cache":"0xc00043bdc0"}
caddy              | {"level":"info","ts":1629547292.7054155,"logger":"tls","msg":"cleaning storage unit","description":"FileStorage:/data/caddy"}
caddy              | {"level":"info","ts":1629547292.7055345,"msg":"autosaved config (load with --resume flag)","file":"/config/caddy/autosave.json"}
caddy              | {"level":"info","ts":1629547292.7055426,"msg":"serving initial configuration"}
caddy              | {"level":"info","ts":1629547292.70762,"logger":"tls","msg":"finished cleaning storage units"}

5. What I already tried:

Restarting caddy didn’t help.

6. Links to relevant resources:

[matt (Matt Holt)]

Hmm, I think you might actually need a config more like this:

Using Caddy to keep certificates renewed

You can use Caddy as an automated certificate manager to keep certificates renewed without having to run an HTTPS server [1]. This way, the certificates can be used by other programs that need them. Caddy’s tls app can be configured without the need for an HTTP server. It can keep certificates renewed. Without additional configuration, assets (certificates, keys, and metadata) are stored in a data directory on the local file system at a location dependent upon your OS. The simplest form is to …

[kwypchlo (Karol Wypchło)]

Worked like a charm Thank you @matt !

I had the config setup this way because I just removed the http part from the regular config that I got by formatting Caddyfile to json format. I actually saw your article couple of weeks ago and I just wrongly assumed this was the way to do it and didn’t check thoroughly enough. The reason why I thought it’s just one certificate is that I had all the others already in place from running with http config. Anyway, thanks again.

[matt (Matt Holt)]

Awesome, glad to hear it! Thanks for describing your experience.