getssl icon indicating copy to clipboard operation
getssl copied to clipboard

Fix check failure when there is a wild card CNAME record

Open alhashash opened this issue 3 years ago • 5 comments

If there is a wildcard CNAME record "*.domain.com", resolving _acme-challenge.domain.com would yield another domain. Getssl incorrectly updates the check domain with the resolved domain which causes check failure!

Let's Encrypt validation does not follow CNAME of the challenge domain and Getssl should not too.

alhashash avatar Jun 21 '21 12:06 alhashash

Hi @alhashash

This breaks the automated tests for CNAME domains - can you give an example of the bug you're trying to fix?

Thanks

timkimber avatar Jul 20 '21 10:07 timkimber

My use case is:

  1. Create a CNAME record *.mydomain.com that points to server1.mydomain.com.
  2. Try to create a certificate for *.mydomain.com.

This fails because getssl resolves _acme-challenge.domain.com which points to server1.mydomain.com. Then, it tries to check the challenge at server1.mydomain.com TXT record!

Let's Encrypt challenge TXT record is always _acme-challenge.domain.com and it does not follow the CNAME record of that domain.

alhashash avatar Jul 25 '21 16:07 alhashash

@alhashash thanks for your reply

How are you creating a CNAME for *.mydomain.com?

I'd like to create a similar CNAME so I can reproduce the problem and fix it without breaking the existing tests.

The problem is that none of the DNS servers I have access to allow me to create a CNAME containing a star, I think because rfc1035 states that the only valid characters in a domain name are letters (A-Za-z), digits (0-9), and hyphens (see page 8 of https://datatracker.ietf.org/doc/html/rfc1035)

timkimber avatar Jul 27 '21 21:07 timkimber

@timkimber I'm using GoDaddy DNS service but I think most DNS servers support wildcard domains including online services like Amazon Route 53.

In bind, you have to use the full domain *.domain.com. not just *.

rfc1035 valid domain name specifications do not apply to * as it is not a domain name and cannot be queried, it is just a convention to configure wildcard domain resolution in DNS records.

alhashash avatar Jul 30 '21 19:07 alhashash

Hi @alhashash

You're right and I'm wrong. Thanks for correcting me, rfc4592 updated rfc1035 to confirm that wildcard dns entries are valid.

I couldn't find anything when searching the web, but have now, and my hosting provider (Namecheap) has a special interface I need to use to create wildcard cname's, it can't be done using the normal interface.

I'm making some test cleanup at the moment, once that's done I'll look at why the tests are changing after your change.

timkimber avatar Jul 30 '21 20:07 timkimber