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
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.
Add the main domain to the cert domains you want - so freeparking.co.nz for you (could be any subdomain as well I think)
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:
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.
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).
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
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.
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.
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.
