CAA record for googleusercontent.com prevents issuance

Issuance Tech
1

Hello everyone,

This is my first time using certbot and let's encrypt.

I am using Google Cloud and I've set up a zone. I believe that I have the CAA record set up correctly.

$ gcloud dns record-sets list --zone=rcorujo-dns-zone
NAME                                                                       TYPE   TTL    DATA
148.39.202.35.bc.googleusercontent.com.                                    A      3600   35.202.39.148
148.39.202.35.bc.googleusercontent.com.                                    CAA    300    0 issue "letsencrypt.org"
148.39.202.35.bc.googleusercontent.com.                                    NS     21600  ns-cloud-e1.googledomains.com.,ns-cloud-e2.googledomains.com.,ns-cloud-e3.googledomains.com.,ns-cloud-e4.googledomains.com.
148.39.202.35.bc.googleusercontent.com.                                    SOA    21600  ns-cloud-e1.googledomains.com. cloud-dns-hostmaster.google.com. 2 21600 3600 259200 300
_3eb7b6a635bd8a2b8ed0b6b1abf95445.148.39.202.35.bc.googleusercontent.com.  CNAME  3600   13351d9b44d101a51c4a573f26c9b85e.03b585f03363e525586104bb1846925b.80c5f569ea133b1.comodoca.com

I have my "/etc/resolv.conf" pointing first to the Google DNS server (216.239.32.110) for the zone I created.

root@nginx-deployment2-96bbdb955-qfffj:/tmp# cat /etc/resolv.conf
search default.svc.cluster.local svc.cluster.local cluster.local c.dai-dev-560.internal google.internal
nameserver 216.239.32.110
nameserver 8.8.8.8

The "dig" command shows that it can find the "CAA" record.

root@nginx-deployment2-96bbdb955-qfffj:/tmp# dig -t CAA 148.39.202.35.bc.googleusercontent.com

; <<>> DiG 9.18.24-1-Debian <<>> -t CAA 148.39.202.35.bc.googleusercontent.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46221

;; 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: 8529b1ca57a0a2270167985f6b7bc8592f30033de0151abd0592ffffeb (good)
;; QUESTION SECTION:

;148.39.202.35.bc.googleusercontent.com. IN CAA

;; ANSWER SECTION:
148.39.202.35.bc.googleusercontent.com. 300 IN CAA 0 issue "letsencrypt.org"

;; Query time: 10 msec
;; SERVER: 216.239.32.110#53(216.239.32.110) (UDP)
;; WHEN: Mon Feb 26 15:21:54 UTC 2024
;; MSG SIZE rcvd: 134

However, the "certbot" command fails complaining about the "CAA" record, even though I specified I want to use the "http" challenge.

root@nginx-deployment2-96bbdb955-qfffj:/tmp# certbot certonly --test-cert --webroot --preferred-challenges http --webroot-path /usr/share/nginx/html --domains '148.39.202.35.bc.googleusercontent.com'
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Requesting a certificate for 148.39.202.35.bc.googleusercontent.com

Certbot failed to authenticate some domains (authenticator: webroot). The Certificate Authority reported these problems:
  Domain: 148.39.202.35.bc.googleusercontent.com
  Type:   caa
  Detail: CAA record for googleusercontent.com prevents issuance

Hint: The Certificate Authority failed to download the temporary challenge files created by Certbot. Ensure that the listed domains serve their content from the provided --webroot-path/-w and that files created there can be downloaded from the internet.

Some challenges have failed.
Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details.

The "/var/log/letsencrypt/letsencrypt.log" shows "resolverAddrs", which seems to suggest that my DNS server is not being used at all.

{
  "identifier": {
    "type": "dns",
    "value": "148.39.202.35.bc.googleusercontent.com"
  },
  "status": "invalid",
  "expires": "2024-03-04T15:19:45Z",
  "challenges": [
    {
      "type": "http-01",
      "status": "invalid",
      "error": {
        "type": "urn:ietf:params:acme:error:caa",
        "detail": "CAA record for googleusercontent.com prevents issuance",
        "status": 403
      },
      "url": "https://acme-staging-v02.api.letsencrypt.org/acme/chall-v3/11377857603/6hMG4Q",
      "token": "Z4l7ORirWWCjWyb_S92Q0cUSN75Ccubj497PHfay3wc",
      "validationRecord": [
        {
          "url": "http://148.39.202.35.bc.googleusercontent.com/.well-known/acme-challenge/Z4l7ORirWWCjWyb_S92Q0cUSN75Ccubj497PHfay3wc",
          "hostname": "148.39.202.35.bc.googleusercontent.com",
          "port": "80",
          "addressesResolved": [
            "35.202.39.148"
          ],
          "addressUsed": "35.202.39.148",
          "resolverAddrs": [
            "A:10.0.32.83:29709",
            "AAAA:10.0.32.89:30750"
          ]
        }
      ],
      "validated": "2024-02-26T15:19:45Z"
    }
  ]
}

How can I get it to use my "216.239.32.110" DNS server?

Thank you.

2

This has been resolved. I used the Google Cloud instructions at https://cloud.google.com/certificate-manager/docs/public-ca-tutorial and specified the "http" challenge, then followed the instructions that were displayed. I got my certificate.

1 Like
3

With regard to your original CAA problem:

You think your DNS zone is operated by ns-cloud-e{1..4}.googledomains.com. while in reality, if you do a trace, your DNS zone is operated by ns{1..4}.google.com.. And those NS don't have a CAA RR on file for that hostname. Only the 0 issue "pki.goog" CAA RR exists for googleusercontent.com. which is looked for if no other CAA RRs can be found for the other DNS labels..

5 Likes
4

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