Caddy attempts to manage SSL certificate when `auto_https` is set to `disable_certs`

[drakon64]

I have the following Caddyfile:

{
  admin unix//var/run/caddy/caddy-admin.sock

  auto_https disable_certs

  servers {
    metrics
  }
}

:2019 {
  metrics
}

subdomain.example1.com *.example2.com :443 {
  root * /opt/app/public
  php_fastcgi unix//var/run/php-fpm/default.sock
  file_server

  tls /etc/pki/tls/certs/example1.crt /etc/pki/tls/private/example1.key {
    ciphers TLS_AES_256_GCM_SHA384 TLS_AES_128_GCM_SHA256 TLS_CHACHA20_POLY1305_SHA256 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
  }

  tls /etc/pki/tls/certs/example2.crt /etc/pki/tls/private/example2.key {
    ciphers TLS_AES_256_GCM_SHA384 TLS_AES_128_GCM_SHA256 TLS_CHACHA20_POLY1305_SHA256 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
  }

  encode zstd gzip
}

The two tls blocks provide an SSL certificate for subdomain.example1.com and *.example2.com.

Despite SSL certificates already being provided and auto_https being set to disable_certs, Caddy still attempts to provide replacement SSL certificates via ACME. Setting auto_https to off resolves this but disables other functionality we require.

Is this a bug or is something wrong in our config?

[francislavoie]

You can't specify tls twice in the Caddyfile, only the last one will take effect.

What SANs do your certificates have?

[drakon64]

You can't specify tls twice in the Caddyfile, only the last one will take effect.

Would specifying separate server blocks for each hostname work in this instance?

What SANs do your certificates have?

I know for a fact that the subdomain.example1.com certificate is just for subdomain.example1.com and not a SAN, will look into *.example2.com.

[francislavoie]

Would specifying separate server blocks for each hostname work in this instance?

Possibly, but I don't have a good sense of your goal.

I know for a fact that the subdomain.example1.com certificate is just for subdomain.example1.com and not a SAN, will look into *.example2.com.

In that case, probably yes, you should separate them so it loads both certificates.

FWIW, this is only a Caddyfile limitation currently, you could load both explicitly in a JSON config. The overwhelming majority of Caddy users let Caddy issue its own certs and don't provide their own, so this is usually not an issue.

[drakon64]

After creating separate server blocks for each hostname and removing the :443 server, Caddy stopped trying to manage certificates itself.

It still seems weird to me that in this case Caddy effectively ignores auto_https disable_certs, but the immediate issue is resolved.

[francislavoie]

Yeah, the Automatic HTTPS logic is extremely complex, reasoning about it and fixing bugs in it is very hard. I'm not surprised there's edgecases like this we haven't found yet. I agree it's a bug.

[drakon64]

Possibly, but I don't have a good sense of your goal.

The web server has to provide the same service across two different hostnames using different domain names.

The overwhelming majority of Caddy users let Caddy issue its own certs and don't provide their own, so this is usually not an issue.

Unfortunately we can't use HTTP-01 for ACME and DNS-01 isn't an option with Caddy due to our DNS provider not being supported.

[francislavoie]

and DNS-01 isn't an option with Caddy due to our DNS provider not being supported.

There are ways around that. You could use https://github.com/joohoi/acme-dns instead (along with https://github.com/caddy-dns/acmedns), or you could do ACME challenge delegation with something like DuckDNS: https://github.com/caddy-dns/duckdns?tab=readme-ov-file#challenge-delegation, or with any other DNS provider with the dns_challenge_override_domain option

[drakon64]

Unfortunately it seemed that the solution just caused bigger issues. Removing the :443 block caused the load balancer health checks to fail because it's incapable of sending a Host header and then the site went down. Adding :443 to one of the existing hostname blocks then causes the original issue to re-occur.

Seems like I'm going to have to disable Auto HTTPS entirely because of this load balancer issue.

[mholt]

@drakon64 I was able to find that by running caddy adapt on your config, the automate loader was populated with your domain names, but probably shouldn't have been. It turns out there's a simple condition where we check for auto_https off and skip filling in those names, but not auto_https disable_certs. I've just added that condition and I think it should work for you now (no longer see any automate loader). Let me know if it doesn't!