Infrastructure Setup Means Certbot Challenges Are Not Passing

When I try to renew the certificates for my domains, I get the following log:

Attempting to renew cert from /etc/letsencrypt/renewal/ produced an unexpected error: Failed authorization procedure. (tls-sni-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Failed to connect to XXX.XXX.XXX.XXX:443 for tls-sni-01 challenge. Skipping.

We host multiple domains under the same IP. My virtualhosts are like this:

<IfModule mod_ssl.c>
    <VirtualHost *:443>

Apparently certbot try to check the domian calling the IP and port, but I cannot serve under the request because there are multiple domains under the same IP. I think it gets any other domain, but crash the request with 400.

What can I do?

Can you share the domain name that is failing authorization? To me this looks like a case where Boulder (the server-side of Let's Encrypt that Certbot talks to) can't reach your domain at the IP it resolves to on port 443.

hi @antonioromero

This should have gone in the help section.

Below are the usual questions that are asked to assist in cases like this.

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

My domain is:

I ran this command:

It produced this output:

My operating system is (include version):

My web server is (include version):

My hosting provider, if applicable, is:

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

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


My domain name is: and the IP were: (where the issue came) and (OK).
Currently is only the right one behind that domain name domain name.

Those machines host multiple name-based virtual hosts, so I did not want to serve a specific domain name if anybody calls with IP. Do you think I should to configurate a catch-all?

The configuration for both machines are similar. Why comes the failure only at one of them?

Was running Apache listening on 443 at the time that you tried to run the renewal process?

Yes, I have a cronjob for the renewal and It work for other domain names. And at is all ok with the same Apache config. What expects Boulder when it tries to call, a specific domain or any “right” response?

Ah, maybe important, althought the error was the same. I have tried to remove the certificate at that machine and create a “clean” new one. But the error is the same.

Hola @antonioromero,

Just to clarify.

You issued your certificate for and and when you issued your certificate the machine had the ip and you changed the ip on that machine or moved your domain to another machine and now the ip is which is the one for your domain and Is this correct?.

Which is the exact command you used to issue your certificate?.

What is the content of /etc/letsencrypt/renewal/ or maybe it is /etc/letsencrypt/renewal/ ?.

It is really strange that is pointing to ip and Let's Encrypt tries to validate it using the old ip Maybe I didn't understand the issue but as you obfuscated the info in your first message it is confusing me ;).

Again, please, put the exact command you used and the output of that command.

Also, did you modify the conf of your virtual host after issue the first certificate for your domain?.

Un saludo,

We have two servers (each with a different IP) behind our DNS entries. They serve multiple domains (one of them is They have the same configuration.
There is a redirect (301) from to

Because I could not renew the certificate, I have tried to delete the certificate from that server and create a new one:

Command: certbot --apache -d

But I got again a similar error:
The server could not connect to the client to verify the domain :: Failed to connect to for tls-sni-01 challenge.

Then and because I could not progress with the issue, I must take away one server from the DNS.

You didn't put all the info I requested :P.

You should review your redirect, it is not normal to redirect an https to http and then to https again:

$curl -IkL
HTTP/1.1 301 Moved Permanently
Date: Thu, 11 May 2017 13:09:26 GMT
Server: Apache/2.4.10 (Debian)
Cache-Control: max-age=604800
Expires: Thu, 18 May 2017 13:09:26 GMT
Content-Type: text/html; charset=iso-8859-1

HTTP/1.1 301 Moved Permanently
Date: Thu, 11 May 2017 13:09:26 GMT
Server: Apache/2.4.10 (Debian)
Cache-Control: max-age=604800
Expires: Thu, 18 May 2017 13:09:26 GMT
Content-Type: text/html; charset=iso-8859-1

HTTP/1.1 200 OK
Date: Thu, 11 May 2017 13:09:26 GMT
Server: Apache/2.4.10 (Debian)
Cache-Control: max-age=604800
Expires: Thu, 18 May 2017 13:09:26 GMT
Content-Type: text/html;charset=UTF-8

You already have a few valid certificates:

CRT ID     DOMAIN (CN)      VALID FROM              VALID TO                EXPIRES IN  SANs
134918627       2017-May-09 08:24 CEST  2017-Aug-07 08:24 CEST  87 days
131318433   2017-May-01 01:31 CEST  2017-Jul-30 01:31 CEST  79 days
130610755  2017-Apr-29 11:36 CEST  2017-Jul-28 11:36 CEST  77 days
97639487  2017-Feb-28 10:28 CET   2017-May-29 11:28 CEST  17 days
97617312   2017-Feb-28 08:26 CET   2017-May-29 09:26 CEST  17 days
97334085   2017-Feb-27 14:36 CET   2017-May-28 15:36 CEST  17 days
97333542   2017-Feb-27 14:34 CET   2017-May-28 15:34 CEST  17 days
97244202   2017-Feb-27 10:02 CET   2017-May-28 11:02 CEST  16 days

Are you sure it is not trying to issue a certificate for one of the other domains like or Because those domains have 2 A records, pointing to both ips.

You have also a DNSSEC misconfiguration that you should review too:

You should provide the conf requested or it is really hard to understand what your problem is.

Anyway, at this point I would try to issue a new cert using certonly and --webroot, avoiding the use of -apache option to be sure that is not the problem.


Hi @sahsanu!

Many thanks for analysis. The redirects issue should already be fixed.
We had requested some certificates for the domain but some of them were not right configured or belongs for another subdomains.

The certificate that I try to request should be only for (no wildcards).



PD: the URL “” should be ->

Hola @antonioromero,

At this point I would use the webroot method to get the certificate.

certbot certonly --webroot -w /path/to/ -d

Before trying to use the webroot method I advice to put a test file inside /path/to/ and check you can get that test file using curl or your web browser.

mkdir -p  /path/to/
echo -n "Testing acme-challenge" >  /path/to/

And now use your browser to get that test file:

Or use curl from command line:

curl -ikL

If you get the text "Testing acme-challenge" the you could try the webroot method.

Keep in mind that it is possible that you already have an entry /etc/letsencrypt/live/ because you already created a cert using it as your first option, if that is the case, certbot could ask to overwrite the contents of that cert or will create a new dir /etc/letsencrypt/ where the x is a number, so pay attention to Congratulations message when you issue the cert because there you will see where your cert is being saved.

Sorry, you are right, I mistyped your domain name.

Buena suerte,

Muy buenas @sahsanu,

Thanks again for your help. I will try it, but I have first a few question.

I suspect that certbot want to write files under ‘.well-known/acme-challenge/’ and try to request them form the corresponding URL. But the DNS entry resolves to a couple of IPs, so I do not know which IP would it get. We synchronize our files, but the certbot may be faster than the sync. What do you think about?

Would be requested those files everytime we try to renew our cert under that server? There is a different behaviour for the renewing?

Do you know how could recover an active cert for my server? I mean. I have the current one removed (because it could not succesfully been updated) and you have show me there are still some of them “active”.

I will appreciate your advices.



Buenas @antonioromero,

To solve this situation you have several options.

1.- Instead of webroot method you could use the manual method and http challenge, with this method you should use the switch --manual-auth-hook and provide a script that put the challenge in the right path of both machines.

2.- The same as above but using dns challenge, with this method you should be able to create a TXT record on your dns provider so no matter where the ip is, it won't be used, only the TXT record. The problem with this method is that your DNS provider should have some kind of API to add records or it will be impossible to automate it.

3.- You have 2 servers serving the same content with apache so you could use one of them to resolve the challenges and the second one will redirect the challenge request to the first one on a specific domain.

I mean, you have two servers; and, the first one is where you will use the certbot command (in this case with the options (certonly --webroot blablabla) in this first server you will add a new VirtualHost that will be used to serve the challenge requests.

In the first machine create a new VirtualHost for letsencrypt.yourdomain.tld (this domain will have only an A record pointing to and its DocumentRoot pointing to for example /var/www/letsencrypt.

Now, edit the VirtualHost conf of the real domain (the one you need a certificate) and add a new Redirect directive (this redirect directive should be the first one in your VirtualHost conf).

Redirect /.well-known/acme-challenge/ http://letsencrypt.yourdomain.tld/.well-known/acme-challenge/

This redirect should be in the VirtualHost conf of your real domain in both machines and

Now to issue your cert, from the first server use the command:

certbot certonly --webroot -w /var/www/letsencrypt -d www.yourdomain.tld

Now, Let's Encrypt, will try to validate the challenge so it will try to reach http://www.yourdomain.tld/.well-known/acme-challenge/randomtoken and no matter what ip of www.yourdomain.tld it uses, both servers will answer with this redirect http://letsencrypt.yourdomain.tld/.well-known/acme-challenge/randomtoken and as domain letsencrypt.yourdomain.tld only have an ip defined ( the request will reach the first server where you have defined a VirtualHost for letsencrypt.yourdomain.tld and the DocumentRoot is /var/www/letsencrypt that is the right path you used in your certbot command so the challenge will be served from this machine and you will get your cert. Of course, you should implement something to copy the new cert to the right path on the other apache server and reload both of them (you can use the --renew-hook and/or --post-hook switches to provide a script to perform these actions).

Maybe some community's buddy could give you another approach to solve this issue.

If you try to renew your cert the first 30 days after you issued the cert, Let's Encrypt will renew your cert without performing any challenge check but as you should renew it after 30 days you should no worry about, certbot will try to renew the cert the same way you issued it the first time.

I hope this helps.

Un saludo,

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