A quick question for a wider audience, I am seeing this from several domains on several servers in the last few days. Very long term deployments and stable configurations.
Are others seeing "urn:ietf:params:acme:error:connection" ... "Timeout after connect (your server may be slow or overloaded)" ? Appear being reported by https://acme-v02.api.letsencrypt.org (so far)
This has come up for us too, similarly out of the blue for what has been a stable setup.
The certificates that have begun to fail validation have HTTP to HTTPS redirects. The HTTP request from the validation server completes, getting a 301 response, but we never see the redirected HTTPS request come in. Interestingly, dry runs with the --staging environment flag do work, both HTTP and HTTPS.
We have had upstream networking changes in the last few weeks which is what we're exploring now, but it stands out to me that HTTP works and HTTPS does not.
All of the missing HTTPS requests were expected from validation servers in 23.178.112.0/24.
We can likely work around this by skipping the HTTP→HTTPS redirect, which is what we'll do if this hasn't come right in the next few days. 
I've checked over the configurations and logs and am seeing the same as you describe tomryder-inspirenet, the HTTP->HTTPS (301/302) subsequent requests aren't arriving.
First thing that comes to mind is an accidental outbound firewall issue on the LE outbound servers (80=Accept, 443=Whoops).
That is not enough info to work with. There is a wide variety of problems that cause that.
If it only happens after redirect a common cause is if you have IPv6 AAAA records for your domain that don't work properly. Let's Encrypt will fallback/retry with IPv4 but only for the initial request - not the redirect.
@tomryder-inspirenet please start a new thread and answer the questions on the form you will be shown.
@jc-rimu Same for you but please answer as much as you can in this thread. It is highly unlikely all such HTTPS requests from Let's Encrypt would be failing. LE issues over 7 million certs per day and a failure like that would be triggering vast alerts in their internal monitoring.
Below is the form. Heck, even an actual domain name would give us something to work with.
=========================================================
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. crt.sh | example.com), 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:
It produced this output:
My web server is (include version):
The operating system my web server runs on is (include version):
My hosting provider, if applicable, is:
I can login to a root shell on my machine (yes or no, or I don't know):
I'm using a control panel to manage my site (no, or provide the name and version of the control panel):
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):
I posted about a generic issue that I'm seeing across domains/servers, within 30 minutes there was confirmation from tomryder-inspirenet , and his information was excellent.
a common cause is if you have IPv6 AAAA records for your domain that don't work properly
No, not in what I'm observing. A helpful suggestion though.
Thank you, I have created a new thread with the templated information you requested: HTTPS connection failures (timeouts) from validation servers
Sure, but, often times the same symptoms are from very different causes. And, different posters have different skills so the debug steps vary.
Even the full error message would help. Let's Encrypt has 5 validation centers. The primary center must succeed but then the other 4 secondary centers are activated. The error message differs and helps isolate problems.
This is the LE response for a new certificate earlier today (it failed in the same way as the renews per above). Of the information I can share this one is not too private. The well-known file is still present, you can curl that and see there is no issue requesting the file. The domain name neoqura.com has since been redirected elsewhere (try troubleshooting it now).
$ curl https://acme-v02.api.letsencrypt.org/acme/chall/34647863/624189828776/KRWHlA
{
"type": "http-01",
"url": "https://acme-v02.api.letsencrypt.org/acme/chall/34647863/624189828776/KRWHlA",
"status": "invalid",
"validated": "2025-12-07T21:24:26Z",
"error": {
"type": "urn:ietf:params:acme:error:connection",
"detail": "103.248.176.180: Fetching https://mypanel.co.nz/.well-known/acme-challenge/B8d-_d6Nra74xvyegNeciLrpM-sO-xW5f4DehCTjza8: Timeout after connect (your server may be slow or overloaded)",
"status": 400
},
"token": "B8d-_d6Nra74xvyegNeciLrpM-sO-xW5f4DehCTjza8",
"validationRecord": [
{
"url": "http://neoqura.com/.well-known/acme-challenge/B8d-_d6Nra74xvyegNeciLrpM-sO-xW5f4DehCTjza8",
"hostname": "neoqura.com",
"port": "80",
"addressesResolved": [
"103.248.176.140"
],
"addressUsed": "103.248.176.140"
},
{
"url": "https://mypanel.co.nz/.well-known/acme-challenge/B8d-_d6Nra74xvyegNeciLrpM-sO-xW5f4DehCTjza8",
"hostname": "mypanel.co.nz",
"port": "443",
"addressesResolved": [
"103.248.176.180"
],
"addressUsed": "103.248.176.180"
}
]
}
*(don't try trouble shooting it now...)
On one of our affected servers I set the MTU to 1280 and the renew worked. This is good debug information for the Let's Encrypt team. I have reverted that server's MTU as a workaround is not a solution.
Thanks MaxHearnden for the suggestion and tomryder-inspirenet for doing an initial try with that HTTPS connection failures (timeouts) from validation servers - #11 by tomryder-inspirenet .
I have repeated this on all affected servers. Reduce MTU to 1280 -> LE renew -> MTU reverted to 1500. This MTU workaround is not a solution, escalation to the Let's Encrypt team absolutely required.
In this thread are two independent hosting providers in New Zealand that are affected.
This Let's Encrypt issue is in its day 5th day of being present (Thurs -> Mon so far), I allowed the weekend to see if any transient issue sorted itself out before raising it here.
The other thread for reference: HTTPS connection failures (timeouts) from validation servers
This is probably a good question for @mcpherrinm because there were fairly recent changes to boulder along that theme.
Thanks for tagging people in the know. I'm not sure what boulder means, can you tldr that for me a little bit please?
Boulder is the software Let's Encrypt use to run their certificate ACME API and issuance GitHub - letsencrypt/boulder: An ACME-based certificate authority, written in Go.
Hi JamesLE
We have another server affected and more failures queued to deal with, via the MTU workaround, until the problem is resolved.
The MTU here is 1500, as it should be.
An automated renewal attempt failed:
curl https://acme-v02.api.letsencrypt.org/acme/chall/34647863/624645132576/KGXRBA
{
"type": "http-01",
"url": "https://acme-v02.api.letsencrypt.org/acme/chall/34647863/624645132576/KGXRBA",
"status": "invalid",
"validated": "2025-12-08T20:38:10Z",
"error": {
"type": "urn:ietf:params:acme:error:connection",
"detail": "103.248.176.180: Fetching https://mypanel.co.nz/.well-known/acme-challenge/LS3L9OMtBqe_GAiyntUWj8u8J_qtpqWjujKsMppCR9M: Timeout after connect (your server may be slow or overloaded)",
"status": 400
},
"token": "LS3L9OMtBqe_GAiyntUWj8u8J_qtpqWjujKsMppCR9M",
"validationRecord": [
{
"url": "http://webmail.interspeed.co.nz/.well-known/acme-challenge/LS3L9OMtBqe_GAiyntUWj8u8J_qtpqWjujKsMppCR9M",
"hostname": "webmail.interspeed.co.nz",
"port": "80",
"addressesResolved": [
"103.248.176.140"
],
"addressUsed": "103.248.176.140"
},
{
"url": "https://mypanel.co.nz/.well-known/acme-challenge/LS3L9OMtBqe_GAiyntUWj8u8J_qtpqWjujKsMppCR9M",
"hostname": "mypanel.co.nz",
"port": "443",
"addressesResolved": [
"103.248.176.180"
],
"addressUsed": "103.248.176.180"
}
]
}
Manually attempting renewal again fails, a tcpdump with that information. pcap is no good here as I couldn't predict which LE server may initiate the incoming request..
tcpdump of Let's Encrypt exchange:
# tcpdump -i any port 80 or port 443 | grep letsencrypt
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
10:24:33.698494 IP outbound2m.letsencrypt.org.52089 > enterprise.rimu.net.nz.https: Flags [S], seq 2363495615, win 64240, options [mss 1436,sackOK,TS val 1765086036 ecr 0,nop,wscale 7], length 0
10:24:33.698570 IP enterprise.rimu.net.nz.https > outbound2m.letsencrypt.org.52089: Flags [S.], seq 69855016, ack 2363495616, win 65160, options [mss 1460,sackOK,TS val 4208317154 ecr 1765086036,nop,wscale 7], length 0
10:24:33.955207 IP outbound2m.letsencrypt.org.52089 > enterprise.rimu.net.nz.https: Flags [.], ack 1, win 502, options [nop,nop,TS val 1765086293 ecr 4208317154], length 0
10:24:33.955482 IP outbound2m.letsencrypt.org.52089 > enterprise.rimu.net.nz.https: Flags [P.], seq 1:1502, ack 1, win 502, options [nop,nop,TS val 1765086293 ecr 4208317154], length 1501
10:24:33.955736 IP enterprise.rimu.net.nz.https > outbound2m.letsencrypt.org.52089: Flags [.], ack 1502, win 498, options [nop,nop,TS val 4208317411 ecr 1765086293], length 0
10:24:33.960475 IP enterprise.rimu.net.nz.https > outbound2m.letsencrypt.org.52089: Flags [P.], seq 1:2849, ack 1502, win 501, options [nop,nop,TS val 4208317415 ecr 1765086293], length 2848
10:24:33.960500 IP enterprise.rimu.net.nz.https > outbound2m.letsencrypt.org.52089: Flags [P.], seq 2849:3151, ack 1502, win 501, options [nop,nop,TS val 4208317415 ecr 1765086293], length 302
10:24:34.217106 IP outbound2m.letsencrypt.org.52089 > enterprise.rimu.net.nz.https: Flags [.], ack 1, win 502, options [nop,nop,TS val 1765086554 ecr 4208317411,nop,nop,sack 1 {2849:3151}], length 0
10:24:34.287573 IP enterprise.rimu.net.nz.https > outbound2m.letsencrypt.org.52089: Flags [.], seq 1:1425, ack 1502, win 501, options [nop,nop,TS val 4208317743 ecr 1765086554], length 1424
10:24:35.071570 IP enterprise.rimu.net.nz.https > outbound2m.letsencrypt.org.52089: Flags [.], seq 1:1425, ack 1502, win 501, options [nop,nop,TS val 4208318527 ecr 1765086554], length 1424
10:24:36.643552 IP enterprise.rimu.net.nz.https > outbound2m.letsencrypt.org.52089: Flags [.], seq 1:1425, ack 1502, win 501, options [nop,nop,TS val 4208320099 ecr 1765086554], length 1424
10:24:39.903546 IP enterprise.rimu.net.nz.https > outbound2m.letsencrypt.org.52089: Flags [.], seq 1:1425, ack 1502, win 501, options [nop,nop,TS val 4208323359 ecr 1765086554], length 1424
10:24:43.959427 IP outbound2m.letsencrypt.org.52089 > enterprise.rimu.net.nz.https: Flags [F.], seq 1502, ack 1, win 502, options [nop,nop,TS val 1765096293 ecr 4208317411,nop,nop,sack 1 {2849:3151}], length 0
10:24:43.959911 IP enterprise.rimu.net.nz.https > outbound2m.letsencrypt.org.52089: Flags [F.], seq 3151, ack 1503, win 501, options [nop,nop,TS val 4208327415 ecr 1765096293], length 0
10:24:44.705490 IP outbound2m.letsencrypt.org.52089 > enterprise.rimu.net.nz.https: Flags [F.], seq 1502, ack 1, win 502, options [nop,nop,TS val 1765097039 ecr 4208317411,nop,nop,sack 1 {2849:3151}], length 0
10:24:44.705532 IP enterprise.rimu.net.nz.https > outbound2m.letsencrypt.org.52089: Flags [.], ack 1503, win 501, options [nop,nop,TS val 4208328160 ecr 1765097039,nop,nop,sack 1 {1502:1503}], length 0
10:24:46.303558 IP enterprise.rimu.net.nz.https > outbound2m.letsencrypt.org.52089: Flags [.], seq 1:1425, ack 1503, win 501, options [nop,nop,TS val 4208329759 ecr 1765097039], length 1424
10:24:56.799591 IP enterprise.rimu.net.nz.https > outbound1h.letsencrypt.org.60947: Flags [.], seq 1804985597:1804987021, ack 3641183713, win 501, options [nop,nop,TS val 3203873114 ecr 2840456505], length 1424
10:24:58.847554 IP enterprise.rimu.net.nz.https > outbound2m.letsencrypt.org.52089: Flags [.], seq 1:1425, ack 1503, win 501, options [nop,nop,TS val 4208342303 ecr 1765097039], length 1424
# tcptraceroute outbound2m.letsencrypt.org
Selected device ens12, address 103.248.176.180, port 56715 for outgoing packets
Tracing the path to outbound2m.letsencrypt.org (23.178.112.212) on TCP port 80 (http), 30 hops max
1 103.248.176.2 0.387 ms 0.281 ms 0.350 ms
2 10.70.11.26 0.166 ms 0.149 ms 0.148 ms
3 as4826.auckland.megaport.com (43.243.22.18) 1.568 ms 1.295 ms 1.345 ms
4 static-41.75.255.49.in-addr.VOCUS.net.au (49.255.75.41) 2.107 ms 1.800 ms 1.736 ms
5 198.41.236.39 1.620 ms 0.921 ms 0.721 ms
6 172.69.0.33 0.696 ms 0.648 ms 0.683 ms
7 172.69.0.33 0.814 ms 0.784 ms 0.744 ms
8 172.69.0.33 0.779 ms 0.709 ms 0.858 ms
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
LE staff can perform tests to this as it is still a valid URL:
$ curl https://mypanel.co.nz/.well-known/acme-challenge/LS3L9OMtBqe_GAiyntUWj8u8J_qtpqWjujKsMppCR9M
Footnote: Let's Encrypt is fantastic. In the real world issues occur and a time buffer is vital to resolve issues. The industry push for shorter certificate lifespans creates less time for issues to be addressed and that is unwise.
Statuses for New Zealand Internet posted here: HTTPS connection failures (timeouts) from validation servers - #22 by Bruce5051
Hi @JamesLE & @mcpherrinm
$ curl https://acme-v02.api.letsencrypt.org/acme/chall/34647863/625234762006/Bavihg
{
"type": "http-01",
"url": "https://acme-v02.api.letsencrypt.org/acme/chall/34647863/625234762006/Bavihg",
"status": "invalid",
"validated": "2025-12-10T02:40:41Z",
"error": {
"type": "urn:ietf:params:acme:error:connection",
"detail": "103.248.176.180: Fetching https://mypanel.co.nz/.well-known/acme-challenge/XznWmtJl-f7d1lvnK3wztOPSfH-iq_s5SlbCgR85w0g: Timeout after connect (your server may be slow or overloaded)",
"status": 400
},
"token": "XznWmtJl-f7d1lvnK3wztOPSfH-iq_s5SlbCgR85w0g",
"validationRecord": [
{
"url": "http://webmail.interspeed.co.nz/.well-known/acme-challenge/XznWmtJl-f7d1lvnK3wztOPSfH-iq_s5SlbCgR85w0g",
"hostname": "webmail.interspeed.co.nz",
"port": "80",
"addressesResolved": [
"103.248.176.140"
],
"addressUsed": "103.248.176.140"
},
{
"url": "https://mypanel.co.nz/.well-known/acme-challenge/XznWmtJl-f7d1lvnK3wztOPSfH-iq_s5SlbCgR85w0g",
"hostname": "mypanel.co.nz",
"port": "443",
"addressesResolved": [
"103.248.176.180"
],
"addressUsed": "103.248.176.180"
}
]
}
You can test requests to this URL it is still valid:
https://mypanel.co.nz/.well-known/acme-challenge/XznWmtJl-f7d1lvnK3wztOPSfH-iq_s5SlbCgR85w0g
I saw successful renewals today on a server (MTU 1500) that has been affected.
Yes, it seems to be working now:
webhost19:~$ sudo certbot certonly --config-dir=/etc/letsencrypt/config-alt --cert-name=webhost19.inspire.net.nz_test --domain=webhost19.inspire.net.nz --webroot --webroot-path=/var/www/webhost19.inspire.net.nz
…
Successfully received certificate.
…