NginxProxyManager / nginx-proxy-manager

Docker container for managing Nginx proxy hosts with a simple, powerful interface
https://nginxproxymanager.com
MIT License
21.07k stars 2.45k forks source link

Support for Strato Let'e Encrypt DNS challenge #1154

Open psychofaktory opened 3 years ago

psychofaktory commented 3 years ago

What provider would you like to see added to NPM? Strato

Have you checked if a certbot plugin exists? I found this here: https://github.com/Buxdehuda/strato-certbot

FlixMa commented 5 months ago

Can you explain how? I am stuck at the point with pip install… i always got an error…

Hey @Yoshi315161, did you try the suggestion at the end of the error message? the Strato package doesn’t need to much dependencies. Good chance, nothing will break. Just saying that it might be worth a try, just make sure to have a backup.

Yoshi315161 commented 5 months ago

Ok got it to work now Thx for the hint FlixMa :) If someone have the same problems with the error:

  1. exec in to the container
  2. apt update
  3. apt install pip
  4. apt install nano
  5. pip install certbot-dns-strato==0.2.1 --break-system-packages
  6. cd global/
  7. nano certbot-dns-plugins.json
  8. change the version from Strato 0.1.1 to 0.2.1 and save it
  9. restart the container
  10. Request a new Wildcard within NPM
nevyen commented 5 months ago

Hey I followed the instructions serveral times.

But I still get an Error. I've got a guess what the problem is.

In my strato login are different packages. So on the first login I got the list with packages and need to select one before I can edit a domain.

It seems there is a param cID in the URL which select the right package.

I tried to add it to the custom_api_pathbut it seems this isn't the solution.

@FlixMa maybe you got an idea how to manage it.

FlixMa commented 5 months ago

The cID is determined automatically by the domain name you specify in the configuration. It is wrong to add it to the custom path. Is your cid 0 or 1 or something way higher like 6-digits? Strato did change this behaviour and broke it for my setup some weeks ago, but I thought I fixed that.

Estradamis commented 5 months ago

Joining here as the steps provided didnt fix the issue :(

speede83 commented 5 months ago

Hey all, apparently Strato did change the way of accessing the individual packages. In the past this was done through an absolute package id. Now this changed to incrementing numbers per account.

Hopefully the uploaded fix 0.2.1 will account for that. The tests on my end are looking fine. Please try to update the pip package and let me know :-) Felix

Thanks a lot. Updated NPM to v2.11.1 and updated the certbot-dns-strato to fix 0.2.1. I instatly was able to renew my wildcard certificat.

nevyen commented 5 months ago

I tried it once again but it didn't work

my Config is:

dns_strato_username = "myloginnumber"
dns_strato_password = "mySecretPasswordWitha$asSpecialChar"

Propagation Seconds = 70

The log gives the following output

2024-02-20 14:29:12,215:DEBUG:acme.client:Storing nonce: 1pTQTQeXzVAON8O3Q591coWeQUvKkxzhPFA_m3dQMlrt4jo7VBI
2024-02-20 14:29:12,218:INFO:certbot._internal.auth_handler:Performing the following challenges:
2024-02-20 14:29:12,219:INFO:certbot._internal.auth_handler:dns-01 challenge for mydomain.de
2024-02-20 14:29:12,228:DEBUG:urllib3.connectionpool:Starting new HTTPS connection (1): www.strato.de:443
2024-02-20 14:29:12,528:DEBUG:urllib3.connectionpool:https://www.strato.de:443 "GET /apps/CustomerService HTTP/1.1" 200 None
2024-02-20 14:29:13,011:DEBUG:urllib3.connectionpool:https://www.strato.de:443 "POST /apps/CustomerService HTTP/1.1" 302 0
2024-02-20 14:29:13,082:DEBUG:urllib3.connectionpool:https://www.strato.de:443 "GET /apps/CustomerService?sessionID=5dc882acc8846e453a5e95c7019079&node=kds_CustomerEntryPage&cID=0&swtssa=gerbksnst0000000000000000 HTTP/1.1" 200 None
2024-02-20 14:29:13,146:DEBUG:urllib3.connectionpool:https://www.strato.de:443 "GET /apps/CustomerService?sessionID=5dc882acc8846e453a5e95c7019079&cID=0&node=kds_CustomerEntryPage HTTP/1.1" 200 None

As you can see my cID above is 0 when I login into my account the cID is 1.

Maybe this is my problem.

4EverChaos commented 4 months ago

Ok got it to work now Thx for the hint FlixMa :) If someone have the same problems with the error:

1. exec in to the container

2. apt update

3. apt install pip

4. apt install nano

5. pip install certbot-dns-strato==0.2.1 --break-system-packages

6. cd global/

7. nano certbot-dns-plugins.json

8. change the version from Strato 0.1.1 to 0.2.1 and save it

9. restart the container

10. Request a new Wildcard within NPM

This helped in my case, thanks for the steps!

mwLabs-eu commented 4 months ago

Trying to setup a new LXC on proxmox but cannot get it to run. Requesting single subdomain certificates is working fine, but DNS challenge with strato isn't.

Already updated certbot-dns-strato, modified certbot-dns-plugins.json etc. but no success.

2FA is NOT activated & no '#' inside my password.

NPM: v2.11.1 also tried with 2.10

Credentials File Content

```shell dns_strato_username = "XXXXX" dns_strato_password = "XXXXXXXXXXXX" #uncomment if youre using two factor authentication: #dns_strato_totp_devicename = 2fa_device #dns_strato_totp_secret = 2fa_secret # #uncomment if domain name contains special characters #insert domain display name as seen on your account page here #dns_strato_domain_display_name = my-punicode-url.de # #if youre not using strato.de or another special endpoint you can customise it below #you will probably only need to adjust the host, but you can also change the complete endpoint url #dns_strato_custom_api_scheme = https #dns_strato_custom_api_host = www.strato.de #dns_strato_custom_api_port = 443 #dns_strato_custom_api_path = "/apps/CustomerService" ```

