Error when trying to make wildcard certificate using google-dns plugin

I am trying to make a wildcard certificate using the google-dns plugin, as the DNS is hosted on Google Cloud Platform.

$ sudo certbot certonly \
  --dns-google \
  --dns-google-credentials ~/.secrets/certbot/google.json \
  --dns-google-propagation-seconds 120 \
  -d *.mydomain.co.uk \
  -d mydomain.co.uk --dry-run

But I get this error:

Encountered error adding TXT record: <HttpError 412 when requesting https://dns.googleapis.com/dns/v1/projects/cloud-servers-214706/managedZones/430986XXXXXXXX4294/changes?alt=json returned "Precondition not met for 'entity.change.deletions[0]'">

I do not get an error when I replace the * with a hostname and the dry run completes successfully.

How do I make a wildcard certificate in this manner?

Thanks.

Is there anything in that zone that would conflict with the addition of the required TXT entry?

It really doesn’t help you to obscure your FQDN with:

Perhaps it would be easy to spot if it really was:
-d *.some.sub.domain.com
[which means you haven’t created the folders to put that TXT record into]

or a real and valid name that can easily be checked for DNS irregularities…

No, we are left to wonder and speculate.

FYI:

The validation for a wildcard doesn’t make an * entry in DNS.
The fact that a unique name passes checks means your DNS credentials are GOOD.
The mistake must be in a TXT record creation overlap/conflict.
But none of the DNS experts here can help you without a real name.

Please correct me if I am wrong… Should there not be 2 domain declarations?

  1. mydomain.com
  2. *.mydomain.com

Thought I’d ask.
Rip

1 Like

Is there anything in that zone that would conflict with the addition of the required TXT entry?

There are two TXT entries:

$ dig TXT mydomain.co.uk

; <<>> DiG 9.11.5-P4-5~bpo9+1-Debian <<>> TXT mydomain.co.uk
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13365
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;mydomain.co.uk.            IN      TXT

;; ANSWER SECTION:
mydomain.co.uk.     3528    IN      TXT     "v=spf1 include:spf.protection.outlook.com -all"
mydomain.co.uk.     3528    IN      TXT     "google-site-verification=BP7anV0rrauF-vePM0b5aR1KowpouC6XeEXEh3QrPEk"

;; Query time: 2 msec
;; SERVER: 169.254.169.254#53(169.254.169.254)
;; WHEN: Mon Jan 20 00:21:55 GMT 2020
;; MSG SIZE  rcvd: 187

But there have also been two entries in a TXT record in another zone I used successfully using the Cloudflare plugin, although that was not using a wildcard.

Why would anything being done be different when trying for a wildcard, when it works for a host address? Isn’t the TXT entry being added to the domain root TXT record in both cases?

Perhaps it would be easy to spot if it really was:
-d *.some.sub.domain.com
[which means you haven’t created the folders to put that TXT record into]

The wildcard domain is in the form of *.mydomain.co.uk. I can provide the domain if it helps any more than the information I have already given.

Thanks.

Yes, I have realised that and I have added that root domain (original post edited), but the same problem persists.

Thanks.

No.
The TXT record is “_acme-challenge.”+FQDN.
so XYZ.DOMAIN.CO.UK =
_acme-challenge.XYZ.DOMAIN.CO.UK
while *.DOMAIN.CO.UK =
_acme-challenge.DOMAIN.CO.UK

Neither of which that should conflict with the TXT for:
DOMAIN.CO.UK

…unless…
You actually have a TXT record for:
*.DOMAIN.CO.UK

FYI - your dig request won’t show all that is in a zone.
[a full zone transfer would]

try comparing the outputs of:
dig TXT mydomain.co.uk
dig TXT *.mydomain.co.uk

1 Like

Hi. I found the problem. I didn’t notice it before, as there are so many records in the zone, but there was already a TXT record for _acme-challenge.mydomain.co.uk, from an earlier time where I was using a certbot certificate without the dns plugin. Removing that TXT record has solved this issue.

Thanks for your help.

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