[mijn.host] DNS Challenge mislukt voor Let's Encrypt

[Saekerhett]

Ik heb een domeinnaam bij mijn.host geregistreerd en deze verwijst door naar mijn interne TrueNAS ip waar vervolgens allemaal dockers op draaien, waaronder Nginx Proxy Manager. Daarin heb ik vervolgens allemaal subdomeinen aangemaakt en reverse proxy's ingesteld. Als ik voor deze subdomeinen apart een Let's Encrypt certificaat aanvraag, gaat het goed, maar als ik een wildcard probeer aan te vragen, gaat het mis. En omdat ik best aan het spelen ben met heel veel dockers, lijkt het me handig om een keer een wildcard certificaat te hebben, zodat ik niet voor elk subdomein een apart certificaat hoef aan te vragen.

Ik begin met de volgende instelling:



De verwijzing in de 'Credentials File Content' is standaard zo ingesteld als je 'mijn.host' uit de DNS Provider lijst erboven kiest.

Als ik in TrueNAS een shell open in Nginx, dus in Docker, heb ik het volgende ingesteld:



De inhoud van 'mijnhost-credentials.ini' heb ik zo neergezet omdat iets vergelijkbaars hier werd benoemd:

https://github.com/mijnhost/certbot-dns-mijn-host


En toch krijg ik dan een error als ik hem wil registreren:

code:

CommandError: Saving debug log to /tmp/letsencrypt-log/letsencrypt.log
No API key provided
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.

    at /app/lib/utils.js:16:13
    at ChildProcess.exithandler (node:child_process:430:5)
    at ChildProcess.emit (node:events:519:28)
    at maybeClose (node:internal/child_process:1105:16)
    at Socket. (node:internal/child_process:457:11)
    at Socket.emit (node:events:519:28)
    at Pipe. (node:net:339:12)

Volgens mij moet het gewoon in de GUI van Nginx Proxy Manager kunnen, maar gezien de 'No API key provided' lijkt het me dat hier ergens de crux zit, ik doe vast wat fout met de file waarin de API key staat.

Zou iemand mij op weg kunnen helpen? Ik heb het idee dat ik er bijna ben, maar het laatste stapje ontbreekt.

[ Voor 5% gewijzigd door Saekerhett op 11-12-2024 08:58 ]

[vormulier]

Als je toch met docker aan de gang bent, er is een mijn.host docker image voor letsnencrypt. (al zit er een andere bug aan vast)

Hoe ziet je command line er uit?
Je zal wel iets van:

code:

--dns-mijn-host-credentials

Mee moeten geven

[vormulier]

Als je trouwens een ls -lah doet op de folder heeft het bestand de juiste permissies?

[Saekerhett]

vormulier schreef op woensdag 11 december 2024 @ 09:00:
Als je toch met docker aan de gang bent, er is een mijn.host docker image voor letsnencrypt. (al zit er een andere bug aan vast)

Hoe ziet je command line er uit?
Je zal wel iets van:

code:

--dns-mijn-host-credentials

Mee moeten geven

Ok, waar zou ik dit mee moeten geven? Moet dit bij de installatie van Nginx op TrueNAS of zo?

vormulier schreef op woensdag 11 december 2024 @ 09:02:
Als je trouwens een ls -lah doet op de folder heeft het bestand de juiste permissies?

Dat geeft:

code:

drwxrwx--- 13 npm  npm       16 Dec 11 08:40 letsencrypt

Oh wacht, de file zelf heeft:

code:

-rwxr--r--  1 npm  npm    57 Nov 13 16:58 mijnhost-credentials.ini

Zou daar het probleem zitten?

[ Voor 9% gewijzigd door Saekerhett op 11-12-2024 09:07 ]

[vormulier]

Saekerhett schreef op woensdag 11 december 2024 @ 09:05:
[...]
Ok, waar zou ik dit mee moeten geven? Moet dit bij de installatie van Nginx op TrueNAS of zo?

Mijn ochtend ogen zien dat je alles via de GUI doet. Dan zal dit automagisch goed moeten gaan.

code:

drwxrwx--- 13 npm  npm       16 Dec 11 08:40 letsencrypt

En de inhoud van de folder ? Het doel is om te kijken of je ini file (die is nu groen) de juiste permissies heeft.
Allicht heeft de npm user geen rechten om je bestand te lezen?

[Saekerhett]

vormulier schreef op woensdag 11 december 2024 @ 09:09:
[...]

Mijn ochtend ogen zien dat je alles via de GUI doet. Dan zal dit automagisch goed moeten gaan.


[...]


En de inhoud van de folder ? Het doel is om te kijken of je ini file (die is nu groen) de juiste permissies heeft.
Allicht heeft de npm user geen rechten om je bestand te lezen?

