Skip to content

DomainOffensive DNS Challenge wrong API variable #4428

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
Jafewe02 opened this issue Mar 10, 2025 · 2 comments
Closed

DomainOffensive DNS Challenge wrong API variable #4428

Jafewe02 opened this issue Mar 10, 2025 · 2 comments
Labels

Comments

@Jafewe02
Copy link

Checklist

  • Have you pulled and found the error with jc21/nginx-proxy-manager:latest docker image?
    • Yes
  • Are you sure you're not using someone else's docker image?
    • Yes
  • Have you searched for similar issues (both open and closed)?
    • No

Describe the bug
The default api variable changed for do.de it was "dns_do_api_token" and the new one is "dns_domainoffensive_api_token"

Nginx Proxy Manager Version

v2.12.3

To Reproduce
Steps to reproduce the behavior:

  1. Go to SSL Certificates
  2. try to add a Let's Encrypt certificate
  3. select DNS Challenge
  4. select Do.de as Provider
  5. in Credentials File Content you can see wrong variable

Expected behavior
DNS Challenge should work if i put in my api token but i need to change the whole line.

Additional context
not a big Bug but as a newbie hard to identify.

@Jafewe02 Jafewe02 added the bug label Mar 10, 2025
@SvenLudwig202
Copy link

I ran into the same issue.
I've been using nginx-proxy-manager for some time now and my existing config doesn't seem to be compatible with 2.12.3, which results in renewal failing since 2.12.3 was released.
I was able to modify some files, so I could renew my certificates, but thought I'll share my findings.

Logfile looked like this

app-1 | [3/11/2025] [10:19:53 AM] [SSL ] › ℹ info Renewing Let'sEncrypt certificates via DomainOffensive (do.de) for Cert #5: XXX
app-1 | [3/11/2025] [10:19:53 AM] [SSL ] › ℹ info Command: certbot renew --force-renewal --config "/etc/letsencrypt.ini" --work-dir "/tmp/letsencrypt-lib" --logs-dir "/tmp/letsencrypt-log" --cert-name 'npm-5' --disable-hook-validation --no-random-sleep-on-renew
app-1 | [3/11/2025] [10:19:53 AM] [Global ] › ⬤ debug CMD: certbot renew --force-renewal --config "/etc/letsencrypt.ini" --work-dir "/tmp/letsencrypt-lib" --logs-dir "/tmp/letsencrypt-log" --cert-name 'npm-5' --disable-hook-validation --no-random-sleep-on-renew
app-1 | [3/11/2025] [10:19:53 AM] [SSL ] › ✖ error Saving debug log to /tmp/letsencrypt-log/letsencrypt.log
app-1 | Failed to renew certificate npm-5 with error: The requested dns-do plugin does not appear to be installed
app-1 | All renewals failed. The following certificates could not be renewed:
app-1 | /etc/letsencrypt/live/npm-5/fullchain.pem (failure)
app-1 | 1 renew failure(s), 0 parse failure(s)
app-1 | Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /tmp/letsencrypt-log/letsencrypt.log or re-run Certbot with -v for more details.
app-1 |
app-1 | [3/11/2025] [10:19:53 AM] [SSL ] › ℹ info Completed SSL cert renew process

In the SQLite database the metadata of the certificate in question was still referring to "dns_do_api_token" in the "dns_provider_credentials".

Inside the container "/etc/letsencrypt/renewal/npm-5.conf" was reading:

authenticator = dns-do
dns_do_propagation_seconds = 120
dns_do_credentials = /etc/letsencrypt/credentials/credentials-5

Also inside the container "/etc/letsencrypt/credentials/credentials-5" was reading:

dns_do_api_token = XXXXXXXXXXXXXXXXX

After modifying the files certbot works with inside the container, I was able to successfully renew my certificate.

I feel like some transformation of the existing configuration files should have happened when updating from 2.12.2 to 2.12.3.
This seems related to updating to the newer DomainOffensive certbot plugin (commit 5d087f1).

@FabianK3
Copy link
Contributor

I feel like some transformation of the existing configuration files should have happened when updating from 2.12.2 to 2.12.3.
This seems related to updating to the newer DomainOffensive certbot plugin (commit 5d087f1).

You are correct. This is something that i did not think off and it had been merged without being tested (😢).

In the original PR the issue has been discussed a bit more: #4235

A fix seems to be already in progress: #4406

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants