Too many CNAMEs when looking up CAA

Help
1

Hi,

today we are trying to generate a certificate for a subdomain like we already did for dozens of our domains…

We have our DNS set up like that… we have a master records called frontend.gcloud.schema31.it that contains 6 A records to our balancers, then we set up a CNAME from the domain we have to serve to the Load Balancers CNAME.

Like…

subdomain.schema31.it CNAME frontend.gcloud.schema31.it

frontend.gcloud.schema31.it A 123.123.123.123
frontend.gcloud.schema31.it A 123.123.123.124
frontend.gcloud.schema31.it A 123.123.123.125
frontend.gcloud.schema31.it A 123.123.123.126
frontend.gcloud.schema31.it A 123.123.123.127
frontend.gcloud.schema31.it A 123.123.123.128

Until today everything worked like a charm. Today we’re trying to issue a certificate for our jenkins instance called jenkins.schema31.it but we’re getting this error:

"The following errors were reported by the server:

Domain: jenkins.schema31.it
Type: connection
Detail: too many CNAMEs when looking up CAA

To fix these errors, please make sure that your domain name was entered correctly and the DNS A/AAAA record(s) for that domain contain(s) the right IP address."

But frankly I don’t really get what he’s talking about…

What am I missing?

2

P.S.:

as you probably understood we’re using DNS Authorization…

{
  "identifier": {
    "type": "dns",
    "value": "jenkins.schema31.it"
  },
  "status": "invalid",
  "expires": "2017-09-22T13:47:27Z",
  "challenges": [
    {
      "type": "http-01",
      "status": "pending",
      "uri": "https://acme-v01.api.letsencrypt.org/acme/challenge/Kiiqry1Vxx1d1Zo8HXuR_5svUvZtBS-Lwj3IY_Bxv1Q/1991359141",
      "token": "_lF1HEOxzu2mpoAliMjp02S7czXy6v1wIIGBTxd-soU"
    },
    {
      "type": "tls-sni-01",
      "status": "pending",
      "uri": "https://acme-v01.api.letsencrypt.org/acme/challenge/Kiiqry1Vxx1d1Zo8HXuR_5svUvZtBS-Lwj3IY_Bxv1Q/1991359142",
      "token": "KIGhnFEHBN8CUrlcRq4Ft-VJOsdCz99LKSUu-ELxvGw"
    },
    {
      "type": "dns-01",
      "status": "invalid",
      "error": {
        "type": "urn:acme:error:connection",
        "detail": "too many CNAMEs when looking up CAA",
        "status": 400
      },
      "uri": "https://acme-v01.api.letsencrypt.org/acme/challenge/Kiiqry1Vxx1d1Zo8HXuR_5svUvZtBS-Lwj3IY_Bxv1Q/1991359143",
      "token": "pvwRrjk5Zg2AivULdYvrvXI2fgAHEi3b7JNSs7S7fD8",
      "keyAuthorization": "pvwRrjk5Zg2AivULdYvrvXI2fgAHEi3b7JNSs7S7fD8.L2qX8uon4A-9qbpWgwSNgLJIVUGMuQqdLIy0trBtUxQ",
      "validationRecord": [
        {
          "hostname": "jenkins.schema31.it",
          "port": "",
          "addressesResolved": [],
          "addressUsed": "",
          "addressesTried": []
                                                                                                                                                                                                                    225,1         79%
          "addressUsed": "",
          "addressesTried": []
        }
      ]
    }
  ],
  "combinations": [
    [
      1
    ],
    [
      2
    ],
    [
      0
    ]
  ]
}
3

Hi @skeyby,

We recently had to adjust our CAA checking implementation to handle CNAMEs differently. As part of that we added a threshold for the maximum number of CNAME dereferences we would follow. Another user opened a Boulder bug about this limit being too low.

It does seem like in your case the limit is being reached without successive CNAMEs and I suspect there may be a bug in the implementation. I recommend you follow Issue #3093 while we get to the bottom of the problem.

Update: This was not a bug, the user had a CAA CNAME loop as described in Legacy CAA Implementation

4

I stand corrected: @jsha points out this actually is a loop:

If you tree-climb on frontend.gcloud.schema31.it., you get gcloud.schema31.it. That's a CNAME to frontend.gcloud.schema31.it., so you tree-climb on the CNAME target, which sends you back to gcloud.schema31.it, etc.

5

I’m having the same issue. My domain has only 1 CNAME redirect till it reaches an A record (nayarweb.com)

6

@Nayar Please see Legacy CAA Implementation

You have a loop per the CAA RFC:
nayarweb.com is CNAME’d to haproxy.nayarweb.com. Which when climbed will result in a lookup for nayarweb.com's CAA record, which results in a CNAME to haproxy.nayarweb.com and so on.

7

I redid my DNS. Works now. Kinda liked it the old way though

8

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