Why Does a Self-Hosted Certificate Renew Locally but Fail From the Internet?

Eva Wong

IceWhale author

Eva Wong is the Technical Writer and resident tinkerer at ZimaSpace. A lifelong geek with a passion for homelabs and open-source software, she specializes in translating complex technical concepts into accessible, hands-on guides. Eva believes that self-hosting should be fun, not intimidating. Through her tutorials, she empowers the community to demystify hardware setups, from building their first NAS to mastering Docker containers.

Why Does a Self-Hosted Certificate Renew Locally but Fail From the Internet?

A certificate can renew locally yet fail publicly when the ACME authority cannot reach or verify the challenge through the internet-facing path.

On a self-hosted NAS or home server, a local dry run may confirm that Certbot, acme.sh, or the reverse proxy can create challenge files and access its own configuration. Public issuance adds different requirements: authoritative DNS must point to the correct address, the selected IPv4 or IPv6 path must be reachable, the router and firewall must deliver the validation request, and the reverse proxy must serve the exact challenge token before redirects or application routes interfere.

Separate Local Client Success From Public Domain Validation

Read the renewal log and identify what actually succeeded. A local configuration check, certificate parsing test, webroot write, or staging request does not prove that an external certificate authority reached the home server.

A common Nginx Proxy Manager case identifies public port 80 reachability as the first requirement to verify when an HTTP challenge fails despite a working local proxy interface.

Record the challenge type, hostname, validation URL, resolved address, and exact CA error. Continue only from the first external failure—DNS lookup, TCP connection, HTTP status, token mismatch, or secondary validation—instead of repeatedly forcing renewal without new evidence.

Compare Authoritative A and AAAA Records With the Real Server Path

Query every certificate hostname through authoritative DNS and record its A and AAAA answers. Compare them with the router’s current public IPv4, the server’s reachable IPv6 address, and the proxy that actually serves the challenge.

A Virtualmin renewal case succeeded only after removing a published AAAA record that sent validation to a broken IPv6 path, demonstrating how a broken AAAA validation path can override an otherwise healthy IPv4 setup.

If an address family is not fully reachable, remove that record temporarily or repair its firewall, routing, listener, and proxy path. Also verify that all authoritative nameservers return the same current records before retrying issuance.

Test the Exact HTTP Challenge URL From Outside the Home

For HTTP-01, place a harmless test file under the configured /.well-known/acme-challenge/ path and request it from mobile data or another external network using the certificate hostname over HTTP.

A Home Assistant self-hosting report shows how an ISP-blocked HTTP challenge prevents HTTP validation even when the service itself works locally.

The external request must reach the correct token without authentication, a captive page, a router login, an application 404, or a redirect to an unreachable destination. If TCP port 80 never opens, inspect the ISP, CGNAT, router forward, host firewall, and proxy listener before changing the ACME client.

Featured

ZimaCube 2 Personal Cloud Home NAS

ZimaCube2

Verify the Reverse Proxy and Webroot Serve the Same Token

Compare the token path written by the ACME client with the filesystem or temporary responder used by the public virtual host. Containers, bind mounts, and separate proxy networks can make the client write to one directory while NGINX or Caddy serves another.

Inspect the proxy access log during one external challenge request. A request that arrives but returns 404 points to route or webroot mismatch; 401 or 403 points to authentication or filtering; 502 points to an unnecessary upstream dependency in the challenge path.

Give the challenge location priority over normal application routing and preserve the hostname. Keep redirects simple and verify them externally; do not send the token through a backend application that can be offline during renewal.

Check CGNAT, Firewalls, and Multi-Location Reachability

Compare the router WAN address with the public IPv4 address and confirm the validation port is reachable from more than one external network. A local NAT-loopback test can succeed even when unsolicited internet traffic never reaches the router.

Certificate authorities increasingly validate from multiple network locations to reduce routing attacks. Research on multiple validation vantage points explains why a path reachable from one country, ISP, or test service may still fail broader validation.

Remove geoblocking, country filters, temporary deny rules, and rate limits from the narrow challenge path during validation. If the home connection is behind CGNAT or the ISP blocks the required port, use DNS-01 or an outbound validation design instead of weakening unrelated firewall rules.

Choose the Challenge Type That Matches the Network Boundary

Keep HTTP-01 when public DNS is correct and port 80 can reliably reach the challenge responder. Use DNS-01 when inbound reachability is unavailable, wildcard certificates are required, or the service must remain private.

The ZimaSpace article on how CGNAT blocks inbound validation helps identify when changing the ACME method is more appropriate than repairing the local proxy.

The fix is complete only when a forced renewal succeeds through the production CA, the new certificate is deployed to the active proxy, external clients receive the new serial and expiry date, and an unattended renewal test works without manual port or DNS changes.