Nginx Proxy Manager / Troubleshooting
Nginx Proxy Manager Let’s Encrypt Certificate Renewal Fails
Separate HTTP-01 reachability from DNS-01 credential or plugin failures on Nginx Proxy Manager 2.15.x, then respect exact ACME errors and rate limits instead of deleting certificates or data.
Nginx Proxy Manager uses Certbot to issue and renew Let’s Encrypt certificates. For DNS challenges it installs the provider-specific Certbot DNS plugin, and the official NPM documentation warns that plugin dependency compatibility can vary.[3]
Let’s Encrypt validates HTTP-01 only on port 80, while DNS-01 validates a TXT record under _acme-challenge and depends on an automated DNS API path. The two challenge types therefore need different evidence; a working HTTPS site on port 443 does not prove that HTTP-01 renewal can succeed.[4]
Applicability
- Products
- Nginx Proxy Manager
- Scope
- For Nginx Proxy Manager 2.15.1 / the 2.15.x line when an existing Let’s Encrypt certificate fails a manual or scheduled renewal. NPM documents that it uses Certbot for issuance and renewal. The 2.15.0 line moved to a newer Debian/Certbot/Python base and warns that DNS plugins can need dependency adjustments. This page does not cover first-time NPM setup, generic TLS serving problems, or a certificate that renewed successfully but is not the one being served.[1][2][3]
- Last verified
Symptoms
Quick diagnosis
Read the renewal error and identify HTTP-01 versus DNS-01 before touching certificates, DNS, or firewall rules.
Capture the exact NPM/Certbot renewal error
Read the NPM container logs and the renewal failure details before changing any certificate, DNS record, firewall rule, or plugin. NPM’s own guidance for DNS plugin problems starts with checking the container logs for Certbot or Python package errors.[3]
Identify HTTP-01 versus DNS-01
Determine how this certificate is validated. HTTP-01 requires Let’s Encrypt to fetch the challenge over port 80; DNS-01 requires the expected TXT record and an automated DNS provider path. Do not apply a port-80 fix to a DNS-01 certificate or a DNS-token fix to HTTP-01.[4][3]
Do not delete and recreate certificates as a diagnostic shortcut
Preserve the existing certificate and its renewal evidence. Repeated new orders can consume Let’s Encrypt rate limits and can remove evidence about the actual renewal failure.[5]
Interactive troubleshooter
Your answers stay in this browser tab. The tool does not connect to your systems or send diagnostic results.
Guided check / step 1
Safe diagnostic guidanceIs this renewal failure for an existing Let’s Encrypt certificate?
This page starts only after an existing NPM certificate fails renewal.[3]
Read the complete diagnostic tree without using the controls
- Is this renewal failure for an existing Let’s Encrypt certificate?
This page starts only after an existing NPM certificate fails renewal.[3]
- Yes — existing certificate renewal fails → Which ACME challenge does this certificate use?
- No — first issuance or different TLS problem → Different diagnosis
- Which ACME challenge does this certificate use?
HTTP-01 and DNS-01 have different validation paths and must be diagnosed separately.[4][3]
- HTTP-01 → Can the public domain reach the intended challenge path on port 80?
- DNS-01 → What does the DNS-01 evidence show?
- Unsure → Collect exact NPM and Certbot evidence
- Can the public domain reach the intended challenge path on port 80?
Let’s Encrypt performs HTTP-01 on port 80; 443 alone does not satisfy this check.[4]
- Yes — port 80 path is proven → Does the exact ACME error report a Let’s Encrypt rate limit?
- No — port 80 path fails → HTTP-01 public port-80 path is broken
- What does the DNS-01 evidence show?
Use the provider/Certbot log evidence to separate credential failure from plugin dependency failure.[3][4]
- Provider credential/API error → DNS-01 provider authentication or API path failed
- Certbot/Python plugin error → NPM Certbot DNS plugin dependency failed
- No credential or plugin error → Does the exact ACME error report a Let’s Encrypt rate limit?
- Unsure → Collect exact NPM and Certbot evidence
- Does the exact ACME error report a Let’s Encrypt rate limit?
Rate-limit responses include a retry boundary; repeated attempts are not a fix.[5]
- Yes — rate limited → Let’s Encrypt rate limit is active
- No — no current confirmed branch → Collect exact NPM and Certbot evidence
- Different diagnosis
First issuance and post-renewal serving problems are outside this page.[3]
- HTTP-01 public port-80 path is broken
Restore only the proven public port-80 path to the intended NPM challenge endpoint.[4]
- DNS-01 provider authentication or API path failed
Correct only the proven provider credential/API boundary and keep secrets narrowly scoped.[4][3]
- NPM Certbot DNS plugin dependency failed
Use the provider plugin definition and exact Certbot/Python error; NPM documents dependency compatibility as a known boundary.[3][2]
- Let’s Encrypt rate limit is active
Honor the retry time and stop generating more production attempts until the underlying validation issue is corrected.[5]
- Collect exact NPM and Certbot evidence
Preserve the certificate and logs and stop before historical or destructive trial-and-error.[3][1]
Detailed diagnosis
1. Read the exact renewal failure
Capture the certificate name, domain set, challenge type, timestamp, and the exact NPM/Certbot error. If the error is a rate-limit response, use the retry time supplied by Let’s Encrypt rather than generating more orders.[3][5]
2. For HTTP-01, verify public port-80 reachability
For an HTTP-01 certificate, confirm the domain resolves to the intended public path and that Let’s Encrypt can reach the HTTP challenge on TCP port 80. HTTP-01 cannot be moved to an arbitrary external port; a working 443 endpoint does not substitute for this requirement.[4]
3. For DNS-01, verify credentials, TXT automation, and plugin health
For a DNS-01 certificate, confirm the configured provider still accepts the narrowly scoped API credentials and that the NPM Certbot plugin installs and runs without dependency errors. NPM documents provider plugins separately and warns that some can lag or conflict with current Certbot dependencies.[3][4]
4. Treat a rate-limit response as its own branch
If Let’s Encrypt reports a rate limit, record the exact limit and Retry-After or retry timestamp. Do not repeatedly click Renew Now or recreate certificates while the limit is active.[5]
5. If current evidence does not select a branch, stop with logs
When HTTP-01 reachability or DNS-01 credentials/plugin health do not explain the failure, preserve the exact NPM and Certbot logs and stop. Historical workarounds from older NPM releases are not promoted into this 2.15.x procedure without current evidence.[1][3]
Supported scenarios
These observations narrow the next investigation; they do not establish a unique cause.
HTTP-01 cannot reach the challenge on port 80
Let’s Encrypt performs HTTP-01 on port 80. Wrong DNS, missing inbound forwarding, ISP filtering, or another listener on the public path can therefore prevent validation even when HTTPS on 443 is working.[4]
How to check: Verify the domain’s public destination and the port-80 path to the NPM challenge endpoint from outside the LAN.[4]
DNS-01 automation cannot update the challenge record
DNS-01 requires the ACME client to create the expected _acme-challenge TXT value. Invalid or over-restricted provider credentials, or a provider API failure, prevents that automation.[4][3]
How to check: Check the NPM/Certbot error for provider authentication or TXT update failure and confirm the configured credential scope without exposing the secret.[4][3]
The NPM DNS plugin has a dependency problem
NPM documents that DNS plugins are maintained independently and can lag or conflict with current Certbot dependencies; NPM 2.15.0 specifically warned that the new dependency stack could require DNS-plugin adjustments.[3][2]
How to check: Look for Certbot or Python package installation errors for the selected DNS provider in the NPM container logs.[3][2]
Let’s Encrypt is refusing new ACME work under a rate limit
Let’s Encrypt applies documented rate limits and returns a retry point. Retrying before that boundary does not fix the underlying condition and can add more failed attempts.[5]
How to check: Match the exact error to the documented rate-limit class and record its retry time.[5]
Next actions and procedure boundaries
Restore the proven HTTP-01 port-80 path
Only after proving HTTP-01 cannot reach the domain on port 80, correct the responsible DNS, firewall/NAT, or upstream forwarding boundary so TCP 80 reaches the intended NPM HTTP challenge path. Do not expose the NPM admin UI and do not change unrelated ports.[4]
Before changing anything
- Risk
- Changing public DNS or firewall/NAT can redirect or expose traffic for every host using that address.[4]
- Safer check
- Prove this certificate uses HTTP-01, record current DNS and port-forward/firewall state, and confirm which public IP and internal NPM listener are intended before editing.[4]
- Expected result
- The public domain reaches the intended NPM HTTP challenge path on port 80 and the same certificate renews without changing unrelated services.[4]
- Backup / recovery access
- Preserve the current DNS records and firewall/NAT rules so the previous public path can be restored exactly.[4]
- Rollback
- Restore the recorded DNS and firewall/NAT state if the challenge path does not recover or any unrelated service becomes reachable incorrectly.[4]
Correct only the proven DNS-01 credential or provider definition
If the error identifies provider authentication or plugin installation, update only the affected DNS credential or provider plugin definition using NPM’s documented Certbot integration. Keep credentials narrowly scoped and do not paste tokens into logs, issues, or page output.[3][4]
Before changing anything
- Risk
- Changing DNS API credentials or plugin definitions can break renewals for every certificate that uses that provider.[3][4]
- Safer check
- Record the provider, plugin version, current credential scope without the secret value, and the exact Certbot/Python error before editing.[3][4]
- Expected result
- A test renewal creates and removes the expected DNS challenge successfully and certificates using other providers remain unaffected.[3][4]
- Backup / recovery access
- Preserve the previous provider/plugin configuration and have a replacement credential ready without exposing either secret.[3][4]
- Rollback
- Restore the previous provider/plugin definition if the new configuration fails, then return to the exact container log error before further changes.[3][4]
Honor the Let’s Encrypt retry boundary
If the ACME server reports a rate limit, stop renewal attempts until the supplied retry time and correct the original validation problem first. Use a staging environment for repeated testing where appropriate rather than consuming production issuance limits.[5]
Keep the certificate and hand off exact logs when unresolved
When the current 2.15.x evidence branches are exhausted, preserve the existing certificate, NPM configuration, and exact Certbot/NPM logs. Do not delete /data, /etc/letsencrypt, the NPM database, or all certificates to force a clean state.[3][1]
Warnings and boundaries
Sources
Links were reviewed on 2026-09-08. Reachability and automated validation do not replace editorial verification of each claim.
- Nginx Proxy Manager v2.15.1 release
Nginx Proxy Manager project · Tier B · accessed 2026-09-08 - Nginx Proxy Manager v2.15.0 release and Trixie compatibility warning
Nginx Proxy Manager project · Tier B · accessed 2026-09-08 - Certbot DNS plugins in Nginx Proxy Manager
Nginx Proxy Manager project · Tier A · accessed 2026-09-08 - Let's Encrypt challenge types
Internet Security Research Group · Tier A · accessed 2026-09-08 - Let's Encrypt rate limits
Internet Security Research Group · Tier A · accessed 2026-09-08