Renewal failure: Failed to connect ... TLS-SNI-01 challenge

The problematic installation was a fully working system for several months, with LE certificates installed and working fine for 2 domains. I got an email notifiation of one about ready to expire. I tried the renewal command, and it won't renew with this error:

Domain: !
Type: connection
Detail: Failed to connect to for TLS-SNI-01

After repeated failures I blew away the letsencrypt installation and re-installed and also deleted /etc/letsencrypt. Same exact problem.

Command line I am currently trying (with many, many variations):

./certbot-auto -v certonly --apache -n --agree-tos -d

After googling, I tried various solutions related to firewalls, etc. I have no problem telnetting to port 443 both from the local system and a remote system. So thats not it. Tried completely dropping the firewall, no go.

Thinking something changed with the Apache configuration, I tried a webroot install, and that fails too (different error ... basically unable to create a file I think).

The system is Ubuntu 16.04 / Apache.


Are you running certbot-auto as root?

Yes. There was a folder created, called something like .well-known, but it was empty. Thx.

I had a different system (Ubuntu 14.04) try to auto renew last night. Different but similar errrors:

Type: unauthorized
Detail: Incorrect validation certificate for TLS-SNI-01 challenge.

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.

Domain is correct as is the IP address. Again, this was (still is technically) a working, functional system using LE certs.

The second error typically happens when the domain is behind a reverse proxy or CDN (CloudFlare, etc.), or more generally speaking: whenever you’re running the client on a system that’s not terminating TLS for your domain. It could also be a bug in the apache plugin where it fails to (temporarily) modify your configuration (by adding a new vhost) in a way that makes apache use the “special” validation certificate for the request from Let’s Encrypt. If you’re behind something like CloudFlare, you’ll need to use the webroot plugin (or DNS-01 with one of the alternative clients).

As a general sanity check for your first host (with the connection error), see if you can ping (which is where the validation requests come from at the moment). This won’t rule out that there’s some inbound-only filtering by, say, your ISP, but if the ping fails as well, it confirms some kind of network problem.

I’d be curious about the exact error you got with the webroot plugin, if you want to try that again.

Not cloudfare, load balancer, varnish, proxy … both of these are basic Rackspace cloud servers with Ubuntu LAMP. There is a non-standard/legacy vhosts configuration on these, which LE can’t find, and that’s why the ‘-n’ flag (at least that seems to stop the attempt to find the files it can’t find). This has worked fine for a while. And, I’d actually prefer to modify my own server configs.

Ping works fine.

Just retried the webroot on one domain, and it worked fine! Question though: this domain is restricted by Apache basic auth (the others in question are not). The webroot approach can’t handle that. Can you suggest a rule to allow LE through? Is the DNS consistent?

Thanks for the help.

I’d recommend disabling basic auth for all requests to /.well-known/acme-challenge/*. The IP (or host) should not be considered static and might change without prior notice (or be extended to multiple validation requests from different IPs).

Here’s one way to do this with apache.

Thanks. Didn’t know about that one.

I’ve gotten another strange error after renewing with webroot. Apache seems ok, at least to the point of restarting without any errors. But, the certificate doesn’t seem to be valid.

> $ curl -s -k -v
> * Hostname was NOT found in DNS cache
> *   Trying
> * Connected to ( port 443 (#0)
> * successfully set certificate verify locations:
> *   CAfile: none
>   CApath: /etc/ssl/certs
> * SSLv3, TLS handshake, Client hello (1):
> * error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol

> <C-F3>$ openssl s_client -connect -prexit
> CONNECTED(00000003)
> 140250108479136:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol:s23_clnt.c:795:
> ---
> no peer certificate available
> ---
> No client certificate CA names sent
> ---
> SSL handshake has read 7 bytes and written 295 bytes
> ---
> New, (NONE), Cipher is (NONE)
> Secure Renegotiation IS NOT supported
> Compression: NONE
> Expansion: NONE
> ---
> ---
> no peer certificate available
> ---
> No client certificate CA names sent
> ---
> SSL handshake has read 7 bytes and written 295 bytes
> ---
> New, (NONE), Cipher is (NONE)
> Secure Renegotiation IS NOT supported
> Compression: NONE
> Expansion: NONE

Apache ssl log:

> [Tue Aug 02 21:49:09.985985 2016] [ssl:info] [pid 10853] AH01914: Configuring server for SSL protocol
> [Tue Aug 02 21:49:09.986324 2016] [ssl:debug] [pid 10853] ssl_engine_init.c(925): AH01904: Configuring server certificate chain (1 CA certificate)
> [Tue Aug 02 21:49:09.986337 2016] [ssl:debug] [pid 10853] ssl_engine_init.c(392): AH01893: Configuring TLS extension handling
> [Tue Aug 02 21:49:09.986551 2016] [ssl:debug] [pid 10853] ssl_util_ssl.c(443): AH02412: [] Cert matches for name '' [subject: / issuer: CN=Let's Encrypt Authority X3,O=Let's Encrypt,C=US / serial: 03025AAE3F79630AA8699D8664FF90721AD4 / notbefore: Aug  2 15:22:00 2016 GMT / notafter: Oct 31 15:22:00 2016 GMT]
> [Tue Aug 02 21:49:09.986585 2016] [ssl:info] [pid 10853] AH02568: Certificate and private key configured from /etc/letsencrypt/live/ and /etc/letsencrypt/live/

The only thing I get out of that is that the path to the certificate might be wrong during the handshake (but its clearly not set as /etc/ssl/certs in the Apache configs).

This seems more like a server configuration/protocol problem, doesn't seem to be related to the certificate.

Are you serving HTTP on port 443 (due to some misconfiguration. i.e. a missing SSLEngine on) by any chance? You can browse to to verify - if you see a page, you're doing HTTP on the HTTPS port.

That's just curl loading the trusted root certificates, nothing on the server side.

Yea, I tried a self signed certificate, its borked too.

Going to :443 directly I do see a page! SSLEngine is definitely on though. Strange …


I had commented out the ssl* lines for the cert itself, etc, on the other domain on this certificate, but left the rest of the *:443 section in place, not realizing that was a no-no. So seems wonderfully good now. Thanks for the help. Took a lot of googling to find that out.

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