Renew Certs Error

I keep receiving this error every time I try to renew a certificate for the last week:

Cert is due for renewal, auto-renewing…
Plugins selected: Authenticator nginx, Installer nginx
Starting new HTTPS connection (1):
Renewing an existing certificate
Attempting to renew cert ( from /etc/letsencrypt/renewal/ produced an unexpected error: HTTPSConnectionPool(host=‘’, port=443): Read timed out. (read timeout=45). Skipping.

Checked to see if I can connect to the server and I can, I made sure my website is publicly accessible and it is, rebooted webserver, router and dns server just in case still won’t renew.

so I’m out of ideas here, anyone else have some?

Hi @adam-themud,

This looks like an error from Certbot failing to reach Let's Encrypt's ACME server at Are you able to share a traceroute/mtr to that address? Does openssl s_client -connect </dev/null succeed for you?

many moons ago I worked on an LPC intermud2 implementation. Glad to see there's still MUDs out there :slight_smile:

openssl s_client -connect </dev/null

openssl s_client -connect </dev/null
depth=3 O = Digital Signature Trust Co., CN = DST Root CA X3
verify return:1
depth=2 C = US, O = IdenTrust, CN = IdenTrust Commercial Root CA 1
verify return:1
depth=1 C = US, O = IdenTrust, OU = TrustID Server, CN = TrustID Server CA A52
verify return:1
depth=0 CN = *, O = INTERNET SECURITY RESEARCH GROUP, L = Mountain View, ST = California, C = US
verify return:1

Certificate chain
0 s:/CN=* SECURITY RESEARCH GROUP/L=Mountain View/ST=California/C=US
i:/C=US/O=IdenTrust/OU=TrustID Server/CN=TrustID Server CA A52
1 s:/C=US/O=IdenTrust/OU=TrustID Server/CN=TrustID Server CA A52
i:/C=US/O=IdenTrust/CN=IdenTrust Commercial Root CA 1
2 s:/C=US/O=IdenTrust/CN=IdenTrust Commercial Root CA 1
i:/O=Digital Signature Trust Co./CN=DST Root CA X3

Server certificate
subject=/CN=* SECURITY RESEARCH GROUP/L=Mountain View/ST=California/C=US
issuer=/C=US/O=IdenTrust/OU=TrustID Server/CN=TrustID Server CA A52

No client certificate CA names sent
Peer signing digest: SHA256
Server Temp Key: ECDH, P-256, 256 bits

SSL handshake has read 5917 bytes and written 415 bytes

New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-GCM-SHA384
Session-ID: 1EFB2566D4A7F690010EABC7D3071D17ADF302C5F64446092ABE0960D9AD917A
Master-Key: 4EF0CCA135C306AB39106701042C94AE1A595DEA4BE31E752AB20B5CFDD0F498F2B78AFEF47B10E407C689CB479AC675
Key-Arg : None
Krb5 Principal: None
PSK identity: None
PSK identity hint: None
TLS session ticket lifetime hint: 7200 (seconds)
TLS session ticket:
0000 - 00 00 03 d5 01 d0 68 ba-73 6c 13 fd 91 01 b0 a4 ……
0010 - 9c 9f b1 8a 2b cb 16 2f-66 26 9c 8b 12 7a 5a d5 …+…/f&…zZ.
0020 - 53 37 72 42 4b 5a eb 16-4b 58 59 f7 b3 ec 0c 8d S7rBKZ…KXY…
0030 - d0 35 4d de e3 49 e3 bb-48 cb 40 86 48 dd c7 63 .5M…I…H.@.H…c
0040 - 01 8c 05 c3 93 69 24 82-aa 06 6a 58 66 a4 68 be …i$…jXf.h.
0050 - 1d 5d 20 50 86 01 8d 67-83 4e 6c 0f 94 d4 3b 10 .] P…g.Nl…;.
0060 - fb df 31 06 02 aa 39 ae-64 cb 9e 7c 34 ed 87 86 …1…9.d…|4…
0070 - 70 e5 7b 81 26 56 00 59-9c d6 2c 22 aa 1b 1d 61 p.{.&V.Y…,"…a
0080 - f0 cd ac e3 d9 ac fd be-fa 1d 02 2e d6 ac 43 69 …Ci
0090 - c2 5f dd 7d d1 be 55 0c-e7 ee d0 48 fc 96 92 67 ._.}…U…H…g

Start Time: 1514930644
Timeout   : 300 (sec)
Verify return code: 0 (ok)


Yes is succeeded.

Yes there is quite a few still around, you should drop us a line at somepoint


