Checklist
- Have you pulled and found the error with
jc21/nginx-proxy-manager:latest docker image?
- No — reproduced on
jc21/nginx-proxy-manager:2.15.1
- Are you sure you're not using someone else's docker image?
- Have you searched for similar issues (both open and closed)?
- Yes — found no existing report specific to the credentials field not being pre-populated on edit
Describe the bug
When editing an existing Let's Encrypt certificate that uses DNS challenge, the Credentials File Content textarea always appears blank — even though the credentials were successfully used to issue the certificate and are correctly persisted in the database.
This is a UI-only display bug. The credentials are stored correctly (I haven't tested renewals). However the blank field causes confusion and leads users to believe the token was lost.
Nginx Proxy Manager Version
2.15.1
To Reproduce
- Create a new Let's Encrypt certificate using DNS Challenge (tested with Cloudflare)
- Enter credentials in the Credentials File Content field:
# Cloudflare API token
dns_cloudflare_api_token=YOUR_TOKEN_HERE
- Save — certificate issues successfully
- Navigate back to the Certificates list
- Click ⋮ → Edit on the same certificate
- Observe: Credentials File Content field is blank
Expected behavior
When editing an existing certificate, the Credentials File Content field should be pre-populated with the previously saved credentials from meta.dns_provider_credentials.
Operating System
Debian 12 (Bookworm), Docker Compose, x86_64
Additional context
We confirmed this is a UI bug and not a persistence bug by querying the SQLite database directly on the host:
docker volume inspect <npm_data_volume> | grep Mountpoint
sqlite3 <mountpoint>/database.sqlite \
"SELECT id, domain_names, meta FROM certificate WHERE nice_name LIKE '%<your-domain>%';"
Output (redacted):
<id>|["<your-domain>"]|{"dns_challenge":true,"dns_provider":"cloudflare","dns_provider_credentials":"# Cloudflare API token\ndns_cloudflare_api_token=<redacted>"}
The dns_provider_credentials value is correctly stored in the meta JSON column. The edit form simply does not read it back to populate the textarea.
I also noted that the /api/nginx/certificates/dns-providers endpoint returns only static provider templates with placeholder credentials — not per-certificate saved values. The edit form may be incorrectly relying on this endpoint to populate the field instead of reading from the certificate's own meta object.
Root cause hypothesis: In the certificate edit form, when opening an existing certificate, the Credentials File Content textarea is not being populated from certificate.meta.dns_provider_credentials. The fix should pre-fill this field when certificate.id exists (edit mode).
- Certificate issuance: ✅ works correctly
- Auto-renewal: unknown status; not tested
- Docker version: 29.5.3, build d1c06ef
- Browser: Chrome Version 148.0.7778.216 (Official Build) (arm64) - macOS
Checklist
jc21/nginx-proxy-manager:latestdocker image?jc21/nginx-proxy-manager:2.15.1Describe the bug
When editing an existing Let's Encrypt certificate that uses DNS challenge, the Credentials File Content textarea always appears blank — even though the credentials were successfully used to issue the certificate and are correctly persisted in the database.
This is a UI-only display bug. The credentials are stored correctly (I haven't tested renewals). However the blank field causes confusion and leads users to believe the token was lost.
Nginx Proxy Manager Version
2.15.1
To Reproduce
Expected behavior
When editing an existing certificate, the Credentials File Content field should be pre-populated with the previously saved credentials from
meta.dns_provider_credentials.Operating System
Debian 12 (Bookworm), Docker Compose, x86_64
Additional context
We confirmed this is a UI bug and not a persistence bug by querying the SQLite database directly on the host:
Output (redacted):
The
dns_provider_credentialsvalue is correctly stored in themetaJSON column. The edit form simply does not read it back to populate the textarea.I also noted that the
/api/nginx/certificates/dns-providersendpoint returns only static provider templates with placeholder credentials — not per-certificate saved values. The edit form may be incorrectly relying on this endpoint to populate the field instead of reading from the certificate's ownmetaobject.Root cause hypothesis: In the certificate edit form, when opening an existing certificate, the Credentials File Content textarea is not being populated from
certificate.meta.dns_provider_credentials. The fix should pre-fill this field whencertificate.idexists (edit mode).