Hi to all
I try to renew a certificate with 7 alternate names. I run the command certbot renew and it don´t work.
I get the message that the server can´t connect with client. Viewing the log file, domain name is resolved to ip, challenge files are created but at last get the message that the server (acme-v01.api.letsencrypt.org) can´t connect to the client with status 400.
Some times this occurs with 3 of the alternate names, some times with 4…
I put an html file in the .well-known directory and is reachable. certbot renew --dryn-run don´t show any error message
Any clue in this?
Hi @lofesa,
Please fill out the questions that are on the new thread template. Specifically:
- What are the domain names you’re trying to issue for?
- What is your Certbot version?
- Do you have logs from the failures?
- Are you using HTTP-01 challenges with standalone mode? Other?
Hi @cpu
Domain name is intersindicalrm.org, all other 6 alternate names are subdomains of this.
Certbot version: 0.9.3
Yes, I had a log file
letsencrypt.txt (112.1 KB)
I think yes, are HTTP-01 as I can see in the log file “type”: “http-01”
certbot is installed from epel repo.
Thx in advance, and sorry for spam other thread.
Hi @lofesa,
From the Boulder side we’re seeing a “Client.Timeout exceeded while awaiting headers” error underlying the {"error":{"type":"urn:acme:error:connection","detail":"Could not connect to intersindical.intersindicalrm.org","status":400}, object returned to Certbot.
This doesn’t seem to be a Boulder issue. It has come up with Certbot in the past - I recommend you add your log & information to that thread and see if the Certbot developers are able to help diagnose why your server configuration is timing out.
To confirm: you’ve retried this since the earlier incident ended?
yes, I retried some times. The log you see are the last try
Thx.
Interestingly, the validation record for intersindicalrm.org indicates that the initial connection to intersindicalrm.org on port 80 worked. The response was a redirect to https://intersindical.intersindicalrm.org/.well-known/acme-challenge/Yiwp5VXeF1yNusFPufTlTKK8qsHreYltgmpCosh8Ivs, which resolved to the same IP, but that request (this time to port 443) seems to fail.
Any chance you run some other commands as part of your renewal script, one of which does something like disable HTTPS on your web server (which would explain the request timing out)?
Hi @pfg
No renewal script but command line “certbot renewal --rsa-key-size 4096”.
The redirection from port 80 to 443 are for historical reasons, we have moved these webs from http to https in the last september thus a lot of people had the old http url´s
Very odd. If it’s due to some network issue anywhere between you and Let’s Encrypt’s validation server, I would have expected port 80 to be affected too, but that seems to be working.
Can you check your server logs to see if the request for https://intersindical.intersindicalrm.org/.well-known/acme-challenge/Yiwp5VXeF1yNusFPufTlTKK8qsHreYltgmpCosh8Ivs is reaching your server, and if you’re sending a reply? The request would’ve been made from 66.133.109.36 (there might be another one from localhost - not sure if certbot still attempts to self-validate challenges).
Yes I have and the response is …404
213.47.56.124 - - [14/Dec/2016:19:39:30 +0100] “GET /.well-known/acme-challenge/Yiwp5VXeF1yNusFPufTlTKK8qsHreYltgmpCosh8Ivs HTTP/2.0” 404 5280 “-” “Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2946.0 Safari/537.36” “intersindical.intersindicalrm.org”
This says that the challenge file is not created?
If I put an html file in /.wee-known/ I can read it
Perhaps can´t create acme-challenge directory?
That’s from my tests - you’d be looking for a request from 66.133.109.36. If you don’t have one from that IP, it would appear that the request is not reaching your server. If you have a separate error log, might be worth digging there too.
Might be an idea to check if you have any firewall logs (often in your syslog) mentioning that IP as well. If that doesn’t turn up anything either, try running tcpdump -n "src host 66.133.109.36 and port 443" to see the network traffic the validation server is sending to port 443 and then try to renew again.
Have a lot of request from 66.133.109.36 in the web´s servers logs, some with 200, some with 404 and some wiht 301 responses. In the syslog don´t have aby entry with these ip nor in the fail2ban logs.
Seem that challenge files some times sre created and some times not
Here the tcpdump:
20:54:13.367184 IP 66.133.109.36.55408 > 178.79.148.103.https: Flags [S], seq 1678533312, win 29200, options [mss 1460,sackOK,TS val 3546257115 ecr 0,nop,wscale 7], length 0
20:54:13.495535 IP 66.133.109.36.55408 > 178.79.148.103.https: Flags [.], ack 2572783710, win 229, options [nop,nop,TS val 3546257244 ecr 128981136], length 0
20:54:13.495744 IP 66.133.109.36.55408 > 178.79.148.103.https: Flags [P.], seq 0:170, ack 1, win 229, options [nop,nop,TS val 3546257244 ecr 128981136], length 170
20:54:13.529425 IP 66.133.109.36.55414 > 178.79.148.103.https: Flags [S], seq 1335314854, win 29200, options [mss 1460,sackOK,TS val 3546257278 ecr 0,nop,wscale 7], length 0
20:54:13.627786 IP 66.133.109.36.55408 > 178.79.148.103.https: Flags [.], ack 1449, win 251, options [nop,nop,TS val 3546257377 ecr 128981267], length 0
20:54:13.627854 IP 66.133.109.36.55408 > 178.79.148.103.https: Flags [.], ack 2897, win 274, options [nop,nop,TS val 3546257377 ecr 128981267], length 0
20:54:13.627861 IP 66.133.109.36.55408 > 178.79.148.103.https: Flags [.], ack 3668, win 296, options [nop,nop,TS val 3546257377 ecr 128981267], length 0
20:54:13.628475 IP 66.133.109.36.55408 > 178.79.148.103.https: Flags [P.], seq 170:296, ack 3668, win 296, options [nop,nop,TS val 3546257377 ecr 128981267], length 126
20:54:13.757417 IP 66.133.109.36.55408 > 178.79.148.103.https: Flags [P.], seq 296:724, ack 3719, win 296, options [nop,nop,TS val 3546257506 ecr 128981397], length 428
20:54:13.887754 IP 66.133.109.36.55408 > 178.79.148.103.https: Flags [P.], seq 724:755, ack 4196, win 319, options [nop,nop,TS val 3546257636 ecr 128981527], length 31
20:54:13.887879 IP 66.133.109.36.55408 > 178.79.148.103.https: Flags [R.], seq 755, ack 4228, win 319, options [nop,nop,TS val 0 ecr 128981527], length 0
20:54:13.894306 IP 66.133.109.36.55466 > 178.79.148.103.https: Flags [S], seq 291787628, win 29200, options [mss 1460,sackOK,TS val 3546257643 ecr 0,nop,wscale 7], length 0
20:54:14.415760 IP 66.133.109.36.55540 > 178.79.148.103.https: Flags [S], seq 622765205, win 29200, options [mss 1460,sackOK,TS val 3546258164 ecr 0,nop,wscale 7], length 0
20:54:14.530881 IP 66.133.109.36.55414 > 178.79.148.103.https: Flags [S], seq 1335314854, win 29200, options [mss 1460,sackOK,TS val 3546258280 ecr 0,nop,wscale 7], length 0
20:54:14.894688 IP 66.133.109.36.55466 > 178.79.148.103.https: Flags [S], seq 291787628, win 29200, options [mss 1460,sackOK,TS val 3546258644 ecr 0,nop,wscale 7], length 0
20:54:15.416740 IP 66.133.109.36.55540 > 178.79.148.103.https: Flags [S], seq 622765205, win 29200, options [mss 1460,sackOK,TS val 3546259166 ecr 0,nop,wscale 7], length 0
20:54:16.534600 IP 66.133.109.36.55414 > 178.79.148.103.https: Flags [S], seq 1335314854, win 29200, options [mss 1460,sackOK,TS val 3546260284 ecr 0,nop,wscale 7], length 0
20:54:16.898632 IP 66.133.109.36.55466 > 178.79.148.103.https: Flags [S], seq 291787628, win 29200, options [mss 1460,sackOK,TS val 3546260648 ecr 0,nop,wscale 7], length 0
20:54:17.418720 IP 66.133.109.36.55540 > 178.79.148.103.https: Flags [S], seq 622765205, win 29200, options [mss 1460,sackOK,TS val 3546261168 ecr 0,nop,wscale 7], length 0
Hi @cpu @pfg
I can confirm, the issue was the redirections from port 80 to the port 443.
I have commented the lines that does the redirection in server config and renewal was succesfull.
2 Likes
Wonderful! I’m glad to hear it. Thanks for posting your success follow-up.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.