03 / FIELD NOTES

Why a certificate request fails

Check DNS, port 80 reachability, and CDN proxying before retrying a Let’s Encrypt request.

Why this way

The default HTTP-01 challenge asks Let’s Encrypt to fetch a file from http://YOUR_DOMAIN/ on port 80. It fails when DNS points elsewhere, port 80 is blocked, or a CDN answers instead of your server.

When to use

Nginx Proxy Manager or Zoraxy reports an error when requesting a certificate.

When not to

Do not retry in a loop. Let’s Encrypt rate-limits repeated failures for the same domain.

Prerequisites

Replace example.com with your domain
dnsutils for dig

Steps

Does DNS point to this server?

Read-only

DOMAIN=example.com
dig +short A "$DOMAIN"
curl -4 -s https://api.ipify.org; echo

Expect: The two IPs must match. A different IP means DNS is not updated yet, or a CDN proxy (such as the orange cloud on Cloudflare) is on.

Is port 80 served by the proxy?

Read-only

ss -lntp | grep -E ':(80|443) '
curl -sI "http://$DOMAIN/" | head -n 1

Expect: docker-proxy should own 80 and 443. Any HTTP status line means port 80 is reachable.

What it changes

Read-only. If DNS and port 80 are fine, check the provider security group for TCP 80, then retry once.

A port you cannot reach from outside

Sources

Let’s Encrypt: challenge types ↗

{
  "slug": "cert-failed",
  "risk": "safe",
  "tags": [
    "https",
    "dns",
    "ports",
    "nginx"
  ],
  "updated": "2026-10-30",
  "pathIndex": null,
  "why": "The default HTTP-01 challenge asks Let’s Encrypt to fetch a file from http://YOUR_DOMAIN/ on port 80. It fails when DNS points elsewhere, port 80 is blocked, or a CDN answers instead of your server.",
  "steps": [
    {
      "command": "DOMAIN=example.com\ndig +short A \"$DOMAIN\"\ncurl -4 -s https://api.ipify.org; echo",
      "risk": "safe"
    },
    {
      "command": "ss -lntp | grep -E ':(80|443) '\ncurl -sI \"http://$DOMAIN/\" | head -n 1",
      "risk": "safe"
    }
  ]
}