Error in NPM

```shell CommandError: Saving debug log to /tmp/letsencrypt-log/letsencrypt.log at /app/lib/utils.js:16:13 at ChildProcess.exithandler (node:child_process:410:5) at ChildProcess.emit (node:events:513:28) at maybeClose (node:internal/child_process:1100:16) at Process.ChildProcess._handle.onexit (node:internal/child_process:304:5) ```

letsencrypt.log

```shell 2024-03-01 14:41:04,687:DEBUG:certbot._internal.main:certbot version: 2.1.0 2024-03-01 14:41:04,687:DEBUG:certbot._internal.main:Location of certbot entry point: /usr/bin/certbot 2024-03-01 14:41:04,687:DEBUG:certbot._internal.main:Arguments: ['--config', '/etc/letsencrypt.ini', '--work-dir', '/tmp/letsencrypt-lib', '--logs-dir', '/tmp/letsencrypt-log', '--cert-name', 'npm-3', '--agree-tos', '--email', 'webmaster@XXXXX.de', '--domains', 'XXXXX.de', '--authenticator', 'dns-strato', '--dns-strato-credentials', '/etc/letsencrypt/credentials/credentials-3'] 2024-03-01 14:41:04,687:DEBUG:certbot._internal.main:Discovered plugins: PluginsRegistry(PluginEntryPoint#dns-cloudflare,PluginEntryPoint#dns-duckdns,PluginEntryPoint#dns-porkbun,PluginEntryPoint#dns-strato,PluginEntryPoint#manual,PluginEntryPoint#null,PluginEntryPoint#standalone,PluginEntryPoint#webroot) 2024-03-01 14:41:04,693:DEBUG:certbot._internal.log:Root logging level set at 30 2024-03-01 14:41:04,694:DEBUG:certbot._internal.plugins.selection:Requested authenticator dns-strato and installer None 2024-03-01 14:41:04,694:DEBUG:certbot._internal.plugins.selection:Single candidate plugin: * dns-strato Description: Obtain certificates using a DNS TXT record (if you are using Strato for DNS). Interfaces: Authenticator, Plugin Entry point: dns-strato = certbot_dns_strato.dns_strato:Authenticator Initialized: Prep: True 2024-03-01 14:41:04,695:DEBUG:certbot._internal.plugins.selection:Selected authenticator and installer None 2024-03-01 14:41:04,695:INFO:certbot._internal.plugins.selection:Plugins selected: Authenticator dns-strato, Installer None 2024-03-01 14:41:04,727:DEBUG:certbot._internal.main:Picked account: ), creation_host='npm.localdomain', register_to_eff=None))> 2024-03-01 14:41:04,727:DEBUG:acme.client:Sending GET request to https://acme-v02.api.letsencrypt.org/directory. 2024-03-01 14:41:05,165:DEBUG:acme.client:Received response: HTTP 200 Server: nginx Date: Fri, 01 Mar 2024 13:41:05 GMT Content-Type: application/json Content-Length: 752 Connection: keep-alive Cache-Control: public, max-age=0, no-cache X-Frame-Options: DENY Strict-Transport-Security: max-age=604800 { "6_Pvodmp9nQ": "https://community.letsencrypt.org/t/adding-random-entries-to-the-directory/33417", "keyChange": "https://acme-v02.api.letsencrypt.org/acme/key-change", "meta": { "caaIdentities": [ "letsencrypt.org" ], "termsOfService": "https://letsencrypt.org/documents/LE-SA-v1.3-September-21-2022.pdf", "website": "https://letsencrypt.org" }, "newAccount": "https://acme-v02.api.letsencrypt.org/acme/new-acct", "newNonce": "https://acme-v02.api.letsencrypt.org/acme/new-nonce", "newOrder": "https://acme-v02.api.letsencrypt.org/acme/new-order", "renewalInfo": "https://acme-v02.api.letsencrypt.org/draft-ietf-acme-ari-02/renewalInfo/", "revokeCert": "https://acme-v02.api.letsencrypt.org/acme/revoke-cert" } 2024-03-01 14:41:05,166:DEBUG:certbot._internal.display.obj:Notifying user: Requesting a certificate for XXXXX.de 2024-03-01 14:41:05,178:DEBUG:certbot.crypto_util:Generating ECDSA key (2048 bits): /etc/letsencrypt/keys/0002_key-certbot.pem 2024-03-01 14:41:05,188:DEBUG:certbot.crypto_util:Creating CSR: /etc/letsencrypt/csr/0002_csr-certbot.pem 2024-03-01 14:41:05,192:DEBUG:acme.client:Requesting fresh nonce 2024-03-01 14:41:05,192:DEBUG:acme.client:Sending HEAD request to https://acme-v02.api.letsencrypt.org/acme/new-nonce. 2024-03-01 14:41:05,333:DEBUG:acme.client:Received response: HTTP 200 Server: nginx Date: Fri, 01 Mar 2024 13:41:05 GMT Connection: keep-alive Cache-Control: public, max-age=0, no-cache Link: ;rel="index" Replay-Nonce: iCRP5AvKBZQQDNabOqaNZb8VQSj0sAOmXtGuOTI0WpwW76p--LY X-Frame-Options: DENY Strict-Transport-Security: max-age=604800 2024-03-01 14:41:05,334:DEBUG:acme.client:Storing nonce: iCRP5AvKBZQQDNabOqaNZb8VQSj0sAOmXtGuOTI0WpwW76p--LY 2024-03-01 14:41:05,335:DEBUG:acme.client:JWS payload: b'{\n "identifiers": [\n {\n "type": "dns",\n "value": "XXXXX.de"\n }\n ]\n}' 2024-03-01 14:41:05,343:DEBUG:acme.client:Sending POST request to https://acme-v02.api.letsencrypt.org/acme/new-order: { "protected": "eyJhbGciOiAiUlMyNTYiLCAia2lkIjogImh0dHBzOi8vYWNtZS12MDIuYXBpLmxldHNlbmNyeXB0Lm9yZy9hY21lL2FjY3QvMTU5Njc5Njk0NyIsICJub25jZSI6ICJpQ1JQNUF2S0JaUVFETmFiT3FhTlpiOFZRU2owc0FPbVh0R3VPVEkwV3B3Vzc2cC0tTFkiLCAidXJsIjogImh0dHBzOi8vYWNtZS12MDIuYXBpLmxldHNlbmNyeXB0Lm9yZy9hY21lL25ldy1vcmRlciJ9", "signature": "ftcKQsGnUrRi7tg2DMXnzw3azVcCRJgvHldRbp_WLmI2ov_Z5ys5xcJF5gouD5vbNls1j7c_lklzTW4XqVTONZ1N9DQIfmsxjfN4G-s78GDLIr3xVu9TzaMtWjodZd1cb9jfQbORsBskeU27iVDZDmP91vvIPP4yVIUJC1T5rF6qIaZQVeqm99Kbk5SG_5P_USdvq--z9J72QLoWRXuHvA-kyonnWjECCL9vwhZIGl9ihQkjxTmzWrsBw5TZSac1TJE_bFYnHzbWtgnxfgwWisRatRTJgtqt8x9ByyN6O5TrP2TQ7UJD7xrsT4N8wWiMzjpxudIC56DtAMxS6oNoyQ", "payload": "ewogICJpZGVudGlmaWVycyI6IFsKICAgIHsKICAgICAgInR5cGUiOiAiZG5zIiwKICAgICAgInZhbHVlIjogIndvbGV3aWVuc2tpLmRlIgogICAgfQogIF0KfQ" } 2024-03-01 14:41:05,736:DEBUG:acme.client:Received response: HTTP 201 Server: nginx Date: Fri, 01 Mar 2024 13:41:05 GMT Content-Type: application/json Content-Length: 340 Connection: keep-alive Boulder-Requester: 1596796947 Cache-Control: public, max-age=0, no-cache Link: ;rel="index" Location: https://acme-v02.api.letsencrypt.org/acme/order/1596796947/248728721787 Replay-Nonce: iCRP5AvKuHwnj8SJuFgqR7PK3u2C4C33ZccsWzxV0T5YEalgkpg X-Frame-Options: DENY Strict-Transport-Security: max-age=604800 { "status": "pending", "expires": "2024-03-08T13:37:36Z", "identifiers": [ { "type": "dns", "value": "XXXXX.de" } ], "authorizations": [ "https://acme-v02.api.letsencrypt.org/acme/authz-v3/321228332677" ], "finalize": "https://acme-v02.api.letsencrypt.org/acme/finalize/1596796947/248728721787" } 2024-03-01 14:41:05,737:DEBUG:acme.client:Storing nonce: iCRP5AvKuHwnj8SJuFgqR7PK3u2C4C33ZccsWzxV0T5YEalgkpg 2024-03-01 14:41:05,738:DEBUG:acme.client:JWS payload: b'' 2024-03-01 14:41:05,741:DEBUG:acme.client:Sending POST request to https://acme-v02.api.letsencrypt.org/acme/authz-v3/321228332677: { "protected": "eyJhbGciOiAiUlMyNTYiLCAia2lkIjogImh0dHBzOi8vYWNtZS12MDIuYXBpLmxldHNlbmNyeXB0Lm9yZy9hY21lL2FjY3QvMTU5Njc5Njk0NyIsICJub25jZSI6ICJpQ1JQNUF2S3VId25qOFNKdUZncVI3UEszdTJDNEMzM1pjY3NXenhWMFQ1WUVhbGdrcGciLCAidXJsIjogImh0dHBzOi8vYWNtZS12MDIuYXBpLmxldHNlbmNyeXB0Lm9yZy9hY21lL2F1dGh6LXYzLzMyMTIyODMzMjY3NyJ9", "signature": "HApgjJKW2K4bNfizVUGjacGbefTRQaWLGRMKN3pfH4IRsDbiHjI_mg48rUqv85Fh5A2O4vBdoDirSdZie7G3d6yEn0CtEaYvJQidtN7jq8Hs_w-mSJJKpx_lS-NzaRcReEVIHgeiYVrqGHIiPM5bnoEMs5YAKHJdayoZBRcmUNxmV3PgzsX0ywHDor5zdYIt5-XuYxERNrCnBlbc2bn0Cnuc9Zhmo_OHuZ1vR-FPuFv5h0iHiHrr4R4v6WgpooRdGM_FRa6Bj077z3_B-MgGKKFXxzFbqdED_15xRHXgjPzZHKnZy1ankVPSovvcZuWvcq1Xo8bKpKABxgb6oT0Mgw", "payload": "" } 2024-03-01 14:41:05,893:DEBUG:acme.client:Received response: HTTP 200 Server: nginx Date: Fri, 01 Mar 2024 13:41:05 GMT Content-Type: application/json Content-Length: 798 Connection: keep-alive Boulder-Requester: 1596796947 Cache-Control: public, max-age=0, no-cache Link: ;rel="index" Replay-Nonce: iCRP5AvKDvj1FvscYFwwsTlUU1kHvR7yRVh3muiUBT0T4JBLoVQ X-Frame-Options: DENY Strict-Transport-Security: max-age=604800 { "identifier": { "type": "dns", "value": "XXXXX.de" }, "status": "pending", "expires": "2024-03-08T13:37:36Z", "challenges": [ { "type": "http-01", "status": "pending", "url": "https://acme-v02.api.letsencrypt.org/acme/chall-v3/321228332677/H8KNtg", "token": "grWJn6XTE8BdkTUAselPoSFhquwisYXDt7PsU_XetV4" }, { "type": "dns-01", "status": "pending", "url": "https://acme-v02.api.letsencrypt.org/acme/chall-v3/321228332677/I5rWVg", "token": "grWJn6XTE8BdkTUAselPoSFhquwisYXDt7PsU_XetV4" }, { "type": "tls-alpn-01", "status": "pending", "url": "https://acme-v02.api.letsencrypt.org/acme/chall-v3/321228332677/Hl0VMg", "token": "grWJn6XTE8BdkTUAselPoSFhquwisYXDt7PsU_XetV4" } ] } 2024-03-01 14:41:05,894:DEBUG:acme.client:Storing nonce: iCRP5AvKDvj1FvscYFwwsTlUU1kHvR7yRVh3muiUBT0T4JBLoVQ 2024-03-01 14:41:05,895:INFO:certbot._internal.auth_handler:Performing the following challenges: 2024-03-01 14:41:05,896:INFO:certbot._internal.auth_handler:dns-01 challenge for XXXXX.de ```

