DNS Challenge credentials field appears blank when editing existing certificate (UI display bug - credentials are correctly stored in DB)

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?
  • Yes
• 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

1. Create a new Let's Encrypt certificate using DNS Challenge (tested with Cloudflare)
2. Enter credentials in the Credentials File Content field:

   # Cloudflare API token
   dns_cloudflare_api_token=YOUR_TOKEN_HERE
   

3. Save — certificate issues successfully
4. Navigate back to the Certificates list
5. Click ⋮ → Edit on the same certificate
6. 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

Start at the certificate edit form and compare its existing-certificate data with the /api/nginx/certificates/dns-providers response; verify the form uses certificate.meta.dns_provider_credentials rather than only provider templates. Done when reopening a DNS-challenge certificate shows its saved credentials in the textarea while issuance and database persistence remain unchanged.