DNS challenge fails with different TXT records found in two trials

My domain is: pacificcape.com

I ran this command:

certbot certonly --manual --preferred-challenges dns
–work-dir $CBDIR/var/lib/letsencrypt --logs-dir $CBDIR/var/logs/letsencrypt --config-dir $CBDIR/etc/letsencrypt
–cert-name pacificcape.com -d pacificcape.com,www.pacificcape.com

It produced this output:

1st trial:

Domain: pacificcape.com
Type: unauthorized
Detail: Incorrect TXT record
“4XfJz1tz1Lk42rPZ7E_irl-wprIe8iRsrCkkEeavHMc” (and 1 more) found at

Domain: www.pacificcape.com
Type: unauthorized
Detail: No TXT record found at _acme-challenge.www.pacificcape.com

2nd trial:

Domain: pacificcape.com
Type: unauthorized
Detail: Incorrect TXT record
“YZ7OGAJKGDtU4e5MUYblLZaao4rbWhEJJRCWmb_11_w” (and 1 more) found at

Domain: www.pacificcape.com
Type: unauthorized
Detail: No TXT record found at _acme-challenge.www.pacificcape.com

My web server is (include version): Apache httpd 2.4.x

The operating system my web server runs on is (include version): Ubuntu 16.04

My hosting provider, if applicable, is: N/A

I can login to a root shell on my machine (yes or no, or I don’t know): Yes

I’m using a control panel to manage my site (no, or provide the name and version of the control panel): No


I’m having trouble generating certificate (certonly --manual --preferred-challenges dns) on Mac OSX for a domain using the command described in the “ran command” section above.

I tried it twice, both failed. My TXT records after the 2nd trial have the exact content what I was asked to set up:

$ dig pacificcape.com txt

;pacificcape.com. IN TXT

pacificcape.com. 3600 IN TXT “_acme-challenge.www.pacificcape.com=DoDrapE7nyqVKhXaE5dPLCpo8lxMnYgb8H1Dt_AtfOw”
pacificcape.com. 3600 IN TXT “_acme-challenge.pacificcape.com=9pEHb8sAtUwX2mKWmIFSE-3qEJJM0yDRQKIf7Dx7d4A”

The strange thing is that the TXT records certbot found in the two trials are different, as if they were randomly generated (see the above “produced output” section).

Any hep/advice would be greatly appreciated.

So it seems you've created two TXT records for pacificcape.com with the values _acme-challenge.www.pacificcape.com=DoDrapE7nyqVKhXaE5dPLCpo8lxMnYgb8H1Dt_AtfOw and _acme-challenge.pacificcape.com=9pEHb8sAtUwX2mKWmIFSE-3qEJJM0yDRQKIf7Dx7d4A.

Instead you should have created one record for _acme-challenge.www.pacificcape.com with the value DoDrapE7nyqVKhXaE5dPLCpo8lxMnYgb8H1Dt_AtfOw, and one for _acme-challenge.pacificcape.com with the value 9pEHb8sAtUwX2mKWmIFSE-3qEJJM0yDRQKIf7Dx7d4A.

The commands you want to run to test those are:

dig _acme-challenge.pacificcape.com txt
dig _acme-challenge.www.pacificcape.com txt

Yes, that's expected; they'll be different every time, including when your certificate is due to be renewed. This is why it's preferred to use a DNS API to update the records automatically, if possible.

1 Like

Thanks for the quick reply.

Re: Instead you should have created one record for _acme-challenge.www.pacificcape.com with the value DoDrapE7nyqVKhXaE5dPLCpo8lxMnYgb8H1Dt_AtfOw , and one for _acme-challenge.pacificcape.com with the value 9pEHb8sAtUwX2mKWmIFSE-3qEJJM0yDRQKIf7Dx7d4A .

Does it mean I have to first create subdomain _acme-challenge.pacificcape.com and nested subdomain _acme-challenge.www.pacificcape.com, then set up the value-only strings (rather than name=value) in the corresponding TXT records?

Re: DNS API, is there an open-source API tool you would recommend?

Thanks again.

The answer to both questions depends on your DNS service provider and what interfaces they make available to you. Usually there will be a place to put the name of the TXT record and a place to put the value. If there's a box where you put an @ symbol, put the name there instead. Here's an example:

(that's from Hover's documentation). In this case the interface provides a HOSTNAME box and a CONTENT box, so you would set the HOSTNAME to _acme-challenge or _acme-challenge.www and the CONTENT to just the value without the name.

Certbot has plugins to support a few DNS APIs, but they used to be difficult to install. They're a bit easier on 18.04 but I don't know what the situation is on 16.04 currently.

acme.sh is famous for supporting many different DNS providers' APIs.

If you can't find anything that supports your DNS provider, you can always switch to another provider. Or if you're feeling adventurous you can try acme-dns.

