Certificate validation fails: port 80, redirects, DNS challenges and rate limits

What the HTTP challenge needs

The usual challenge asks the certificate authority to fetch a token from your server over plain HTTP on port 80. Let's Encrypt documents that this port cannot be changed, that the request may follow up to ten redirects to http or https on ports 80 or 443, and that the certificate on an https target is not verified during the redirect. So the validation fails when port 80 is closed by a firewall, when a redirect sends the request to a different port, when the name resolves to a different machine than the one holding the token, or when the web server answers the challenge path with an error. Many servers fail after someone hardens the firewall to allow only 443.

• Port 80 must reach the machine that will answer the challenge.
• A redirect to an unusual port breaks validation.
• The DNS record must point at the server that holds the token.

Wildcards and the DNS challenge

A wildcard certificate cannot be validated with the HTTP challenge. It needs the DNS challenge, which proves control by publishing a record under the domain's challenge name. Renewal should be automatic, so this only makes sense if your DNS provider has an API a tool can call, and Let's Encrypt warns that keeping broad API credentials on a web server is risky. The documented alternative is to delegate the challenge name to a dedicated zone, so the credentials only affect that zone. If you do not need a wildcard, listing the specific hostnames and using the HTTP challenge is simpler.

• Wildcard names need the DNS challenge.
• Limit the API credentials to the narrowest zone.
• Specific hostnames with the HTTP challenge avoid the issue.

Testing safely: use staging

The production certificate authority has limits designed to stop abuse, and a person debugging can hit them. A validation that fails five times for the same name on the same account within an hour blocks further attempts until slots refill, one every twelve minutes. A longer-running limit exists for many consecutive failures. Separately, no more than five certificates for exactly the same set of names can be issued in seven days, which people hit by deleting and recreating configuration while troubleshooting. Let's Encrypt tells testers to use the staging environment, which has much higher limits, and certbot's dry run does exactly that.

• Debug with the dry run and the staging environment.
• Wait for limit slots to refill rather than changing accounts.
• Adding a name to the set changes the exact-set limit, but is not a fix for a broken challenge.

Check from outside, in order

Work from the outside in. Does the name resolve to the server? Does port 80 accept a connection from a network that is not yours? Does a request to the challenge path return a plain answer, or a redirect, or an error? Is a CDN in front changing the request? Each question has a cheap test. Change one thing at a time and re-run the dry run, since each run is a cheap, safe test against staging. A guess that opens port 80 to everything is rarely necessary; the challenge only needs the one path.

• Resolve the name and compare with the server's address.
• Test port 80 from outside.
• Request the challenge path and read the exact response.

When this becomes a paid job

The fixed renewal repair covers one server and up to three hostnames on one certificate. It finds which of these causes applies, makes the smallest change, proves renewal with the dry run and the served certificate, and sets up an outside alert. A server with a control panel that manages the certificate is a different fixed job. Wildcard setups that need DNS provider access are quoted separately, and none of this is a guarantee that every future renewal will succeed.