Certbot - Challenge Not Passing Due to IPV6 Configuration

Please fill out the fields below so we can help you better.

My domain is: si.cx

I ran this command:

/root/.local/share/letsencrypt/bin/certbot certonly --expand --non-interactive --keep-until-expiring --webroot
-w /home/www-data/si.cx/www/
-d si.cx
-d www.si.cx

It produced this output:

Saving debug log to /var/log/letsencrypt/letsencrypt.log
You are running with an old copy of letsencrypt-auto that does not receive updates, and is less reliable than more recent versions. We recommnd upgrading to the latest certbot-auto script, or using native OS packages.
Cert is due for renewal, auto-renewing…
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for si.cx
http-01 challenge for www.si.cx
Using the webroot path /home/www-data/si.cx/www for all unmatched domains.
Waiting for verification…
Cleaning up challenges
Failed authorization procedure. si.cx (http-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain:: Could not connect to si.cx


  • The following errors were reported by the server:

    Domain: si.cx
    Type: connection
    Detail: Could not connect to si.cx

    To fix these errors, please make sure that your domain name was
    entered correctly and the DNS A record(s) for that domain
    contain(s) the right IP address. Additionally, please check that
    your computer has a publicly routable IP address and that no
    firewalls are preventing the server from communicating with the
    client. If you’re using the webroot plugin, you should also verify
    that you are serving files from the webroot path you provided.

My web server is (include version): apache2.2.16

The operating system my web server runs on is (include version): Debian Squeeze

My hosting provider, if applicable, is:

I can login to a root shell on my machine (yes or no, or I don’t know): yes

I’m using a control panel to manage my site (no, or provide the name and version of the control panel): no

What is the reason, it cannot connect to si.cx? If i run the same command without domain si.cx, but only www.si.cx, it works normally:

/root/.local/share/letsencrypt/bin/certbot certonly --expand --non-interactive --keep-until-expiring --webroot
-w /home/www-data/si.cx/www/
-d www.si.cx

Hi @jerdna,

Take a look to this announcement https://community.letsencrypt.org/t/preferring-ipv6-for-challenge-validation-of-dual-homed-hosts/347741

As a resume, your domain has 2 ips, one for ipv4 and one for ipv6. You are answering on ipv4 address but not on ipv6 address. In this situation Let's Encrypt should fallback to ipv4.

$ curl -I4kL si.cx
HTTP/1.1 200 OK
Date: Thu, 25 May 2017 15:28:23 GMT
Server: Apache/2.2.16 (Debian) DAV/2 mod_ssl/2.2.16 OpenSSL/0.9.8o mod_fcgid/2.3.6
X-Powered-By: PHP/5.4.23
Vary: Accept-Encoding
Content-Type: text/html

$ curl -i6kL http://si.cx
curl: (7) Failed to connect to si.cx port 80: Connection timed out

@jsha, @cpu, one more buddy with this issue. In this case, no connection is possible to ipv6 address so it should fallback to ipv4, right?.

That is because www.si.cx doesn't have an AAAA record but si.cx does.

You should configure your server correctly to accept the ipv6 address of si.cx or remove the AAAA record from your DNS.


Thanks for flagging. This does seem like a case that I would have expected the fallback to occur. I’ll try to do a little more digging.

@jerdna Am I correct in assuming that the IPv6 address in your AAAA record routed to the machine correctly but there was no webserver bound to 80/443 on that interface/address?

1 Like

Hello sahsanu,

thank you for a fast response. I set webserver to accept ipv6 and now it

I don’t think its neccessary to fallback to ipv4. It would just be fine,
if certbot would tell me, that it tried to connect via ipv6 and failed.


1 Like

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