Renewal requests rejected

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g., so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is:

I ran this command: certbot renew

It produced this output:
Saving debug log to /var/log/letsencrypt/letsencrypt.log

Processing /etc/letsencrypt/renewal/

Cert is due for renewal, auto-renewing…
Plugins selected: Authenticator webroot, Installer None
Attempting to renew cert ( from /etc/letsencrypt/renewal/ produced an unexpected error: Requesting Network is unreachable. Skipping.
All renewal attempts failed. The following certs could not be renewed:
/etc/letsencrypt/live/ (failure)

All renewal attempts failed. The following certs could not be renewed:
/etc/letsencrypt/live/ (failure)

1 renew failure(s), 0 parse failure(s)

My web server is (include version): Apache

The operating system my web server runs on is (include version): Debian v9

My hosting provider, if applicable, is:

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

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

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you’re using Certbot): 0.31.0

I am trying to renew a certificate. I can resolve the domain name and I try to connect to it but I get a TCP reset back killing the connection. I have reduced the MTU on my NIC to 1200 as I heard that can help but it didn’t. As you can see in the FW logs below, my connect reaches the server but it rejected with a TCP reset in bold.

1: 20:01:26.321638 802.1Q vlan#97 P0 192.168.xx.xx.55302 > 192.168.xx.xx.53: udp 39
2: 20:01:26.322737 802.1Q vlan#97 P0 192.168.xx.xx.53 > 192.168.xx.xx.55302: udp 103
10: 20:01:30.542193 802.1Q vlan#97 P0 192.168.xx.xx.37192 > S 2877232600:2877232600(0) win 23200 <mss 1160,sackOK,timestamp 47460041 0,nop,wscale 7>
11: 20:01:30.542238 802.1Q vlan#97 P0 > 192.168.xx.xx.37192: R 0:0(0) ack 2877232601 win 23200

Any advice would be appreciated.


1 Like

Does your machine have outbound connectivity?

I don’t get the reset, I timeout, as if iptables drops me. Is the correct ip address?


% nmap -Pn
Starting Nmap 7.80 ( ) at 2020-03-19 10:22 CET
Nmap scan report for (
Host is up.
All 1000 scanned ports on ( are filtered

(ignore “host is up”, it’s meaningless when using -Pn)

1 Like

Thanks for the response. As this is not a publicly accessible server it is not normally accessible from the internet but I do make it temporarily available to renew the cert.

That being said, I had thought the TCP reset in my original post was coming from the letencrypt server but it was coming from our firewall. I have resolved that now and can see healthy communications between the our server and letsencrypt as shown below but the renewal is still failing.

4: 00:51:23.875870 > S 76436964:76436964(0) win 23200 <mss 1160,sackOK,timestamp 1709954653 0,nop,wscale 7>
5: 00:51:23.876312 > S 1272044911:1272044911(0) ack 76436965 win 65535 <mss 1460,nop,nop,sackOK,nop,wscale 10>
6: 00:51:23.876755 > . ack 1272044912 win 182
7: 00:51:23.887206 > P 76436965:76437321(356) ack 1272044912 win 182
8: 00:51:23.887557 > . ack 76437321 win 66
9: 00:51:24.258592 > . 1272044912:1272046072(1160) ack 76437321 win 66
10: 00:51:24.258607 > P 1272046072:1272046372(300) ack 76437321 win 66
11: 00:51:24.258623 > . 1272046372:1272047532(1160) ack 76437321 win 66
12: 00:51:24.258638 > P 1272047532:1272047832(300) ack 76437321 win 66
13: 00:51:24.258638 > P 1272047832:1272048299(467) ack 76437321 win 66
14: 00:51:24.259340 > . ack 1272046372 win 205
15: 00:51:24.259340 > . ack 1272047832 win 227
16: 00:51:24.259355 > . ack 1272048299 win 245

I am getting the error “Failed Authorisation Procedure, the server could not connect to the client to verify the domain. Timeout during connection”.

When I did the capture on the firewall shown above, I could see outbound connections from my server to letsencrypt working fine. When renewing in the past I would then see a new connection made back to my server to verify the domain but I never saw this on the firewall when it failed most recently.

While I have now disabled internet connectivity for my server until I try to renew again, I can confirm I have been able to reach this server from the internet when I open it up on my firewall. This is shown below:

1: 01:04:03.603835 203.206.xx.xx.50686 > S 2746238189:2746238189(0) win 64240 <mss 1380,sackOK,timestamp 1174803913 0,nop,wscale 7>
2: 01:04:03.604430 203.206.xx.xx.443 > S 800322711:800322711(0) ack 2746238190 win 22960 <mss 1160,sackOK,timestamp 2827480731 1174803913,nop,wscale 7>
3: 01:04:03.616560 203.206.xx.xx.50686 > . ack 800322712 win 502 <nop,nop,timestamp 1174803926 2827480731>
4: 01:04:03.619337 203.206.xx.xx.50686 > P 2746238190:2746238707(517) ack 800322712 win 502 <nop,nop,timestamp 1174803929

So I am not sure why this is still failing. It seems like the connection back to my server to verify the domain is not occuring.


1 Like

if you don’t want your machine to be publicly reachable during validation by ANY ip (see “multi-perspective validation”) you should switch to dns-01 validation.

the connection is happening, multiple times, from multiple IPs.

1 Like

Just to confirm the expected flow, this is how I understand it:

  • My server initiates a connection to which can be seen above in packets between by server and
  • A second connection(s), the one you are referring to in your last message, is initiated from LetsEncrypt back to my server address. This is the validation step.

That is how I understand it but I am just not seeing any new connections hit my firewall to after the connection from to is initiated. I assume I am right in thinking the second connection will target TCP443 on my server, I can’t imagine what other port it would use.

I only had DNS set up 6-7 hours ago, that should be plenty of time but maybe it hasn’t propagated yet though the failure didn’t mention anything about DNS not resolving, it was about a connection timeout. I assume that connection it is referring to is the second, validation connection, but I just don’t see it hitting my firewall.


1 Like

Then initiates several others to different endpoints, to do what ACME does.

When the client tells LE that a challenge is ready,

But it doesn’t happen like this. It’s initiated from arbitrary IP addresses, always more than one. And it connects on port 80. (for http-01)

1 Like

I think I see the issue. it looks as though the connection back for validation is using HTTP not HTTPS. I was looking for inbound connections on TCP443

Thanks, one or many addresses, it doesn’t really matter, the firewall would let them all through while I do this work. The issue is I expected the connections to be on TCP443, so I just need to allow TCP80 and it should be fine, that is once my rate-limit hour has expired.

Thanks for your assistance.

1 Like

you know about --pre-hook and --post-hook already, do you?

1 Like

Nope, no idea what they are.

certbot options that specify commands to be run before and after obtaining certificates:

  --pre-hook PRE_HOOK   Command to be run in a shell before obtaining any
                        certificates. Intended primarily for renewal, where it
                        can be used to temporarily shut down a webserver that
                        might conflict with the standalone plugin. This will
                        only be called if a certificate is actually to be
                        obtained/renewed. When renewing several certificates
                        that have identical pre-hooks, only the first will be
                        executed. (default: None)
  --post-hook POST_HOOK
                        Command to be run in a shell after attempting to
                        obtain/renew certificates. Can be used to deploy
                        renewed certificates, or to restart any servers that
                        were stopped by --pre-hook. This is only run if an
                        attempt was made to obtain/renew a certificate. If
                        multiple renewed certificates have identical post-
                        hooks, only one will be run. (default: None)
1 Like