Skip to content

caddytls: load existing cert for subdomains when wildcard fails - #7929

Open
faiyaz032 wants to merge 2 commits into
caddyserver:masterfrom
faiyaz032:fix-wildcard-blocks-subdomain-certs-7365
Open

caddytls: load existing cert for subdomains when wildcard fails#7929
faiyaz032 wants to merge 2 commits into
caddyserver:masterfrom
faiyaz032:fix-wildcard-blocks-subdomain-certs-7365

Conversation

@faiyaz032

Copy link
Copy Markdown

When a wildcard like *.domain.com fails to obtain a certificate, subdomains covered by it can stop serving HTTPS even if they already have a certificate on disk.

Caddy currently skips these subdomains while the wildcard is being managed:

if t.managingWildcardFor(subj, subjects) {
    if _, ok := t.automateNames[subj]; !ok {
        continue
    }
}

There is an automate escape hatch for this, but it is not exposed through the Caddyfile. This change loads an existing certificate from storage before skipping the subdomain:

_, err := ap.magic.CacheManagedCertificate(t.ctx.Context, subj)

No new certificate is requested, so the existing wildcard optimization stays the same.

Testing

Added TestWildcardCoveredSubdomainKeepsExistingCert to verify an existing certificate is loaded when a covering wildcard fails.

Also ran:

go test ./modules/caddytls/...
go test ./modules/caddyhttp/...
go build ./...
go vet ./modules/caddytls/...

Reproduced the issue with Pebble and confirmed the existing certificate is served without another ACME request.

Fixes #7365

Assistance Disclosure

AI assistance was used to navigate the codebase and reproduce the issue with Pebble. The code and tests were reviewed and verified manually.

  Skipped subdomains covered by a pending wildcard now still load any
  cert they already have in disk, so they don't get ignored if the
  wildcard domain permanently fails

  Fixes caddyserver#7365

Signed-off-by: Faiyaz <faiyazrahman03@gmail.com>
Copilot AI lite review requested due to automatic review settings August 8, 2026 08:03
@CLAassistant

CLAassistant commented Aug 8, 2026

Copy link
Copy Markdown

CLA assistant check
All committers have signed the CLA.

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR improves TLS certificate management in the caddytls app by ensuring that wildcard-covered subdomains can still serve HTTPS using an already-existing certificate from storage, even while a covering wildcard certificate is being managed (and potentially failing).

Changes:

  • Load an existing managed certificate from storage for wildcard-covered subdomains before skipping individual management due to wildcard coverage.
  • Add a regression test to confirm the existing subdomain certificate is loaded into the in-memory cache in the wildcard-covered case.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File Description
modules/caddytls/tls.go Attempts to load an existing managed cert into cache for wildcard-covered subdomains before continuing.
modules/caddytls/tls_wildcard_test.go Adds a regression test covering “subdomain keeps serving with existing cert while wildcard is managed”.

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

Comment thread modules/caddytls/tls_wildcard_test.go Outdated
Comment on lines +151 to +154
if cached := certCache.AllMatchingCertificates(subdomain); len(cached) == 0 {
t.Errorf("expected existing certificate for %s to be loaded into the cache even though "+
"a covering wildcard (%s) is also being managed; see issue #7365", subdomain, wildcard)
}
Comment thread modules/caddytls/tls.go
// subdomains by adding the name to the 'automate' cert loader
if t.managingWildcardFor(subj, subjects) {
if _, ok := t.automateNames[subj]; !ok {
// not going to request a new cert for subj since a covering wildcard is being managed instead. But the wildcard may never succeed, so make sure we dont ignore a cert we already have in disk for that subj.
Follow up to Copilot's PR review: AllMatchingCertificates also
matches wildcard certs, so the test could pass without the fix
actually loading the subdomain's own cert. Check its SANs instead.

Signed-off-by: Faiyaz <faiyazrahman03@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Wildcard domain throttled block valid definitions

3 participants