Switched to LE-Certificate since January 2016 with apache-plugin of letsencrypt-auto without any problem with tld.net and pod.tld.net
First renewal in march worked flawlessly.
Cert expired few days ago, tried to renew but because of unknown reason letsencrypt-auto failed on setting up environment (I later understood that it couldn’t compile cryptography despite having enough memory … couldn’t activate backports for lubuntu and decided to resetup the server with debian jessie (bananian to be exact).
Installing certbot via backports on jessie-server and restoring /etc/letsencrypt and apache-vhosts
Calling tld and subdomain in browser results in HSTS-Warning and SEC_ERROR_EXPIRED_CERTIFICATE error.
The actual problem
sudo certbot renewal --apache leeds to
2016-06-18 16:32:35,690:WARNING:certbot.renewal:Attempting to renew cert from /etc/letsencrypt/renewal/pod.tld.net.conf produced an unexpected error: Failed authorization procedure. pod.tld.net (tls-sni-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Failed to connect to 92.228.254.191:443 for TLS-SNI-01 challenge, tld.net (tls-sni-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Failed to connect to 92.228.254.191:443 for TLS-SNI-01 challenge. Skipping.
Which is odd as obivously the server is connectable since I receive the old expired cert despite or do I mix up sth?
Even odder: I checked my IP and actually noticed a different IP to the error message. Copying the IPs into browser as url both reach the server! Seems that the DNS used by LE didn’t’t receive my actual IP (dyndns via ddclient with udmedia as my domain-host) yet but the old one still routes to my server …
#However …
I would have expected the renewal to work with both IPs reaching the server and don’t understand why connection seems to fail while SSL is working with expired certs.
How can I step further? Is the failure really caused by the IP mismatch? Or do I have to check elsewhere?
Prospective thanks for your help!
Update #1
curl 92.228.254.191:443 (old IP used by certbot)
leads to:
400 Bad Request
Bad Request
Your browser sent a request that this server could not understand.
Reason: You're speaking plain HTTP to an SSL-enabled server port.
Instead use the HTTPS scheme to access this URL, please.
Apache/2.4.10 (Debian) Server at ismus.net Port 443
If I understand correctly, you're saying that 92.228.254.191 is not the correct IP address for your domain?
Let's Encrypt performs authoritative DNS requests, meaning it will always contact the actual name server for your domain. DNS records are not cached. Make sure that the A record for your domain actually points to the correct IP. One common gotcha is that your own router might have some static DHCP mapping or something like that which will make it look like the IP is correct in the DNS, but that's actually just the case when you're doing it inside of your network. Try it from a VPS outside of your network, or use dig to query your name server directly:
dig google.com NS
; <<>> DiG 9.8.3-P1 <<>> google.com NS
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13994
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;google.com. IN NS
;; ANSWER SECTION:
google.com. 345600 IN NS ns4.google.com.
google.com. 345600 IN NS ns1.google.com.
google.com. 345600 IN NS ns2.google.com.
google.com. 345600 IN NS ns3.google.com.
(ns1-ns4.google.com are the name servers, pick one for the next command)
dig @ns1.google.com google.com A
; <<>> DiG 9.8.3-P1 <<>> @ns1.google.com google.com A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30971
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available
;; QUESTION SECTION:
;google.com. IN A
;; ANSWER SECTION:
google.com. 300 IN A 172.217.18.174
Thanks for your help.
Actually I cannot reach the old IP from outside my local network, so you’re right - there seems to be some caching in my provider forced router
So the problem seems to be that my actual IP isn’t communicated fast enough to the dns-servers? Is there any workaround for me? Changing the dns-server in my /etc/resolv.conf? It’s strange, I didn’t have such problems in the last 6 months
There isn’t really a workaround other than ensuring that your DNS records are correct at the time you attempt renewal. Let’s Encrypt cannot rely on your local DNS server, that would be a massive vulnerability (what’s to stop you from pointing google.com to your IP? ) Maybe you can use a --pre-hook script with certbot renew which updates your DNS records? Most dynamic DNS providers have fairly simple APIs, so this should be possible to do in a small bash script.
I’m actually checking a hypothesis:
I just realized that my ddclient didn’t work properly since resetting up my server. And because of the dns-caching of my router I had the illusion of working. Debugging the ddclient lead me to the following message:
FATAL: Error loading the Perl module IO::Socket::SSL needed for SSL connect.
FATAL: On Debian, the package libio-socket-ssl-perl must be installed.
FATAL: On Red Hat, the package perl-IO-Socket-SSL must be installed.
which could be due to my domain-provider made ssl mandatory 2 months ago. After installing this package now ddclient works without error message. I guess I have to wait some hours now to retry the renewal but am full of hope that it will work now
) Maybe you can use a 