Zie edit

[vormulier]

Dat ziet er snor uit

Vaag dat je probleem ook aleen met een * domein is. Mijn docker compose zier er zo uit en dat werkt als een zonnetje:

code:

docker run -it --rm \
  -v /opt/containers/certbot:/certbot \
  private/mijnhostletsencrypt \
  certbot certonly -n \
  --authenticator dns-mijn-host \
  --dns-mijn-host-credentials /certbot/mijnhost.ini \
  --dns-mijn-host-propagation-seconds 60 \
  --agree-tos \
  --rsa-key-size 4096 \
  --config-dir /certbot/workdir/etc/letsencrypt \
  --work-dir /certbot/workdir/var/lib/letsencrypt \
  --logs-dir /certbot/workdir/var/log/letsencrypt \
  -d '*.email.com' \
  -m [e-mail] \
  --eff-email

Allicht heb je een gekke bug te pakken in TrueNas?

[Saekerhett]

vormulier schreef op woensdag 11 december 2024 @ 09:18:
Dat ziet er snor uit

Vaag dat je probleem ook aleen met een * domein is. Mijn docker compose zier er zo uit en dat werkt als een zonnetje:

code:

docker run -it --rm \
  -v /opt/containers/certbot:/certbot \
  private/mijnhostletsencrypt \
  certbot certonly -n \
  --authenticator dns-mijn-host \
  --dns-mijn-host-credentials /certbot/mijnhost.ini \
  --dns-mijn-host-propagation-seconds 60 \
  --agree-tos \
  --rsa-key-size 4096 \
  --config-dir /certbot/workdir/etc/letsencrypt \
  --work-dir /certbot/workdir/var/lib/letsencrypt \
  --logs-dir /certbot/workdir/var/log/letsencrypt \
  -d '*.email.com' \
  -m [e-mail] \
  --eff-email

Allicht heb je een gekke bug te pakken in TrueNas?

toon volledige bericht

Bedankt voor het meedenken in elk geval. Is de inhoud van jouw 'mijnhost.ini' op dezelfde manier neergezet als mijn 'mijnhost-credentials.ini'?

[vormulier]

Die ziet er inderdaad ook zo uit:

code:

dns_mijn_host_api_key = superGeheimBeepBoop

[Saekerhett]

Ik heb als test even de mijnhost-credentials.ini hernoemd naar iets anders en de foutmelding blijft hetzelfde. Om permissies helemaal uit te sluiten heb ik ook nog een chmod 777 gedaan zonder resultaat. Ik gok dus dat Nginx op de verkeerde locatie zoekt naar de file en/of inhoud. Effe verder puzzelen, als iemand nog goede ideeën heeft hoor ik het graag.

[Maykz0r]

Saekerhett schreef op woensdag 11 december 2024 @ 18:17:
Ik heb als test even de mijnhost-credentials.ini hernoemd naar iets anders en de foutmelding blijft hetzelfde. Om permissies helemaal uit te sluiten heb ik ook nog een chmod 777 gedaan zonder resultaat. Ik gok dus dat Nginx op de verkeerde locatie zoekt naar de file en/of inhoud. Effe verder puzzelen, als iemand nog goede ideeën heeft hoor ik het graag.

Bij mij werkte het nadat ik de inhoud van de ini file in het "Credentials File Content *" had gestopt. Dus ik denk dat hij niet een bestand wil inlezen maar de inhoud van het bestand wil hebben in het invoerveld.

[Saekerhett]

Maykz0r schreef op dinsdag 17 december 2024 @ 18:50:
[...]


Bij mij werkte het nadat ik de inhoud van de ini file in het "Credentials File Content *" had gestopt. Dus ik denk dat hij niet een bestand wil inlezen maar de inhoud van het bestand wil hebben in het invoerveld.

Dit werkt inderdaad

[Maykz0r]

Goed om te horen, veel plezier ermee :-D

Ik ben ook blij met die nieuwe bot. Ik had voorheen alles opgezet met een mijn.domein VPS in combinatie met BIND9 en een wireguard tunnel naar m’n server thuis. Daar draait nginx proxy manager.
Bind9 kan je configureren om de RFC2136 dns provider optie in nginx proxy manager te gebruiken. De certbot van mijn.host doet min of meer hetzelfde maar dan een stuk eenvoudiger.

Ik kwam er wel achter dat je nog geen wildcard certificaten kan aanvragen op subdomeinen e.g. *.huis.domein.nl.
Iemand anders was dit ook al opgevallen en er staat een pull request voor open op GitHub. Hopelijk vind het zijn weg binnenkort in de mijn-host-certbot https://github.com/mijnhost/certbot-dns-mijn-host/pull/5.