traceroute to (, 30 hops max, 60 byte packets
1 gateway.sunnydale ( 0.296 ms 0.240 ms 0.270 ms
2 ( 9.967 ms 9.961 ms 11.117 ms
3 ( 11.872 ms 11.867 ms 11.863 ms
4 ( 11.625 ms ( 11.958 ms ( 11.615 ms
5 ( 11.837 ms ( 11.969 ms ( 11.941 ms
6 ( 49.847 ms 49.671 ms 44.728 ms
7 ( 11.172 ms 11.129 ms 11.122 ms

Is it possible that the ACME client is trying to use IPv6 while the other tools are using IPv4? (Though I don’t think that would be likely to produce that particular socket error.)

I can disable IPv6 and try but its never given me issues before?

You could try

curl -4
curl -6

curl -6

“Mj6rGDKAscY”: “Adding random entries to the directory”,
“key-change”: “”,
“meta”: {
“terms-of-service”: “
“new-authz”: “”,
“new-cert”: “”,
“new-reg”: “”,
“revoke-cert”: “

curl -4

“key-change”: “”,
“meta”: {
“terms-of-service”: “
“new-authz”: “”,
“new-cert”: “”,
“new-reg”: “”,
“revoke-cert”: “”,
“zTDH_eJ3YOY”: “Adding random entries to the directory

Would it make a difference if my IPv4 and IPv6 address changed after the last renewal of the certificates over 90 days ago?

No, that shouldn’t have any effect.

@cpu, any theories on whether this is more of a client-side or more of a server-side problem?

Log File traceback:

2018-01-03 00:38:51,338:WARNING:certbot.renewal:Attempting to renew cert ( from /etc/letsencrypt/renewal/ produced an unexpected error: HTTPSConnectionPool(host=‘’, port=443): Read ti
med out. (read timeout=45). Skipping.
2018-01-03 00:38:51,338:DEBUG:certbot.renewal:Traceback was:
Traceback (most recent call last):
File “/opt/”, line 425, in handle_renewal_request
main.renew_cert(lineage_config, plugins, renewal_candidate)
File “/opt/”, line 743, in renew_cert
_get_and_save_cert(le_client, config, lineage=lineage)
File “/opt/”, line 80, in _get_and_save_cert
renewal.renew_cert(config, domains, le_client, lineage)
File “/opt/”, line 297, in renew_cert
new_certr, new_chain, new_key, _ = le_client.obtain_certificate(domains)
File “/opt/”, line 318, in obtain_certificate
File “/opt/”, line 66, in get_authorizations
self.authzr[domain] = self.acme.request_domain_challenges(domain)
File “/opt/”, line 213, in request_domain_challenges
typ=messages.IDENTIFIER_FQDN, value=domain), new_authzr_uri)
File “/opt/”, line 192, in request_challenges
response =, new_authz)
File “/opt/”, line 709, in post
return self._post_once(*args, **kwargs)
File “/opt/”, line 720, in _post_once
response = self._send_request(‘POST’, url, data=data, **kwargs)
File “/opt/”, line 630, in _send_request
response = self.session.request(method, url, *args, **kwargs)
File “/opt/”, line 488, in request
resp = self.send(prep, **send_kwargs)
File “/opt/”, line 609, in send
r = adapter.send(request, **kwargs)
File “/opt/”, line 499, in send
raise ReadTimeout(e, request=request)
ReadTimeout: HTTPSConnectionPool(host=‘’, port=443): Read timed out. (read timeout=45)

According to the log it connects to no problem at all only when it attempts to run the renew code is when it gets a timeout

Ok mounting the webroot on another machine with internet access via a vpn yields this result.

Plugins selected: Authenticator webroot, Installer None
Cert is due for renewal, auto-renewing…
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for
http-01 challenge for
Using the webroot path /mnt/www/ for all unmatched domains.
Waiting for verification…
Cleaning up challenges
Failed authorization procedure. (http-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching Timeout, (http-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching Timeout


files are being created on the webserver, but the remote server cannot connect to me.

Can you connect to Over IPv6? For me it opens a TCP connection and then dies shortly afterwards. seems to work well enough, but it redirects to the HTTPS site.

(The DNS servers look iffy, too, by the way.'s IPv4 address works but not the other 3 IPs.)

the site fails because of jquery is trying to go via 443 and the certificate is expired.

Domain only has 2 name servers, not 3 so whats strange can you tell me the ones you are seeing?

I was just downloading one URL with curl. The handshake (on IPv6) didn't get far enough for the certificate to be an issue.

It has two hostnames, each with two IP addresses.  (signed)  84700  A  (signed)  84701  AAAA  2001:44b8:4104:8000::100  (signed)  84700  A  (signed)  84701  AAAA  2001:44b8:4104:8000::200

Only the first IP is working.

Reset all the DNS records will try again later, seems to not have updated when i changed it a week or so ago.

hopefully this was the cause of the issues

OK tried one last thing I turned off SSL so only standard http would work and bam no issue,
looks like the certs will not always renew when too far expired.

or its just an amzing coinsidence

1 Like

That shouldn't be an issue, in and of itself. Let's Encrypt is tolerant of certificate issues when validating (perhaps ironically). The issue was that connecting to the site didn't work at all.

(I'm not sure what Apache does when an expired certificate causes OCSP stapling to fail, but I think it handles it well enough.)

Connecting to the site is still an issue, in fact.

Turning off the redirect to HTTPS just avoids the HTTPS problem, whatever it is.

1 Like

My gut instinct says this was a server-side problem (with @adam-themud’s server, not the ACME server) but I don’t have any compelling theories :frowning:

It sounds like the thread is resolved now. Very mysterious! I don’t understand why the machine was able to reach the directory endpoint reliably except during the renewal operation. Very strange!