Had it running in docker on unraid successful but want to move the critical applications to my proxmox cluster. I would really appreciate your help here.

EDIT: I just saw, on my existing NPM on Unraid, also v2.11.1 I run into problems too, when renewing the domain (XXXXX.de) which I´ve tried with the new NPM container. When trying with one of my other domains (YYYYY.com), I can renew without problems. I´ve checked both config files, they are the same. So I have no idea why it's not working for that one domain. In the new container, it is working with my second domain (YYYYY.com) too, with the first one (XXXXX.de) not. Tested with exactly the same settings but ran into the above issue.

Vientus commented 4 months ago

Try to use your package password and your domain.

Go to your strato account and set your package password. Then check, if you can login to your strato account with your domain name (e.g. example.com) as user and for your password use your package password.

If that works, enter those credentials into the Credential File:

dns_strato_username = "example.com"
dns_strato_password = "package password"  
#uncomment if youre using two factor authentication:
#dns_strato_totp_devicename = 2fa_device
#dns_strato_totp_secret = 2fa_secret
#
#uncomment if domain name contains special characters
#insert domain display name as seen on your account page here
#dns_strato_domain_display_name = my-punicode-url.de
#
#if youre not using strato.de or another special endpoint you can customise it below
#you will probably only need to adjust the host, but you can also change the complete endpoint url
#dns_strato_custom_api_scheme = https
#dns_strato_custom_api_host = www.strato.de
#dns_strato_custom_api_port = 443
#dns_strato_custom_api_path = "/apps/CustomerService"
anubis-genix commented 4 months ago

