caddytls: load existing cert for subdomains when wildcard fails - #7929
Open
faiyaz032 wants to merge 2 commits into
Open
caddytls: load existing cert for subdomains when wildcard fails#7929faiyaz032 wants to merge 2 commits into
faiyaz032 wants to merge 2 commits into
Conversation
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>
Contributor
There was a problem hiding this comment.
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 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) | ||
| } |
| // 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>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
When a wildcard like
*.domain.comfails 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:
There is an
automateescape hatch for this, but it is not exposed through the Caddyfile. This change loads an existing certificate from storage before skipping the subdomain:No new certificate is requested, so the existing wildcard optimization stays the same.
Testing
Added
TestWildcardCoveredSubdomainKeepsExistingCertto verify an existing certificate is loaded when a covering wildcard fails.Also ran:
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.