Hi,
We provide a service that orders certificates from Let’s Encrypt. We use the Lego library for ACME operations.
We have end-to-end tests that cover our certificate ordering flows and run daily. Today, these tests started failing, although both the tests and the service code are old and were not changed recently.
We are seeing errors like:
acme: error: 404 :: POST :: https://acme-v02.api.letsencrypt.org/acme/authz/182296030/715412488706 :: urn:ietf:params:acme:error:malformed :: No such authorization
and:
acme: error: 404 :: POST :: https://acme-v02.api.letsencrypt.org/acme/cert/0621af278f8b6902e060999271f73fb21de2/1 :: urn:ietf:params:acme:error:malformed :: Certificate not found
or
acme: error: 404 :: POST :: https://acme-v02.api.letsencrypt.org/acme/chall/182296030/715414421746/W_m1UQ :: urn:ietf:params:acme:error:malformed :: No such challenge
We also tried to isolate the issue outside of our service and the Lego library.
When we run the following command from the terminal several times, using the same URL:
curl -v https://acme-v02.api.letsencrypt.org/acme/chall/182296030/715456667006/lECofA
the result is not consistent. Sometimes the request succeeds, and sometimes the same URL returns 404 .
So it looks like this is not only a Lego/client-side issue. The same ACME challenge URL appears to randomly return 404 when called directly.
Could this indicate an issue with replication/cache/state between Let’s Encrypt servers, or is there some expected behavior that could explain intermittent 404 responses for the same authorization/challenge/certificate URL?
Any guidance would be appreciated.
We are getting same errors since today.
"Dehydrated" Client shows also errors with 404 for cert creation:
+ Signing domains...
+ Generating private key...
+ Generating signing request...
+ Requesting new certificate order from CA...
+ ERROR: An error occurred while sending post-request to https://acme-v02.api.letsencrypt.org/acme/order/106484/517659422496 (Status 404)
Details:
HTTP/2 404
server: nginx
date: Wed, 03 Jun 2026 08:57:08 GMT
content-type: application/problem+json
content-length: 113
cache-control: public, max-age=0, no-cache
link: <https://acme-v02.api.letsencrypt.org/directory>;rel="index"
replay-nonce: nZyQ48DWmlLb_gihNrp9DIohgsShDr4_j5c_XXoZbw3fOWSfbTU
{
"type": "urn:ietf:params:acme:error:malformed",
"detail": "No order for ID 517659422496",
"status": 404
}
EXPECTED value GOT EOF
We got the same spike of 404 responses on multiple requests, mostly on get-authorization endpoint
Same kinds of errors here.
Details:
HTTP/1.0 200 Connection Established
HTTP/2 404
server: nginx
date: Wed, 03 Jun 2026 09:13:08 GMT
content-type: application/problem+json
content-length: 106
boulder-requester: 1270118326
cache-control: public, max-age=0, no-cache
link: https://acme-v02.api.letsencrypt.org/directory;rel="index"
replay-nonce: nZyQ48DWFi8DeaPiU9CkWxvwhIqD6mrbv7hZVdqtHBoccn1aj9A
{
"type": "urn:ietf:params:acme:error:malformed",
"detail": "No such authorization",
"status": 404
}
EXPECTED value GOT EOF
We are seeing the same issue from our ACME client today.
The first occurrence on our side was at around 07:54 local time (Europe/Vienna, CEST), and since then we have seen the error dozens of times across different domains/orders. There were no deployment or infrastructure changes on our side.
Typical flow in our logs:
new-order succeeds- Let’s Encrypt returns fresh
authz URLs
- immediately afterwards, one of those just-returned authorization or challenge URLs fails with HTTP 404
- the ACME error is either:
urn:ietf:params:acme:error:malformed
detail: No such authorization
status: 404
or:
urn:ietf:params:acme:error:malformed
detail: No such challenge
status: 404
In at least one case, the first authorization of an order could be processed successfully, while the second authorization from the same freshly created order returned No such authorization only seconds later.
This does not look like a normal HTTP-01 validation failure on our side. The challenge token is written correctly and the failure happens when accessing the ACME authorization/challenge resource itself, not when Let’s Encrypt validates the HTTP challenge URL.
So this looks very similar to the behavior described here: freshly created ACME resources are intermittently not found shortly afterwards.
Same started to happen for us since ~05:35 GMT:
- No such challenge
- Failed to find authorization for domain
same error. i am using pdns-acme and dns-01 challenge for generating certs. from about 1hour ago i get such as 404 errors 
No such authorization
No order for ID 517....
Not Found
We are seeing this too, and some urn:ietf:params:acme:error:connection errors mixed in.
First uptick ~3 hours ago. Appears on 100% of requests now.
Appears to be some kind of issue on LE's end.
Its not an issue you can retry your way out of either, 20 retries (one every 2s)
"Force renewal requested for b.ssl-test.* (1676)",
"Retrying ACME order reload for https://acme-v02.api.letsencrypt.org/acme/order/*/* after transient authz lookup failure (attempt 2/20)",
"Retrying ACME order finalize for https://acme-v02.api.letsencrypt.org/acme/order/*/* after transient authz lookup failure (attempt 20/20)",
"Exception during certificate request: [malformed] The request message was malformed: No order for ID * (on request \"POST https://acme-v02.api.letsencrypt.org/acme/finalize/*/*\")",
It is > imagineable < , that it's related to the latest nginx exploit patches.. may be it's a nginx meltdown.
As servers do not show any unusual response time delays, I suspect this is the issue ... 
Hope someone at LE notices this thread in time — the status page still shows everything green.
Let's Encrypt has extensive monitoring for these kinds of issues, so if it's widespread (as is apparent from these reports) they are seeing this. However, it's not even 6am in the US, so please be patient.
My money would be on a database replication issue, but we'll need to wait and see.
@lestaff just pinging for increased awareness, a degraded performance status message would probably be helpful if you're investigating.
I'm having the same 404 issue. Shouldn't it be posted on the status page?
Same here with 2 different systems / providers (one AWS, one Google cloud). Seems a server problem to me.
I have verified and double checked from different locations , using different clients, using different accounts and for different domains that this error can be reproduced 100% of time and this is definitely Lets Encrypt server issue.
Update: The issue seems to be resolved now, and our tests are passing again.
Could you please share what caused the intermittent 404 responses?
Also, do you have any recommendations for clients to handle this kind of situation, or is there anything planned on the Let’s Encrypt side to prevent similar issues in the future?
I have contacted LE staff to look into things. (2)
This problem was solved for us too
My only advice to others is to not touch anything until it fixes itself.