Interestingly you seem to already have a CNAME record for _acme-challenge.pacificcape.com pointing to pacificcape.com.letsencrypt.vdeck.eigdyn.com.. If you have control over this domain, you can create the TXT record there (or rather update, there seem to be a couple there already). If it has an API, you can use it - Let's Encrypt will happily follow the CNAME record for validation. You'll want to create another CNAME record for _acme-challenge.www.pacificcape.com if you want to go that route. If not, you'll want to remove the existing CNAME as you can't have both a TXT and a CNAME for the same name.


Appreciated the API suggestions.

The DNS tool for TXT records provided by my DNS provider (mydomain.com) only has a single text box for entries. Their tool for DKIM records does have two entry boxes: host and name, but I suppose that’s not applicable to TXT setup.

Hmm, in that case your best bet might be to move to a different DNS provider that provides a bit more functionality. Or if you have better control of another domain you can use the CNAME solution (use CNAME records to point the two _acme-challenge records at the other domain and create the TXT records there).

Might be worth sharing a screenshot of the UI anyway, just in case someone here can figure out how to make it work.

1 Like

Here’s a screenshot of the domain tool provided by my domain service (MyDomain) for TXT record setup …

Hmm. So what you tried is pretty much what I would have tried, given that interface, and since it didn’t work I’m not sure what else to suggest, other than what I suggested above.

@mikearou Do you really need the DNS challenge? I don’t see a wildcard certificate, so perhaps you can use the http-01 challenge? Or is port 80 closed?

Hi @mikearou

there is one certificate with a lot of domain names:

DNS-Name: eservicedirect.com
DNS-Name: eservicedirect.shopperspick.com
DNS-Name: ilovecaribbean.com
DNS-Name: ilovecaribbean.shopperspick.com
DNS-Name: mail.eservicedirect.com
DNS-Name: mail.ilovecaribbean.com
DNS-Name: mail.pacificcape.com
DNS-Name: mail.shoppingpointer.com
DNS-Name: pacificcape.com
DNS-Name: pacificcape.shopperspick.com
DNS-Name: shoppingpointer.com
DNS-Name: shoppingpointer.shopperspick.com
DNS-Name: www.eservicedirect.com
DNS-Name: www.eservicedirect.shopperspick.com
DNS-Name: www.ilovecaribbean.com
DNS-Name: www.ilovecaribbean.shopperspick.com
DNS-Name: www.pacificcape.com
DNS-Name: www.pacificcape.shopperspick.com
DNS-Name: www.shoppingpointer.com
DNS-Name: www.shoppingpointer.shopperspick.com

www + mail + non-www + a subdomain of shopperspick.com. Looks like you are able to create this certificate with a tool. This is often the best solution.

Just found out my web hosting provider already went ahead and generated all certs (using LetsEncrypt) for their customers. That explains why some conflicting TXT records already existed when I was going through the DNS challenge. They actually sent an email about it some months ago and I overlooked it. In essence, all the work I put in generating the certs was unnecessary. The remaining work would just be enforcing https redirect via some rewrite rules in .htaccess.

Thank you all for your help. Much appreciated!

1 Like

Yep, this is often the best solution. Then it's not required to install certbot per customer. And if your hoster uses a central dns-01 - validation, no file under /.well-known/acme-challenge/ is required.

PS: Your non-www domain has the redirect. Your www not.

D:\temp>download http://pacificcape.com/ -h
Connection: keep-alive
Content-Length: 301
Content-Type: text/html; charset=iso-8859-1
Date: Wed, 26 Sep 2018 18:30:51 GMT
Location: https://www.pacificcape.com/
Server: nginx/1.14.0

Status: 301 MovedPermanently

375,38 milliseconds
0,38 seconds

D:\temp>download http://www.pacificcape.com/ -h
Transfer-Encoding: chunked
Connection: keep-alive
Accept-Ranges: bytes
Content-Type: text/html
Date: Wed, 26 Sep 2018 18:30:59 GMT
Server: nginx/1.14.0

Status: 200 OK

379,90 milliseconds
0,38 seconds

If your hoster support SSL with renew, you may add the HSTS header:

Strict-Transport-Security: max-age=31536000; includeSubDomains

1 Like

Good catch! Thanks. I only modified .htaccess previously configured by someone (see below) by replacing http with https, thus the said problem:

RewriteCond %{HTTP_HOST} !^www.
RewriteRule ^(.*)$ http://www.%{HTTP_HOST}/$1 [R=301,L]

Have just replaced the rule with the following and redirection seems to work fine for both {domain} and www.{domain}:

RewriteCond %{SERVER_PORT} 80
RewriteRule ^(.*)$ https://www.pacificcape.com/$1 [R=301,L]

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.