Ok got it to work now Thx for the hint FlixMa :) If someone have the same problems with the error:

1. exec in to the container

2. apt update

3. apt install pip

4. apt install nano

5. pip install certbot-dns-strato==0.2.1 --break-system-packages

6. cd global/

7. nano certbot-dns-plugins.json

8. change the version from Strato 0.1.1 to 0.2.1 and save it

9. restart the container

10. Request a new Wildcard within NPM

And I had assumed that it was just a bug in the older version. It was all the more annoying to discover that it doesn't work with the newer version either. It finally got it to work thanks to your instructions. Thanks a lot!

mwLabs-eu commented 4 months ago

Try to use your package password and your domain.

Go to your strato account and set your package password. Then check, if you can login to your strato account with your domain name (e.g. example.com) as user and for your password use your package password.

If that works, enter those credentials into the Credential File:


dns_strato_username = "example.com"

dns_strato_password = "package password"  

#uncomment if youre using two factor authentication:

#dns_strato_totp_devicename = 2fa_device

#dns_strato_totp_secret = 2fa_secret

#

#uncomment if domain name contains special characters

#insert domain display name as seen on your account page here

#dns_strato_domain_display_name = my-punicode-url.de

#

#if youre not using strato.de or another special endpoint you can customise it below

#you will probably only need to adjust the host, but you can also change the complete endpoint url

#dns_strato_custom_api_scheme = https

#dns_strato_custom_api_host = www.strato.de

#dns_strato_custom_api_port = 443

#dns_strato_custom_api_path = "/apps/CustomerService"

This finally worked for me! Thank you very much!!! 😁

mwLabs-eu commented 4 months ago

Hey, again me. Looks like I was able to request a cert for my domain now. but it seems not to be a wildcard. There is no "*" in front of the domain, and we also receive the message from Firefox, that the domain name (subdomain) is missing in the cert.

EDIT: Also, whats interesting, now my default strato credentials are working again for this domain...

Vientus commented 4 months ago

Hey, again me. Looks like I was able to request a cert for my domain now. but it seems not to be a wildcard. There is no "*" in front of the domain, and we also receive the message from Firefox, that the domain name (subdomain) is missing in the cert.

EDIT: Also, whats interesting, now my default strato credentials are working again for this domain...

You added your domain to nginx like domain.com and also *.domain.com? Then you should receive a wildcard cert.

mwLabs-eu commented 4 months ago

No, I´ve just added "domain.de" to the textbox, like I did in the past. When additionally adding "*.domain.de" I run into an issue.

EDIT: Anyway, now I´m running into the cert limit. ._.

Vientus commented 4 months ago

I am just a noob myself in that area of expertise ;-). But I think, you have to add *.domain.de for receiving a second level subdomain wildcard certificate.

mwLabs-eu commented 4 months ago

I think I never did this in the past, but it's possible, it got automatically added. Not sure to be honest. But with adding it, it did not work, as the resolved address is not routed to my server (its checking for *.domain.de).

kaptewn commented 4 months ago

Hi,

I just found this thread and it has helped me greatly in managing to create a cert for my domain on strato.

One small (big) problem though. Even though the cert shows up, and I can use it for my reverse proxy, i get an "ERR_SSL_VERSION_OR_CIPHER_MISMATCH" error when I'm trying to connect to the domain. Why woud that be if I have used the config below?

*.example.se

dns_strato_username = username dns_strato_password = "password" dns_strato_domain_display_name = example.se dns_strato_custom_api_host = www.strato.se

