[SOLVED] "The server could not connect to the client for DV" - but I can see the connection

Server
1

I’m trying to get certs for my domains using --webroot. It fails with “Error: The server could not connect to the client for DV”, but I can see the acme server connecting and fetching the files in my logs.

# /root/.local/share/letsencrypt/bin/letsencrypt certonly --help --renew-by-default --text -vv --webroot -w /var/www/html/ -d goop.org -d www.goop.org -d mail.goop.org

A pretty-printed response is (raw in http://pastebin.com/PFZffSY3):

{
    "challenges": [
        {
            "status": "pending",
            "token": "e0euKOFtdUpE-5CeYmt6ExcX4SDBXxujXAeQ7A5bGNU",
            "type": "tls-sni-01",
            "uri": "https://acme-v01.api.letsencrypt.org/acme/challenge/MRZlrdJ9YEsZMk_QcJyw17gp2J3AWHiTHbMOAaYrlNI/1437581"
        },
        {
            "error": {
                "detail": "CAA check for identifier failed",
                "type": "urn:acme:error:connection"
            },
            "keyAuthorization": "o8jJFO3ddmdnZEuBoXv-twa_4fuuIxYaZ955fcVZJzU.jw4YMWqKieWwi-niTMzgb6YwDkUaQMsvb23WJcvqaQs",
            "status": "invalid",
            "token": "o8jJFO3ddmdnZEuBoXv-twa_4fuuIxYaZ955fcVZJzU",
            "type": "http-01",
            "uri": "https://acme-v01.api.letsencrypt.org/acme/challenge/MRZlrdJ9YEsZMk_QcJyw17gp2J3AWHiTHbMOAaYrlNI/1437582",
            "validationRecord": [
                {
                    "addressUsed": "74.207.240.146",
                    "addressesResolved": [
                        "74.207.240.146"
                    ],
                    "hostname": "mail.goop.org",
                    "port": "80",
                    "url": "http://mail.goop.org/.well-known/acme-challenge/o8jJFO3ddmdnZEuBoXv-twa_4fuuIxYaZ955fcVZJzU"
                }
            ]
        }
    ],
    "combinations": [
        [ 1 ],
        [ 0 ]
    ],
    "expires": "2015-12-16T18:15:45Z",
    "identifier": {
        "type": "dns",
        "value": "mail.goop.org"
    },
    "status": "invalid"
}

However, I can see in my apache logs that it managed to successfully get the files:

66.133.109.36 - - [09/Dec/2015:10:15:45 -0800] "GET /.well-known/acme-challenge/gr0iOezBqgEQKTA9hxWbBa5klpu8I-l0aDysX-7dY5U HTTP/1.1" 200 87 "-" "Mozilla/5.0 (compatible; Let's Encrypt validation server; +https://www.letsencrypt.org)"
66.133.109.36 - - [09/Dec/2015:10:15:45 -0800] "GET /.well-known/acme-challenge/o8jJFO3ddmdnZEuBoXv-twa_4fuuIxYaZ955fcVZJzU HTTP/1.1" 200 87 "-" "Mozilla/5.0 (compatible; Let's Encrypt validation server; +https://www.letsencrypt.org)"
66.133.109.36 - - [09/Dec/2015:10:15:46 -0800] "GET /.well-known/acme-challenge/zk8SExw7N2cqt989FXv-g-36QvTz0d80dZxquzFjxDQ HTTP/1.1" 200 87 "-" "Mozilla/5.0 (compatible; Let's Encrypt validation server; +https://www.letsencrypt.org)"

So it doesn’t seem to be any kind of DNS issue. All of those domains resolve to the same server namespace. I had successfully got certs for these domains last week, but they were revoked over the weekend. Is there something else wrong with my setup, or has the CAA DV checking become overly strict? Could it be something like a mime-type issue?

Thanks, J

2

Actually failing the challenge when CAA fails was broken and got fixed two days ago. It probably failed previously too.

1 Like
3

OK, fair enough. Any clues about what I can fix?

I can successfully get certs for another vhost served from the same apache instance, so I’m not sure what’s going wrong with these domains.

4

I’m not sure what your CAA record is supposed to do here, RFC6844 doesn’t define auth and only reserves it as a legacy value.

5

Oh, that. I hadn’t connected the term “CAA” with the DNS record. I’ll drop it; I think it was an experiment in implementing DNSSEC.

[…]
(It’s just TYPE257 in the named db)
[…]

Yep! That fixed it. Thanks.

J