Wildcard Failing dns-01 Acme Challenge


#1

Everytime I try to get my wildcard to work, it asks me to create a new TXT record called acme-challenge.mysubdomain.mydomain.co.nz with a random value

Then I get my manager to modify the TXT record to that, and click Request Certificate, straight away it will give me the same error and then ask me to create a new TXT record with a different random value

Do I need to wait one hour before clicking Request Certificate? Do you think the problem is that my TXT record has not updated yet?

It’s a manual process for us, I’ve asked my manager to change the TXT record about 5 times and I see that we are getting a bit frustrated by the process. Unfortunately our domain service (freeparking.co.nz) is not supported by Lets Encrypt and I don’t know enough details on how to write a custom script


#2

HI, I completely understand the frustration!

Sometimes the account ID and the private key don’t match due to a current bug in 4.x so there’s a chance that’s what you’re seeing. Go to Settings in the app and update your email address (you can set it to the same email again), this will internally update your Let’s Encrypt account ID and the account private key. This may resolve the issue for you but as a test you may just want to try a simpler HTTP validation for a single domain (like www.yourdomain.com) if you are running on a public facing server, just to be sure your account is working OK. Once you have a cert request completed you know that’s OK.

If you are requesting both a wildcard and a domain (e.g. *.mysubdomain.mydomain.co.nz AND ysubdomain.mydomain.co.nz) you will need to add to values to the single acme-challenge.mysubdomain.mydomain.co.nz TXT record) you may also find it easier to split it into 2 managed certificates, one for the wildcard and one for the domain host name (but you’ll still need 2 validations).

I’m currently looking at developing a method to help with the problem of unsupported DNS providers (currently we have to write a plugin for every DNS service, so the lesser known ones will never get one), involving CNAME redirection, so perhaps in the future we will be able to simplify this process for you.


#3

I had the same (or similar) issue with wildcards - see https://github.com/webprofusion/certify/issues/384 - but to save the link this is what worked for me - using your domain as an example:

  1. Add the main domain to the cert domains you want - so freeparking.co.nz for you (could be any subdomain as well I think)
  2. Add the wildcard domain as the second domain to include - so *.freeparking.co.nz
    Make sure the full domain in 1 above is marked as the primary
    So it should look a bit like:
    image

This then worked once TXT DNS dropped on to the top level domain- and I have renewed without having to change the DNS since too.


Authentication DNS - says TXT record is wrong, but matches with what it advised
Manual DNS method authorisation - failing
#4

Great that it’s working although you should expect your DNS validation to expire eventually (that’s up to Let’s Encrypt to decide). I don’t think the order should matter but what happens is one of the variations will validate and the other will may fail, in which case next time attempt the first one won’t need validation and the second one will, so generally if your not using multi-value TXT records you should still be able to do it in two requests (unless there is an account key problem).


#5

Thank you both - I’ll have a go


#6

Can you let me know when you have developed a method to help with the problem of unsupported DNS providers, or have fixed the bug in 4.x ?


#7

I ran into the same issue before. It’s because I’m using the DNS service of 3rd party, and the DNS records are not propagated yet. In my experience, it needs several hours for the values to be updated to the DNS servers. For wildcard domains, you need to add 2 TXT records with the same name(Ex: _acme-challenge.yourdomain.com) but different value specified, one for root domain(Ex: yourdomain.com), one for wildcard subdomains(Ex: *.yourdomain.com). Be aware there is a underline in the begining of TXT record.

Use nslookup tool to make sure the values are identical before clicking Request Certificate again:
nslookup.exe -q=TXT <Your TXT record name> <Your DNS server IP or Name>

For example:
nslookup.exe -q=TXT _acme-challenge.yourdomain.com ns1.yourdomain.com

It should display something like:

Server: <…>
Address: xxx.xxx.xxx.xxx

_acme-challenge.yourdomain.com text =

    "<Random string 1>"

_acme-challenge.yourdomain.com text =

    "<Random string 2>"

yourdomain.com nameserver = ns2.yourdomain.com
yourdomain.com nameserver = ns1.yourdomain.com

Retry above command until <Random string 1> and <Random string 2> are identical to what displayed on Certify The Web client, then you can click “Request Certificate” button again.


#8

A new release 4.0.11 is now available which fixes the Account Key bug which affected some users and caused valid challenge responses to fail.

Support for acme DNS (hosted CNAME redirection) is planned for the next major release, which could be a few weeks.


#9

I would also reiterate that if you are request a cert to cover both ‘domain.com’ and ‘*.domain.com’ you should split the into two managed certificates and complete one before attempting the next one, as it will be less confusing for manual DNS updates.


#11

LE never relies on propagation, it always looks up the domain’s nameservers and queries them directly. (Except when a domain has just been moved, obviously.) Unfortunately, some authoritative nameservers have stupidly long internal caching periods that are just as bad or worse than TTL caching times.


#12

Yeah, that’s probably my situation, and that’s why using nslookup to check first. :wink:


#13

Thank you - 4.0.11 has fixed the issue I had. I’m back up and running now. thanks!