I have tried the full subdomain instead of the wildcard and as display name aswell, but nothing works. The Cert is created with no problems, but I get the version or mismatch error in chrome every time. In firefox the error is "SSL_ERROR_NO_CYPHER_OVERLAP" instead.

If i create a cert for duckdns.org for example, there is no problems at all.

Can anyone elaborate on what I need to do?

EDIT: I solved it myselv by adding the domain to Cloudflare and bypassing Strato DNS completely. Then I could also just make a DNS challenge to Cloudflare instead of Strato.

PLanB2008 commented 4 months ago

After updating to 0.2.1 I could renew the wildcard certificate for one of my two domains. For the other I still get the same error as before. Any hints how to solve this?

Using the https://github.com/Buxdehuda/strato-certbot certbot I can at least receive the fitting certificate, so there it seems to be fixed :)

wolflu05 commented 3 months ago

I can confirm that renewal after manually updating to 0.2.1 works. But why is that version not updated in the official docker container?

PLanB2008 commented 3 months ago

For me it still only works for the first of my domains.

pdsccode commented 3 months ago

Sadly, neither can I renew my wildcard cert nor can I request a new one with any combination of the settings from above. I tried with updating the python package as well. I still get an "internal error" without any indication to the error itself.

jclsn commented 3 months ago

I could successfully create my wildcard certificate, but still can't reach the subdomains when I select it for the proxy host. Btw it says the domains have to already be created. Does that mean that the wildcard certificate will only be created for the subdomains already added in the Strato account?

nevyen commented 3 months ago

I could successfully create my wildcard certificate, but still can't reach the subdomains when I select it for the proxy host. Btw it says the domains have to already be created. Does that mean that the wildcard certificate will only be created for the subdomains already added in the Strato account?

You need to register your subdomains manually at strato. NGINX can't register Subdomains for you.

You need to register your subdomains and set the ip where they should point to. Or you could set a CNAME to point to the same IP as your DYNDNS Domain.

The Wildcard certificate is valid for all subdomains. No matter if they existed before or after the certificate generation.

jclsn commented 3 months ago

@nevyen I would like it to use the same IP as the DynDNS domain. How do I do this with the CNAME? Shouldn't this be automatically set up? I have DynDNS deactivated for the subdomain and I realized that the IP differs from the main domain. I would assume they are the same.

I am still being greeted with the Strato landing page on the subdomain, so the proxy doesn't seem to work. The certificate for my main domain also is not trusted by Firefox today and it points to my router's WebUI. Yesterday this still worked. Really hard to set this up. DuckDNS was so straight-forward.

nevyen commented 3 months ago

@jclsn for each subdomain you must set the CNAME to the domain you registered in your routers dyndns. Then the subdomain will automaticly get the ip from the "main" domain.

Referr to https://www.strato.de/faq/domains/wie-kann-ich-bei-strato-meine-dns-eintraege-verwalten/#cname

FlixMa commented 3 months ago

@jclsn Its not about your proxy not working, but rather a wrong configuration in your strato package. Each subdomain can point to a different server, thus strato allowing you to assign different IPs to each subdomain.

If you just need them to all point to the same server (e.g. your npm instance) than you can either set up your router to supply dyndns for all your subdomains or just use CNAME records in your primary domain. CNAME stands for canonical name and are basically the DNS way of saying „this is an alias for that“.

jclsn commented 3 months ago

The link you sent me is an A-record, where I should enter an IP, although I don't understand how this would work with DynDNS. Afaik the IP changes from time to time.

I looked at changing the CNAME, but it doesn't accept maindomain.de. Calling the Strato support now. I just wonder why the proxy for the main domain is not working anymore. This is probably a configuration issue with NPM. My DuckDNS proxies are still active and working though.

jclsn commented 3 months ago

So I added maindomain.de. as CNAME and now the FritzBox is complaining about DNS Rebind protection. The Strato customer support didn't know how to help me :D Guess they only have qualified support for corporate customers.

jclsn commented 3 months ago

I just realized it works correctly from outside my network. Just tried it with my phone. As soon as I connect to the wifi thoug, the maindomain.de is showing me the router's web ui and the subdomains gives me the rebind protection warning.

tbreitha commented 3 months ago

I gave up with Strato DNS plugin. I kept my domain with Strato but moved the DNS Records off to a free Account on Cloudflare. Now the certs incl. wildcard working without any issues also renewing them is not a problem anymore. Cheers Tom

jclsn commented 3 months ago

Ha, I made it! Seems like you can't use the DynDNS in the FritzBox. Using ddclient works much better!

So here is what I did:

  1. Update the certbot-dns-strato plugin to 0.2.1 as mentioned above
  2. In your Strato account: Create all you subdomains and don't activate DynDNS for them
  3. In your Strato account: Go to subdomain configuration -> DNS configuration -> CNAME-Record -> enter "mydomain.de." including the last dot and save
  4. For DynDNS: I had no luck with doing it directly on the FritzBox, as I could only access the website from outside my network. So I used ddclient. Download the ddclient package to your Linux server and use the template posted here to set it up. Just running ddclient and following the instructions will probably also work. SSL will not work with checkip.dyndns.org, so use ssl=no (see). Use your DynDNS credentials here!
  5. Create your wildcard certificate in NPM using your Strato account credentials, not your DynDNS credentials!
  6. Create your proxies for your subdomains and add the wildcard certificate
  7. Don't forget to open ports 80 and 443 for your server on your router to make NPM reachable from outside your network!
mwLabs-eu commented 2 months ago

When requesting wildcard certificates for my .de domain, i´m still running into issues. The cert request just aborts, with no visible error message. This problem only comes up for .de domains, found my .com and .eu domains from same strato account are working fine. Any idea, what could block me here?

Using Nginx Proxy Manager v2.11.1, certbot-dns-strato v0.2.1

Full log of issue

