Maybe it is I that is not hearing/reading well...
Let me rerereview the topic more thoroughly/completely.
3 Likes
The certbot request may seem similar:
But the domains covered are not that similar.
One single FQDN [ONLY]:
One FQDN and a WILDCARD:
The requests are different.
The results are different.
Try obtaining a new wildcard cert with those credentials.
3 Likes
I do not know how Google DNS is working. However, it looks like it is providing multi-level wildcard support:
tumbleweed:~ # dig CNAME abcd123.xyz987.spend.cloud @216.239.38.107
; <<>> DiG 9.18.25 <<>> CNAME abcd123.xyz987.spend.cloud @216.239.38.107
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5832
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
; COOKIE: 441ef0bb6ce2810d011dc0242c56ab982639f1aa575feedb9b23b52f9c (good)
;; QUESTION SECTION:
;abcd123.xyz987.spend.cloud. IN CNAME
;; ANSWER SECTION:
abcd123.xyz987.spend.cloud. 86400 IN CNAME spend.cloud.
;; Query time: 29 msec
;; SERVER: 216.239.38.107#53(216.239.38.107) (UDP)
;; WHEN: Fri May 10 11:36:27 UTC 2024
;; MSG SIZE rcvd: 102
tumbleweed:~ #
But that does not really relate to the original problem.
1 Like
That is not necessarily credential error. It could be some DNS related error as well. (For example, you cannot have more than one CNAME record for the same domain name, CNAME is singleton.)
Do you have some special Google DNS feature switched on? For example DDoS protection?
What is the content of the zone file? Is there any record that contains the string _acme-challenge in its name?
2 Likes
I understand the difference of course. Obtaining a new certificate is what I'm also thinking of since there is no explanation about why renewal for old certificates are not working as expected. Thanks for your suggestion anyways!
1 Like
I appreciate the points you've added. I have confirmed that it’s not related to any DNS errors since Google has a DNS record set for spend.cloud, and all records are added under this record set. Indeed, it’s not possible to have more than one CNAME record for the same domain.
DDOS protection being enabled or not really isn’t relevant here, as far as I can see. If that were an issue, the certbot should also have failed when I requested a test certificate for certtest.accept.spend.cloud.
There is no DNS record containing _acme-challenge because, as I have already explained in another reply, the _acme-challenge DNS record is automatically added and removed after verification. I'm not maintaining it manually.
What surprises me that sometimes you get a certificate. In fact, you should never get any certificate with DNS-01 authorization, since you always have a CNAME record in the following format:
_acme-challenge.<whatever_here>.spend.cloud.
A TXT type record cannot coexist alongside a CNAME record. So the Google DNS plugin gives an error, as it supposed to give.
2 Likes
I already replied this.
It appears that the certificate renewal API call is being cached and failing, particularly after the recent certbot changes for domain verification. Although I was able to obtain a certificate for *.accept.spend.cloud , attempts to expand the certificate to include accept.spend.cloud trigger the renewal process for the already existing certificate, resulting in 403 errors. I am considering opting for a wildcard certificate and allowing the existing certificate to expire. Afterward, I may attempt to expand it to include the non-wildcard domain.
Looking it from the Internet, seemingly there is domain name containing _acme-challenge:
localhost:~ # dig TXT _acme-challenge.accept.spend.cloud @216.239.32.107
; <<>> DiG 9.18.25 <<>> TXT _acme-challenge.accept.spend.cloud @216.239.32.107
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41906
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
; COOKIE: bb8ca7ec8f05749e011dc0242cb9ecdbfef6fc85551e160402251d4fb3 (good)
;; QUESTION SECTION:
;_acme-challenge.accept.spend.cloud. IN TXT
;; ANSWER SECTION:
_acme-challenge.accept.spend.cloud. 86400 IN CNAME accept.spend.cloud.
accept.spend.cloud. 86400 IN TXT "v=spf1 ip4:34.90.126.36 ~all"
;; Query time: 23 msec
;; SERVER: 216.239.32.107#53(216.239.32.107) (UDP)
;; WHEN: Mon May 13 14:14:01 UTC 2024
;; MSG SIZE rcvd: 151
localhost:~ #
The Google DNS plugin might follow the CNAME chain to check what domain to update to accomplish the authorization. But I am guessing here.
3 Likes
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.