Post request /acme/authz returned 404 No such authorization error

Weekly cron job failed to generate a certificate, rerunning the script worked.

My operating system is (include version):

Debian 10

I installed Certbot with (snap, OS package manager, pip, certbot-auto, etc):

snap certbot version 3.1.0

I ran this command and it produced this output:

/snap/bin/certbot certonly --standalone --csr /var/www/idcard-cert-automation/idcard.csr Unfortunately no output on syslog, seemed to be successful.

Certbot's behavior differed from what I expected because:

Didn't generate a cert

Here is a Certbot log showing the issue (if available):

2025-02-09 04:15:05,484:DEBUG:urllib3.connectionpool:https://acme-v02.api.letsencrypt.org:443 "POST /acme/authz/redacted/redacted HTTP/1.1" 404 106
2025-02-09 04:15:05,484:DEBUG:acme.client:Received response:
HTTP 404
Server: nginx
Date: Sun, 09 Feb 2025 04:15:05 GMT
Content-Type: application/problem+json
Content-Length: 106
Connection: keep-alive
Boulder-Requester: 111448996
Cache-Control: public, max-age=0, no-cache
Link: <https://acme-v02.api.letsencrypt.org/directory>;rel="index"
Replay-Nonce: VsUfN5awPDIyKlpqujBRa2b_SnNqn37wbBawgih0uloC5ab1XSQ

{
  "type": "urn:ietf:params:acme:error:malformed",
  "detail": "No such authorization",
  "status": 404
}
2025-02-09 04:15:05,485:DEBUG:certbot._internal.log:Exiting abnormally:
Traceback (most recent call last):
  File "/snap/certbot/4325/bin/certbot", line 8, in <module>
    sys.exit(main())
             ^^^^^^
  File "/snap/certbot/4325/lib/python3.12/site-packages/certbot/main.py", line 19, in main
    return internal_main.main(cli_args)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/snap/certbot/4325/lib/python3.12/site-packages/certbot/_internal/main.py", line 1873, in main
    return config.func(config, plugins)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/snap/certbot/4325/lib/python3.12/site-packages/certbot/_internal/main.py", line 1564, in certonly
    cert_path, chain_path, fullchain_path = _csr_get_and_save_cert(config, le_client)
                                            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/snap/certbot/4325/lib/python3.12/site-packages/certbot/_internal/main.py", line 1495, in _csr_get_and_save_cert
    cert, chain = le_client.obtain_certificate_from_csr(csr)
                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/snap/certbot/4325/lib/python3.12/site-packages/certbot/_internal/client.py", line 335, in obtain_certificate_from_csr
    orderr = self._get_order_and_authorizations(csr.data, best_effort=False)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/snap/certbot/4325/lib/python3.12/site-packages/certbot/_internal/client.py", line 479, in _get_order_and_authorizations
    orderr = self.acme.new_order(csr_pem)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/snap/certbot/4325/lib/python3.12/site-packages/acme/client.py", line 149, in new_order
    authorizations.append(self._authzr_from_response(self._post_as_get(url), uri=url))
                                                     ^^^^^^^^^^^^^^^^^^^^^^
  File "/snap/certbot/4325/lib/python3.12/site-packages/acme/client.py", line 309, in _post_as_get
    return self._post(*new_args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/snap/certbot/4325/lib/python3.12/site-packages/acme/client.py", line 370, in _post
    return self.net.post(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/snap/certbot/4325/lib/python3.12/site-packages/acme/client.py", line 743, in post
    return self._post_once(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/snap/certbot/4325/lib/python3.12/site-packages/acme/client.py", line 756, in _post_once
    response = self._check_response(response, content_type=content_type)
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/snap/certbot/4325/lib/python3.12/site-packages/acme/client.py", line 607, in _check_response
    raise messages.Error.from_json(jobj)
acme.messages.Error: urn:ietf:params:acme:error:malformed :: The request message was malformed :: No such authorization
2025-02-09 04:15:05,503:ERROR:certbot._internal.log:An unexpected error occurred:
2025-02-09 04:15:05,503:ERROR:certbot._internal.log:No such authorization

FYI this whole script has been running weekly over 2 years without problems. There have been two or three times similar thing has happened but I really haven't bothered to look into it until now.

Exact same error happened to me earlier this month for the first time. I run a cert renewal script from a cronjob which has been working fine for months. Recently, it started failing with this error, but succeeds when I run it manually.

Are you getting this specific "No such authorization" errors persistently?

Because according to the Let's Encrypt staff, as mentioned at https://community.letsencrypt.org/t/renew-using-certbot-certonly-asks-update-key-type-to-ecdsa/196889/3?u=osiris, this is most likely caused by database replica issues at Let's Encrypts side. And thus not a bug in Certbot.

Letsencrypt states you should retry, so why not provide user an option to set a delay and retry parameters between new order and identifier authorization retrieval?

Letsencrypt states you should retry

Where? I don't see the usual Retry-After header. It's probably not conveniently possible for Certbot to distinguish between the different urn:ietf:params:acme:error:malformed errors possible.

Just chiming in that I am seeing this error occasionally as well. It frequently happens when we are renewing multiple certs in succession. Essentially we have a script that checks to see if any of our certs are about to expire and to refresh the ones that need it. When two certs need to be refreshed in the same run(within ~30 seconds of each other), the second one always fails with this "no such authorization" error.

While I'd love it if certbot could retry on this failure automatically, it seems like something Let's Encrypt will need to fix. In the meantime we will implement retries in our automation.

There is definitely a known issue on the LetsEncrypt side that is caused by replication lag occurring between steps of the renewal process. One of their SREs called it "the 404 bug" in a community post so it's definitely a known issue.

I renew about 10-15 certificates a month on average and see this every other month or so, usually on a single random domain. I was quite surprised that certbot doesn't offer a delay or retry option, as I'm reasonably sure a short delay or a single retry would absorb this kind of failure quite well.