```bash 2024-05-02 16:18:38,612:DEBUG:certbot._internal.main:certbot version: 2.1.0 2024-05-02 16:18:38,612:DEBUG:certbot._internal.main:Location of certbot entry point: /usr/bin/certbot 2024-05-02 16:18:38,612:DEBUG:certbot._internal.main:Arguments: ['--config', '/etc/letsencrypt.ini', '--work-dir', '/tmp/letsencrypt-lib', '--logs-dir', '/tmp/letsencrypt-log', '--cert-name', 'npm-52', '--agree-tos', '--email', 'webmaster@domain.de', '--domains', 'domain.de', '--authenticator', 'dns-strato', '--dns-strato-credentials', '/etc/letsencrypt/credentials/credentials-52'] 2024-05-02 16:18:38,612:DEBUG:certbot._internal.main:Discovered plugins: PluginsRegistry(PluginEntryPoint#dns-cloudflare,PluginEntryPoint#dns-duckdns,PluginEntryPoint#dns-porkbun,PluginEntryPoint#dns-strato,PluginEntryPoint#manual,PluginEntryPoint#null,PluginEntryPoint#standalone,PluginEntryPoint#webroot) 2024-05-02 16:18:38,619:DEBUG:certbot._internal.log:Root logging level set at 30 2024-05-02 16:18:38,619:DEBUG:certbot._internal.plugins.selection:Requested authenticator dns-strato and installer None 2024-05-02 16:18:38,620:DEBUG:certbot._internal.plugins.selection:Single candidate plugin: * dns-strato Description: Obtain certificates using a DNS TXT record (if you are using Strato for DNS). Interfaces: Authenticator, Plugin Entry point: dns-strato = certbot_dns_strato.dns_strato:Authenticator Initialized: Prep: True 2024-05-02 16:18:38,620:DEBUG:certbot._internal.plugins.selection:Selected authenticator and installer None 2024-05-02 16:18:38,620:INFO:certbot._internal.plugins.selection:Plugins selected: Authenticator dns-strato, Installer None 2024-05-02 16:18:38,658:DEBUG:certbot._internal.main:Picked account: ), creation_host='reverse-proxy.localdomain', register_to_eff=None))> 2024-05-02 16:18:38,658:DEBUG:acme.client:Sending GET request to https://acme-v02.api.letsencrypt.org/directory. 2024-05-02 16:18:39,085:DEBUG:acme.client:Received response: HTTP 200 Server: nginx Date: Thu, 02 May 2024 14:18:39 GMT Content-Type: application/json Content-Length: 747 Connection: keep-alive Cache-Control: public, max-age=0, no-cache X-Frame-Options: DENY Strict-Transport-Security: max-age=604800 { "OCi65trDFA8": "https://community.letsencrypt.org/t/adding-random-entries-to-the-directory/33417", "keyChange": "https://acme-v02.api.letsencrypt.org/acme/key-change", "meta": { "caaIdentities": [ "letsencrypt.org" ], "termsOfService": "https://letsencrypt.org/documents/LE-SA-v1.4-April-3-2024.pdf", "website": "https://letsencrypt.org" }, "newAccount": "https://acme-v02.api.letsencrypt.org/acme/new-acct", "newNonce": "https://acme-v02.api.letsencrypt.org/acme/new-nonce", "newOrder": "https://acme-v02.api.letsencrypt.org/acme/new-order", "renewalInfo": "https://acme-v02.api.letsencrypt.org/draft-ietf-acme-ari-02/renewalInfo/", "revokeCert": "https://acme-v02.api.letsencrypt.org/acme/revoke-cert" } 2024-05-02 16:18:39,086:DEBUG:certbot._internal.display.obj:Notifying user: Requesting a certificate for domain.de 2024-05-02 16:18:39,097:DEBUG:certbot.crypto_util:Generating ECDSA key (2048 bits): /etc/letsencrypt/keys/0064_key-certbot.pem 2024-05-02 16:18:39,107:DEBUG:certbot.crypto_util:Creating CSR: /etc/letsencrypt/csr/0064_csr-certbot.pem 2024-05-02 16:18:39,110:DEBUG:acme.client:Requesting fresh nonce 2024-05-02 16:18:39,111:DEBUG:acme.client:Sending HEAD request to https://acme-v02.api.letsencrypt.org/acme/new-nonce. 2024-05-02 16:18:39,251:DEBUG:acme.client:Received response: HTTP 200 Server: nginx Date: Thu, 02 May 2024 14:18:39 GMT Connection: keep-alive Cache-Control: public, max-age=0, no-cache Link: ;rel="index" Replay-Nonce: O0afatDIUYo_tvD0qKgcSxmqX1tK9R_NX45BGoQ8WT4UCWOsn-U X-Frame-Options: DENY Strict-Transport-Security: max-age=604800 2024-05-02 16:18:39,252:DEBUG:acme.client:Storing nonce: O0afatDIUYo_tvD0qKgcSxmqX1tK9R_NX45BGoQ8WT4UCWOsn-U 2024-05-02 16:18:39,252:DEBUG:acme.client:JWS payload: b'{\n "identifiers": [\n {\n "type": "dns",\n "value": "domain.de"\n }\n ]\n}' 2024-05-02 16:18:39,260:DEBUG:acme.client:Sending POST request to https://acme-v02.api.letsencrypt.org/acme/new-order: { "protected": "eyJhbGciOiAiUlMyNTYiLCAia2lkIjogImh0dHBzOi8vYWNtZS12MDIuYXBpLmxldHNlbmNyeXB0Lm9yZy9hY21lL2FjY3QvMTU5ODUwMTIyNyIsICJub25jZSI6ICJPMGFmYXRESVVZb190dkQwcUtnY1N4bXFYMXRLOVJfTlg0NUJHb1E4V1Q0VUNXT3NuLVUiLCAidXJsIjogImh0dHBzOi8vYWNtZS12MDIuYXBpLmxldHNlbmNyeXB0Lm9yZy9hY21lL25ldy1vcmRlciJ9", "signature": "TNaLqp0iX0oneAfzg9KFPB5WFMIwk-983BR1hw2ProTI74Str79_tfoXWjx40wIBPFiIG5eQkohC93KrX6iPNFIo9se4OlTJwpYxolUYDehXtyY6yULfpOMXQBcDUxkUARB0cW5ERoyRVz16CHi8oiCxOkYGRwB3St_EOPCYPKNAxAiRSjT-hb4ONIe_9iSRcgeDBGfqwrp104cRnNJB9qVPVOCpqtoM9WzX5pF9TIY6pKI-uX47FPQR9fcZ3_lbFm53a5Iz9Byt7_Bav1wKvZmZf_noK3u66AAHMjSg05bb3hqS2FoJqR1TB0Kc4YIPF_BSX_3CA-ronONwE4dfhA", "payload": "ewogICJpZGVudGlmaWVycyI6IFsKICAgIHsKICAgICAgInR5cGUiOiAiZG5zIiwKICAgICAgInZhbHVlIjogIndvbGV3aWVuc2tpLmRlIgogICAgfQogIF0KfQ" } 2024-05-02 16:18:39,414:DEBUG:acme.client:Received response: HTTP 201 Server: nginx Date: Thu, 02 May 2024 14:18:39 GMT Content-Type: application/json Content-Length: 340 Connection: keep-alive Boulder-Requester: 1598501227 Cache-Control: public, max-age=0, no-cache Link: ;rel="index" Location: https://acme-v02.api.letsencrypt.org/acme/order/1598501227/265980151337 Replay-Nonce: Y_7AIQuUkd3e3_rcDcX4pgPvzO4_O7YtbF9-GNnBAG3kkijVcoA X-Frame-Options: DENY Strict-Transport-Security: max-age=604800 { "status": "pending", "expires": "2024-05-09T14:10:50Z", "identifiers": [ { "type": "dns", "value": "domain.de" } ], "authorizations": [ "https://acme-v02.api.letsencrypt.org/acme/authz-v3/345790981617" ], "finalize": "https://acme-v02.api.letsencrypt.org/acme/finalize/1598501227/265980151337" } 2024-05-02 16:18:39,415:DEBUG:acme.client:Storing nonce: Y_7AIQuUkd3e3_rcDcX4pgPvzO4_O7YtbF9-GNnBAG3kkijVcoA 2024-05-02 16:18:39,415:DEBUG:acme.client:JWS payload: b'' 2024-05-02 16:18:39,417:DEBUG:acme.client:Sending POST request to https://acme-v02.api.letsencrypt.org/acme/authz-v3/345790981617: { "protected": "eyJhbGciOiAiUlMyNTYiLCAia2lkIjogImh0dHBzOi8vYWNtZS12MDIuYXBpLmxldHNlbmNyeXB0Lm9yZy9hY21lL2FjY3QvMTU5ODUwMTIyNyIsICJub25jZSI6ICJZXzdBSVF1VWtkM2UzX3JjRGNYNHBnUHZ6TzRfTzdZdGJGOS1HTm5CQUcza2tpalZjb0EiLCAidXJsIjogImh0dHBzOi8vYWNtZS12MDIuYXBpLmxldHNlbmNyeXB0Lm9yZy9hY21lL2F1dGh6LXYzLzM0NTc5MDk4MTYxNyJ9", "signature": "PNZq4tTE50GX_sy3ClPHI4W9tjzlHLWdvZEpCcHHVUfNxTFCGFPXQNLV-XApHrRlhytrTU6GhuVR7l378zqCOV2z4r5nXQe75t0ZqEeHJ-HE70PGhV6uD3bdpNhKdGSpZ4jmEV50oWUpWEL_AG-WjJx4E_5KV5BC3Xlno-0i9OYRlQqTmi4eki2_8NQAmJMfZliUoqiukSLyuLk126OJqGVdhiiF7Q2G4i36e1VH9VbyadoLbtfv3OAn87dJjpFJM_TBVb2X9HsA_0NnUIFp8YTYOimmRRA4--PZdlFfND0KSR4TdPlDeQoiKnlAJ-fVeA7eXyvybYqYJwyONpUWZw", "payload": "" } 2024-05-02 16:18:39,553:DEBUG:acme.client:Received response: HTTP 200 Server: nginx Date: Thu, 02 May 2024 14:18:39 GMT Content-Type: application/json Content-Length: 798 Connection: keep-alive Boulder-Requester: 1598501227 Cache-Control: public, max-age=0, no-cache Link: ;rel="index" Replay-Nonce: O0afatDI0RLN73rcITo_-Hrn3IjJ_80RKuQsTqncpUMtaf7q9jk X-Frame-Options: DENY Strict-Transport-Security: max-age=604800 { "identifier": { "type": "dns", "value": "domain.de" }, "status": "pending", "expires": "2024-05-09T14:10:50Z", "challenges": [ { "type": "http-01", "status": "pending", "url": "https://acme-v02.api.letsencrypt.org/acme/chall-v3/345790981617/e0m2DA", "token": "-4gozKMezPVXlBOFkulRMXBDmxXUlwEYdnkEjx8gSak" }, { "type": "dns-01", "status": "pending", "url": "https://acme-v02.api.letsencrypt.org/acme/chall-v3/345790981617/coLV5g", "token": "-4gozKMezPVXlBOFkulRMXBDmxXUlwEYdnkEjx8gSak" }, { "type": "tls-alpn-01", "status": "pending", "url": "https://acme-v02.api.letsencrypt.org/acme/chall-v3/345790981617/2sm9nQ", "token": "-4gozKMezPVXlBOFkulRMXBDmxXUlwEYdnkEjx8gSak" } ] } 2024-05-02 16:18:39,553:DEBUG:acme.client:Storing nonce: O0afatDI0RLN73rcITo_-Hrn3IjJ_80RKuQsTqncpUMtaf7q9jk 2024-05-02 16:18:39,554:INFO:certbot._internal.auth_handler:Performing the following challenges: 2024-05-02 16:18:39,555:INFO:certbot._internal.auth_handler:dns-01 challenge for domain.de ```

