Failed authorization procedure. my.domain.org (tls-sni-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Timeout

Help
1

Hello

I have problems renewing my certificate. I remember having lots of problem creating it the first time as well.

My webserver which uses the certificate (Home Assistant) is not on a standard port but I have made Apache available just for the sake of renewing the cert. Also tried standalone mode without Apache. For some unknown reason, certbot fails with connection timeout.

If I try to connect from an external server that I have access to, it connects fine to both port 80 and 443. Also if I try it with some random web service I found (http://www.t1shopper.com/tools/port-scan/).

Note! The firewall rules to allow 80 and 443 were only enabled when I did the certbot-auto-attempts, I deleted these two rules again afterwards.

My run with Apache option:

https://paste.ubuntu.com/26545363/

My run with standalone option:

https://paste.ubuntu.com/26545369/

http://www.t1shopper.com/tools/port-scan/result/

Scanning ports on my.domain.org
my.domain.org is responding on port 80 (http).

my.domain.org is responding on port 443 (https).

Scan with curl from external server:

$ curl -I my.domain.org:80
HTTP/1.1 200 OK
Date: Fri, 09 Feb 2018 07:53:29 GMT
Server: Apache/2.4.18 (Ubuntu)
Link: http://my.domain.local/index.php?rest_route=/; rel="https://api.w.org/"
Link: http://my.domain.local/; rel=shortlink
Content-Type: text/html; charset=UTF-8

$ curl -I https://my.domain.org:443
curl: (60) server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none
More details here: http://curl.haxx.se/docs/sslcerts.html

curl performs SSL certificate verification by default, using a "bundle"
of Certificate Authority (CA) public keys (CA certs). If the default
bundle file isn’t adequate, you can specify an alternate file
using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
the bundle, the certificate verification probably failed due to a
problem with the certificate (it might be expired, or the name might
not match the domain name in the URL).
If you’d like to turn off curl’s verification of the certificate, use
the -k (or --insecure) option.

Why does LE have a problem connecting to my web server when “the Internet” does not?

2

Using webroot instead actually worked. Cannot understand why but I’m happy that it works…

Followed these instructions:

root@mistik:/home/homeassistant/certbot# ./certbot-auto certonly --non-interactive --register-unsafely-without-email --agree-tos --expand --webroot --webroot-path /var/www/html --domain my.domain.org
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator webroot, Installer None
Cert is due for renewal, auto-renewing…
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for my.domain.org
Using the webroot path /var/www/html for all unmatched domains.
Waiting for verification…
Cleaning up challenges

IMPORTANT NOTES:

  • Congratulations! Your certificate and chain have been saved at:
    /etc/letsencrypt/live/my.domain.org/fullchain.pem
    Your key file has been saved at:
    /etc/letsencrypt/live/my.domain.org/privkey.pem
    Your cert will expire on 2018-05-10. To obtain a new or tweaked
    version of this certificate in the future, simply run certbot-auto
    again. To non-interactively renew all of your certificates, run
    "certbot-auto renew"

  • If you like Certbot, please consider supporting our work by:

    Donating to ISRG / Let’s Encrypt: https://letsencrypt.org/donate
    Donating to EFF: https://eff.org/donate-le

1 Like
3

Based on your logs, Certbot was trying to use the TLS-SNI challenge (which was permanently disabled recently due to a security issue).

The TLS-SNI challenge tries to connect over 443/tcp. So the timeout would have related to the connection to your host over that port. For what it’s worth, I can’t connect to your server over 443 either (but I see you removed the firewall rules - keep in mind that ports required for the challenge must be open at every renewal).

I am not altogether sure why Certbot tried to use that challenge, it is meant to be disabled in the version that you run.

The webroot option, which worked for you, uses the HTTP challenge rather than the TLS-SNI one.

You could have also used:

certbot --authenticator webroot --installer apache

rather than certonly.

1 Like
4

I read about that change and yes, strange, as I could see that my certbot-installation had been updated to latest version of the script.

My server was reachable on TCP port 443 at the time I ran the script. Verified from two different outside hosts (during the run of the script). Why the LE server could not reach it is a mystery. I did not check with tcpdump to see if it actually connected or not.

5

One problem for some people here has been having an IPv6 AAAA record pointing to an IPv6 address that doesn’t actually work. I cna’t tell if that’s the case for your site because you didn’t share your domain here.

6

You can find it in a certbot log linked somewhere above :wink:

1 Like
7

Good point! OK, that particular domain does not have an IPv6 record so that isn’t the problem in this case.

8

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