Automatic certificate issuance fails the authorization step and the error does not say why

The key thing to understand is who is doing the checking and from where. The authority is validating from its own servers, on the public internet, not from your machine. So "it works in my browser" tells you very little — your browser may be inside the network, cached, or using a different address.

What happens in an HTTP challenge:

1. The client asks for a certificate and receives a token.
2. It writes the token to a file under /.well-known/acme-challenge/ on your site.
3. The authority requests that exact URL over plain HTTP on port 80, from several locations.
4. It must receive the token, with no redirect to somewhere it cannot follow and no authentication in the way.

So the diagnostic is to fetch that URL yourself the way the authority does — from outside your network, over HTTP, following redirects, and watch what comes back. That single test identifies the failure in nearly every case.

The causes, ordered by how often I see them, given it worked before:

Port 80 is now closed or redirected. People harden a server, block port 80 or redirect everything to HTTPS in a way that breaks the challenge path. A redirect to HTTPS is fine and is followed; a redirect to a login page or a 404 is not.

A new proxy or CDN in front. Anything terminating connections ahead of your server has to pass the challenge path through. This is the single biggest cause of a renewal failing when issuance once worked.

Authentication in front of the site. A basic-auth prompt or an allow-list added later applies to the challenge path too. It must be excluded.

DNS has changed. The record now points somewhere else, or resolves differently from outside than inside. Split-horizon DNS makes this invisible locally.

Rate limits. Repeated failed attempts eventually earn a temporary block, which then masks the original error. Test with the staging environment while debugging — that is exactly what it is for.

For the DNS variant of the error — messages mentioning DNSSEC or a missing key — the failure is a layer below your web server and no amount of web configuration will fix it.

DNSSEC is signed DNS, and if the signatures are broken or a key was rotated without updating the delegation, a validating resolver gets no answer at all. The authority validates, so it sees nothing; a browser using a non-validating resolver may still work, which is why the site looks fine to you.

That mismatch is the tell. If your domain resolves for you and not for the authority, test it against a validating resolver and check the delegation records at your registrar rather than debugging the server.

One structural suggestion if this keeps happening: switch that domain to a DNS-based challenge.

It proves control by writing a record rather than serving a file, which means it does not care about port 80, proxies, redirects, authentication, or whether the site is even running. It is also the only option for a wildcard certificate and for a host with no public web server.

The cost is that your client needs credentials for your DNS provider, so scope that credential to the one zone if the provider allows it.