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

**URL:** <https://community.letsencrypt.org/t/solved-the-server-could-not-connect-to-the-client-for-dv-but-i-can-see-the-connection/6491>\
**Category:** Server\
**Created:** [December 9, 2015, 6:45pm UTC](https://community.letsencrypt.org/t/solved-the-server-could-not-connect-to-the-client-for-dv-but-i-can-see-the-connection/6491 "2015-12-09T18:45:08Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![jsgf](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/jsgf/32/3053_2.png) [@jsgf](https://community.letsencrypt.org/u/jsgf)\
**Post date:** [December 9, 2015, 6:45pm UTC](https://community.letsencrypt.org/t/solved-the-server-could-not-connect-to-the-client-for-dv-but-i-can-see-the-connection/6491/1 "2015-12-09T18:45:08Z")

</div>

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](http://pastebin.com/PFZffSY3)):

```auto
{
    "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

---

<div class="post-metadata">

**Author:** ![jhass](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/jhass/32/4717_2.png) [@jhass](https://community.letsencrypt.org/u/jhass)\
**Post date:** [December 9, 2015, 7:07pm UTC](https://community.letsencrypt.org/t/solved-the-server-could-not-connect-to-the-client-for-dv-but-i-can-see-the-connection/6491/2 "2015-12-09T19:07:56Z")

</div>

Actually failing the challenge when CAA fails was broken and [got fixed](https://github.com/letsencrypt/boulder/pull/1232) two days ago. It probably failed previously too.

---

<div class="post-metadata">

**Author:** ![jsgf](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/jsgf/32/3053_2.png) [@jsgf](https://community.letsencrypt.org/u/jsgf)\
**Post date:** [December 9, 2015, 7:09pm UTC](https://community.letsencrypt.org/t/solved-the-server-could-not-connect-to-the-client-for-dv-but-i-can-see-the-connection/6491/3 "2015-12-09T19:09:40Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![jhass](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/jhass/32/4717_2.png) [@jhass](https://community.letsencrypt.org/u/jhass)\
**Post date:** [December 9, 2015, 7:14pm UTC](https://community.letsencrypt.org/t/solved-the-server-could-not-connect-to-the-client-for-dv-but-i-can-see-the-connection/6491/4 "2015-12-09T19:14:50Z")

</div>

I’m not sure what your CAA record is supposed to do here, [RFC6844](https://tools.ietf.org/html/rfc6844) doesn’t define `auth` and only reserves it as a legacy value.

---

<div class="post-metadata">

**Author:** ![jsgf](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/jsgf/32/3053_2.png) [@jsgf](https://community.letsencrypt.org/u/jsgf)\
**Post date:** [December 9, 2015, 7:19pm UTC](https://community.letsencrypt.org/t/solved-the-server-could-not-connect-to-the-client-for-dv-but-i-can-see-the-connection/6491/5 "2015-12-09T19:19:54Z")

</div>

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