EDIT: Only difference i found is, that .de domain is trying way more challenges and stays on status "pending" compared to .com. But all domais are routed to my homelab via dyndns and can be used/pinged & i have used the exact same credentials for both.

.de-challenges

```bash HTTP 200 Server: nginx Date: Thu, 02 May 2024 14:18:39 GMT Content-Type: application/json Content-Length: 798 Connection: keep-alive Boulder-Requester: 1598501227 Cache-Control: public, max-age=0, no-cache Link: ;rel="index" Replay-Nonce: O0afatDI0RLN73rcITo_-Hrn3IjJ_80RKuQsTqncpUMtaf7q9jk X-Frame-Options: DENY Strict-Transport-Security: max-age=604800 { "identifier": { "type": "dns", "value": "domain.de" }, "status": "pending", "expires": "2024-05-09T14:10:50Z", "challenges": [ { "type": "http-01", "status": "pending", "url": "https://acme-v02.api.letsencrypt.org/acme/chall-v3/345790981617/e0m2DA", "token": "-4gozKMezPVXlBOFkulRMXBDmxXUlwEYdnkEjx8gSak" }, { "type": "dns-01", "status": "pending", "url": "https://acme-v02.api.letsencrypt.org/acme/chall-v3/345790981617/coLV5g", "token": "-4gozKMezPVXlBOFkulRMXBDmxXUlwEYdnkEjx8gSak" }, { "type": "tls-alpn-01", "status": "pending", "url": "https://acme-v02.api.letsencrypt.org/acme/chall-v3/345790981617/2sm9nQ", "token": "-4gozKMezPVXlBOFkulRMXBDmxXUlwEYdnkEjx8gSak" } ] } 2024-05-02 16:18:39,553:DEBUG:acme.client:Storing nonce: O0afatDI0RLN73rcITo_-Hrn3IjJ_80RKuQsTqncpUMtaf7q9jk 2024-05-02 16:18:39,554:INFO:certbot._internal.auth_handler:Performing the following challenges: 2024-05-02 16:18:39,555:INFO:certbot._internal.auth_handler:dns-01 challenge for domain.de ```

