When I try to renew the certificates for my domains, I get the following log:
Attempting to renew cert from /etc/letsencrypt/renewal/my-domain.com.conf produced an unexpected error: Failed authorization procedure. my-domain.com (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:
Apparently certbot try to check the domian calling the IP and port, but I cannot serve my-domain.com 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.
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.
My domain name is: www.vebidoo.es and the IP were: 148.251.178.101 (where the issue came) and 136.243.17.97 (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?
Yes, I have a cronjob for the renewal and It work for other domain names. And at 136.243.17.97 is all ok with the same Apache config. What expects Boulder when it tries to call 148.251.178.101:443, 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.
You issued your certificate for vebidoo.es and www.vebidoo.es and when you issued your certificate the machine had the ip 148.251.178.101 and you changed the ip on that machine or moved your domain to another machine and now the ip is 136.243.17.97 which is the one for your domain vebidoo.es and www.vebidoo.es. Is this correct?.
Which is the exact command you used to issue your certificate?.
What is the content of /etc/letsencrypt/renewal/vebidoo.es.conf or maybe it is /etc/letsencrypt/renewal/www.vebidoo.es.conf ?.
It is really strange that vebidoo.es is pointing to ip 136.243.17.97 and Let's Encrypt tries to validate it using the old ip 148.251.178.101. 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?.
We have two servers (each with a different IP) behind our DNS entries. They serve multiple domains (one of them is www.vebidoo.es). They have the same configuration.
There is a redirect (301) from vebidoo.es to www.vebidoo.es.
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 www.vebidoo.es
But I got again a similar error: The server could not connect to the client to verify the domain :: Failed to connect to 148.251.178.101:443 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 should review your redirect, it is not normal to redirect an https to http and then to https again:
$curl -IkL https://vebidoo.es
HTTP/1.1 301 Moved Permanently
Date: Thu, 11 May 2017 13:09:26 GMT
Server: Apache/2.4.10 (Debian)
Location: http://www.vebidoo.es/
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)
Location: https://www.vebidoo.es/
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 vebidoo.es 2017-May-09 08:24 CEST 2017-Aug-07 08:24 CEST 87 days vebidoo.es
131318433 www.vebidoo.es 2017-May-01 01:31 CEST 2017-Jul-30 01:31 CEST 79 days vebidoo.es
www.vebidoo.es
130610755 blog.vebidoo.es 2017-Apr-29 11:36 CEST 2017-Jul-28 11:36 CEST 77 days blog.vebidoo.es
97639487 blog.vebidoo.es 2017-Feb-28 10:28 CET 2017-May-29 11:28 CEST 17 days blog.vebidoo.es
97617312 www.vebidoo.es 2017-Feb-28 08:26 CET 2017-May-29 09:26 CEST 17 days vebidoo.com
vebidoo.de
vebidoo.es
vebidoobiz.de
www.vebidoo.com
www.vebidoo.de
www.vebidoo.es
www.vebidoobiz.de
97334085 www.vebidoo.es 2017-Feb-27 14:36 CET 2017-May-28 15:36 CEST 17 days vebidoo.es
www.vebidoo.es
97333542 www.vebidoo.es 2017-Feb-27 14:34 CET 2017-May-28 15:34 CEST 17 days vebidoo.es
www.vebidoo.es
97244202 www.vebidoo.es 2017-Feb-27 10:02 CET 2017-May-28 11:02 CEST 16 days vebidoo.es
www.vebidoo.es
Are you sure it is not trying to issue a certificate for one of the other domains like vebidoo.com or vebidoo.de? Because those domains have 2 A records, pointing to both ips.
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.
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 www.vebidoo.es (no wildcards).
Before trying to use the webroot method I advice to put a test file inside /path/to/www.vebidoo.es/DocumentRoot/.well-known/acme-challenge/ and check you can get that test file using curl or your web browser.
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/www.vebidoo.es/ 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/www.vebidoo.es-000x/ 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.
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”.
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; 1.1.1.1 and 2.2.2.2, the first one 1.1.1.1 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 1.1.1.1 create a new VirtualHost for letsencrypt.yourdomain.tld (this domain will have only an A record pointing to 1.1.1.1) 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).
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 (1.1.1.1) 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.