Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CNAME issues with dns-01 #840

Open
tlhackque opened this issue Mar 16, 2024 · 0 comments · May be fixed by #841
Open

CNAME issues with dns-01 #840

tlhackque opened this issue Mar 16, 2024 · 0 comments · May be fixed by #841

Comments

@tlhackque
Copy link
Contributor

tlhackque commented Mar 16, 2024

The DNS code that tries to handle CNAME for dns-01 verification is confused and broken.

The problems include:

  • CNAMEs are not resolved if an AUTH_DNS_SERVER is defined.
  • The dns_add_* scripts always prefix the domain name with _acme-challenge.. The fulfill_challenges doesn't deal with this.
  • check_challenge_completion_dns` also is confused. It expects to get a RR, but doesn't account for the prefix. Further, it also tries to follow a possible CNAME chain. However, at that point, there should not be a CNAME.

CNAMEs are static - added in the domain being issued a certificate. The target of the CNAME is the record being added & verified. Once the CNAME has been resolved (to determine where to place the TXT record), verification has nothing to do with it.

The RFCs & LE allow for CNAMEs to point to an arbitrary record. However, getssl's API for the dns_add_* scripts doesn't support creating arbitrary records.

Rather than "fix" that, the solution is to restrict CNAMEs to what getssl can handle. Specifically:

The domain(s) being verified may contain CNAMEs for _acme-challenge.${domain_name}. They MUST point to a TXT record named _acme-challenge.${domain_name}.${any_dns_zone_that you_can_update}. They can not point to another CNAME.

Most examples that you'll find on the web are unclear, or downright misleading. Here is one that will work with getssl (after a PR to come): The PR adds some checks for misconfiguration.

Assume that you want to issue a certificate for www.example.com and example.com, whose DNS server is dns.example.net. You can't use dynamic updates to this server (but you can add CNAME records).

You have a DNS server that supports dynamic updates named dns.example.info and allows dynamic updates to dynamic.example.info.

On dns.example.net create two CNAMES:

_acme-challenge.example.com. CNAME _acme-challenge.example.com.dynamic.example.info.
and
_acme-challenge.www.example.com. CNAME _acme-challenge.www.example.com.dynamic.example.info.

You do NOT do anything to setup the targets of the CNAMEs in dynamic.example.info. (You do need dynamic update credentials.) Normally, the CNAMEs are dangling - the targets don't exist.

When getssl runs, it will create the TXT records in the dynamic.example.info domain, the issuer will verify them, and getssl will delete them as usual.

tlhackque added a commit to tlhackque/getssl that referenced this issue Mar 17, 2024
tlhackque added a commit to tlhackque/getssl that referenced this issue Mar 19, 2024
tlhackque added a commit to tlhackque/getssl that referenced this issue Apr 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
1 participant