.com challenges

```bash HTTP 200 Server: nginx Date: Thu, 02 May 2024 15:07:11 GMT Content-Type: application/json Content-Length: 572 Connection: keep-alive Boulder-Requester: 1598501227 Cache-Control: public, max-age=0, no-cache Link: ;rel="index" Replay-Nonce: O0afatDIdLAdBXwvNoaYXhbL05VSQ_hxdNdTa93qwsZcu146X04 X-Frame-Options: DENY Strict-Transport-Security: max-age=604800 { "identifier": { "type": "dns", "value": "domain.com" }, "status": "valid", "expires": "2024-06-01T14:08:39Z", "challenges": [ { "type": "dns-01", "status": "valid", "url": "https://acme-v02.api.letsencrypt.org/acme/chall-v3/345789827577/3hjyKg", "token": "YIgmMMYgKo7si214ERMxND-lVFb80uxq2TIMyoeHJ4k", "validationRecord": [ { "hostname": "domain.com", "resolverAddrs": [ "10.1.12.85:30182" ] } ], "validated": "2024-05-02T14:08:39Z" } ] } ```

markist commented 2 days ago

When requesting wildcard certificates for my .de domain, i´m still running into issues. The cert request just aborts, with no visible error message. This problem only comes up for .de domains, found my .com and .eu domains from same strato account are working fine. Any idea, what could block me here?

Using Nginx Proxy Manager v2.11.1, certbot-dns-strato v0.2.1 Full log of issue

EDIT: Only difference i found is, that .de domain is trying way more challenges and stays on status "pending" compared to .com. But all domais are routed to my homelab via dyndns and can be used/pinged & i have used the exact same credentials for both. .de-challenges .com challenges

Did you finally resolve this for .de domains? Having the same issue here

mwLabs-eu commented 2 days ago

When requesting wildcard certificates for my .de domain, i´m still running into issues. The cert request just aborts, with no visible error message. This problem only comes up for .de domains, found my .com and .eu domains from same strato account are working fine. Any idea, what could block me here?

Using Nginx Proxy Manager v2.11.1, certbot-dns-strato v0.2.1

Full log of issue

EDIT: Only difference i found is, that .de domain is trying way more challenges and stays on status "pending" compared to .com. But all domais are routed to my homelab via dyndns and can be used/pinged & i have used the exact same credentials for both.

.de-challenges

.com challenges

Did you finally resolve this for .de domains? Having the same issue here

Unfortunately not. There where some recommendations later, but i switched to zoraxy in the meanwhile and never looked back. Wildcard ist there not possible for strato but tested it and it looked good. Maybe i will try NPM again in the future.

Edit: Check this out, if Both of your Domains are in the Same Package, it could be this issue. So updating the cert it Plugin to 0.2.2 should fix it.

https://github.com/FlixMa/certbot-dns-strato/issues/3

jclsn commented 2 days ago

With Strato I could solve by adding mydomain.de. as CNAMEAm 20.07.2024 um 09:20 schrieb markist @.***>:

When requesting wildcard certificates for my .de domain, i´m still running into issues. The cert request just aborts, with no visible error message. This problem only comes up for .de domains, found my .com and .eu domains from same strato account are working fine. Any idea, what could block me here? Using Nginx Proxy Manager v2.11.1, certbot-dns-strato v0.2.1 Full log of issue EDIT: Only difference i found is, that .de domain is trying way more challenges and stays on status "pending" compared to .com. But all domais are routed to my homelab via dyndns and can be used/pinged & i have used the exact same credentials for both. .de-challenges .com challenges

Did you finally resolve this for .de domains? Having the same issue here

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>