Verification fails, website is accessible via http

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g., so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is:

I ran this command: sudo certbot --apache --staging

It produced this output:

My web server is (include version):

thwee@rain:/var/www/html$ sudo certbot --apache --staging
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator apache, Installer apache

Which names would you like to activate HTTPS for?


Select the appropriate numbers separated by commas and/or spaces, or leave input
blank to select all options shown (Enter ‘c’ to cancel): 1
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for
Enabled Apache rewrite module
Waiting for verification…
Cleaning up challenges
Failed authorization procedure. (http-01): urn:ietf:params:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching Timeout during connect (likely firewall problem)


  • The following errors were reported by the server:

    Type: connection
    Detail: Fetching
    Timeout during connect (likely firewall problem)

    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. 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.

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

Windows 10, Windows Subsystem for Linux, Debian Stretch

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

Hi @thwee

checking your domain (via - Make your website better - DNS, redirects, mixed content, certificates ), there are some errors:

Host T IP-Address is auth. ∑ Queries ∑ Timeout A yes 1 0
AAAA 2600:8801:3A00:C100:F9F5:13AA:0B50:BC75 yes Name Error yes 1 0

Is your ipv6 - address configured?

Domainname Http-Status redirect Sec. G -14 10.050 T
Timeout - The operation has timed out -14 10.026 T
Timeout - The operation has timed out -4 0.707 W
SendFailure - The underlying connection was closed: An unexpected error occurred on a send. The handshake failed due to an unexpected packet format. 307 2.266 Q -14 10.027 T
Timeout - The operation has timed out

Your site has a timeout using http / port 80. But your port 443 - oh, answers with http, not with https.

Sending a https query produces a typical error message ("The handshake failed due to an unexpected packet format"), so http over port 443 is checked. And there is a "normal http status 200".

But must important:

has a timeout.

Is there a Windows firewall? Or a Linux-firewall?

IPv6 address does not respond to HTTP.
[LE prefers IPv6 over IPv4]

1 Like

I thought I had configured ipv6. Thanks, I’ll look this over when I get home again.

These are the settings I’m using:

Could someone tell me if I’m missing any records?

Is there a Windows firewall? Or a Linux-firewall?

No, I turned off Windows Firewall, and ufw is not installed on debian.

I also have the router set up to forward ports 80 and 443 to the server.

IPv6 isn’t the issue. Since some time, Let’s Encrypt implements a form of Happy Eyeballs that is tolerant of IPv6 addresses not working.

I think in your case @thwee, it’s a case of Cox just blocking inbound port 80 -

This is supported by port 443 being accessible on your IPv4 address, whereas 80 is not.

We know that Let’s Encrypt can connect on port 443 successfully, by doing a test via TLS-ALPN: (but your server is talking “HTTP” over its “HTTPS” port).

So you have a problem that you cannot use HTTP validation with your domain, because Cox blocks the only port that supports HTTP validation.

Hmm, that’s unfortunate. I’m a software engineer, but a network newbie, can you tell me whether there’s another way of installing the SSL certificate? Can I try DNS validation instead?

Google Domains doesn’t offer an API to enable automated TXT record updates, which is what would be required for DNS validation.

You could change your domain’s DNS hosting to somewhere else that supports both DDNS and also API updates. One example is Cloudflare, but it’s far from the only choice.

You can do this for free - you don’t need to transfer your domain, just to use different nameservers.

If you did choose to do this, with the Cloudflare example, then you’d just install the Certbot Cloudflare plugin and issue your certificate according to the instructions.

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