LetsEncrypt / ACME op intern netwerk

[iGadget]

Na vele, vele uren vruchteloos zoeken, proberen en falen wil ik nu eindelijk mijn interne servertjes kunnen voorzien van een LetsEncrypt certificaat. Ik zie echter door de bomen het bos niet meer.

Ik draai Proxmox op 3 machines met daarop een groeiend aantal VM's en (LXC) containers (waaronder Nextcloud, piHole en nginx-proxy-manager). Ook heb ik een EdgeRouter Lite en een aantal switches (2x HP, 1x QNAP en 1x Ubiquiti).

Belangrijkste om de certs op werkend te krijgen zijn voor mij de PVE hosts, daarna de VM's en containers, de EdgeRouter zou mooi zijn en de switches zijn nice-to-have.

Het gaat om een thuissituatie, dus één publiek IP en dus gelijk de uitdaging dat een directe letsencrypt aanvraag voor slechts één host werkt - de host waar port 80 / 443 op uitkomen vanaf het publieke IP.

Deze gaat nu naar de nginx-proxy-manager container. Werkt op zich, maar deze houdt de certificaten 'voor zichzelf' en 'dwingt' je zo om ook intern alles via deze host te laten lopen. Om diverse redenen vind ik dat niet wenselijk. Daarnaast zie je in de logs van bijv. Nextcloud alleen nog maar het IP van de nginx-proxy-manager, dus fail2ban / crowdsec etc. werkt dan ook niet meer goed. Schijnt weer te fixen te zijn met custom headers, maar ook dat... vele uren aan besteed, nooit werkend gekregen

Dan de DNS challenge-methode. Ik heb een eigen domein maar de partij die dit host biedt geen API functionaliteit voor hun shared-hosting Plesk klanten. Dus de 'pleskxml´ ACME methode die ik bij Proxmox kan aangeven, valt af.
In de Proxmox documentatie lees ik dat je in dat geval nog de 'alias' methode kan gebruiken:

Manually set up a permanent CNAME record for _acme-challenge.domain1.example pointing to _acme-challenge.domain2.example and set the alias property in the Proxmox VE node configuration file to domain2.example to allow the DNS server of domain2.example to validate all challenges for domain1.example.

Klinkt leuk, maar ik heb dus (nog) geen 2e domain provider die wèl API ondersteuning biedt.

Misschien die zelf maar gaan draaien? Hoe dan? Welke software? Op welke plek in mijn netwerk? Zoveel opties...

Dan is er nog de 'acmeproxy'-methode. Klinkt interessant, maar ben inmiddels huiverig om weer vele uren te besteden aan iets om er dan uiteindelijk achter te komen dat het in mijn specifieke(?) geval tòch weer niet gaat werken. Zeker als ik de Github pagina lees heeft dit nogal wat voeten in de aarde.

Tenslotte dan nog de op de Github pagina van acmeproxy genoemde autocertdelegate wat eigenlijk precies klinkt als wat ik wil, maar waarvan ik echt geen flauw idee heb hoe dit op te zetten.

Hoe kom ik uit dit moeras? Zit ik op de goede weg en zijn de dingen waar ik tegenaan loop makkelijk op te lossen? Of moet ik het helemaal anders aanpakken?
Advies meer dan welkom.

[XiMMiX]

iGadget schreef op dinsdag 17 mei 2022 @ 12:39:
Na vele, vele uren vruchteloos zoeken, proberen en falen wil ik nu eindelijk mijn interne servertjes kunnen voorzien van een LetsEncrypt certificaat. Ik zie echter door de bomen het bos niet meer.

Ik draai Proxmox op 3 machines met daarop een groeiend aantal VM's en (LXC) containers (waaronder Nextcloud, piHole en nginx-proxy-manager). Ook heb ik een EdgeRouter Lite en een aantal switches (2x HP, 1x QNAP en 1x Ubiquiti).

Belangrijkste om de certs op werkend te krijgen zijn voor mij de PVE hosts, daarna de VM's en containers, de EdgeRouter zou mooi zijn en de switches zijn nice-to-have.

Het gaat om een thuissituatie, dus één publiek IP en dus gelijk de uitdaging dat een directe letsencrypt aanvraag voor slechts één host werkt - de host waar port 80 / 443 op uitkomen vanaf het publieke IP.

Deze gaat nu naar de nginx-proxy-manager container. Werkt op zich, maar deze houdt de certificaten 'voor zichzelf' en 'dwingt' je zo om ook intern alles via deze host te laten lopen. Om diverse redenen vind ik dat niet wenselijk. Daarnaast zie je in de logs van bijv. Nextcloud alleen nog maar het IP van de nginx-proxy-manager, dus fail2ban / crowdsec etc. werkt dan ook niet meer goed. Schijnt weer te fixen te zijn met custom headers, maar ook dat... vele uren aan besteed, nooit werkend gekregen

Hoe is je DNS setup nu dan, split-brain of publiceer je je interne IPs ook extern?

iGadget schreef op dinsdag 17 mei 2022 @ 12:39:
Dan de DNS challenge-methode. Ik heb een eigen domein maar de partij die dit host biedt geen API functionaliteit voor hun shared-hosting Plesk klanten. Dus de 'pleskxml´ ACME methode die ik bij Proxmox kan aangeven, valt af.
In de Proxmox documentatie lees ik dat je in dat geval nog de 'alias' methode kan gebruiken:
[...]

Klinkt leuk, maar ik heb dus (nog) geen 2e domain provider die wèl API ondersteuning biedt.

Misschien die zelf maar gaan draaien? Hoe dan? Welke software? Op welke plek in mijn netwerk? Zoveel opties...

Als je voor de 2e domein oplossing kiest zul je dat sowieso ergens moeten registeren (en dus kosten maken), dan kan je een registrar kiezen die DNS hosting met API ondersteuning levert. Die zijn bij mijn weten niet duurder. Dan is het niet nodig zelf DNS oid te draaien. Als je een registrar kiest met een API die door de DNS-challenge oplossing van Proxmox/je VMs ondersteund wordt heb je op zich verder niets nodig.

iGadget schreef op dinsdag 17 mei 2022 @ 12:39:
Hoe kom ik uit dit moeras? Zit ik op de goede weg en zijn de dingen waar ik tegenaan loop makkelijk op te lossen? Of moet ik het helemaal anders aanpakken?
Advies meer dan welkom.

Een andere oplossing is een wildcard certificaat maken mbv http-challenge op je enkele publieke IP en datzelfde certificaat op Proxmox/alle VMS gebruiken.

[To_Tall]

@XiMMiX wild card ja idd oplossing zijn maar dan moet je wel elke 3 maanden scripted de certificaten verspreiden.

Misschien is het dan handiger als het toch om intern verkeer gaat een selfsigned certificaat te gebruiken.

Ca opzetten is niet zo heel lastig. Het Root certificaat moet je dan nog wel overal installeren anders krijg je alsnog certificaat errors.

Of anders een commerciële wildcard aanvragen en deze voor 2 of 3 jaar vast leggen en verspreiden.

[Rolfie]

To_Tall schreef op dinsdag 17 mei 2022 @ 18:59:
Of anders een commerciële wildcard aanvragen en deze voor 2 of 3 jaar vast leggen en verspreiden.

Volgens mij mag een certificaat niet langer geldig zijn dan 1 jaar.

@iGadget De beste methode is denk ik toch een nieuw domain te registeren bij een DNS provider die wel API ondersteuning heeft.

[XiMMiX]

To_Tall schreef op dinsdag 17 mei 2022 @ 18:59:
@XiMMiX wild card ja idd oplossing zijn maar dan moet je wel elke 3 maanden scripted de certificaten verspreiden.

tja, je moet sowieso je letsencrypt certificaten telkens vernieuwen, ze vervolgens verspreiden is toch niet zo veel complexer?

To_Tall schreef op dinsdag 17 mei 2022 @ 18:59:
Misschien is het dan handiger als het toch om intern verkeer gaat een selfsigned certificaat te gebruiken.

Ca opzetten is niet zo heel lastig. Het Root certificaat moet je dan nog wel overal installeren anders krijg je alsnog certificaat errors.

Ik heb 10 jaar lang een eigen CA gebruikt. Ik kan het niet aanraden, het gehannes met verspreiden van je root certificaat begon te vervelen, zeker als je niet alleen met je eigen apparaatuur te maken hebt maar ook met die van familie. De druppel voor mij was dat mijn certificaten op zich nog wel een geldigheidsdatum in de toekomst hadden, maar dat de root na 10 jaar was verlopen, kon ik weer handmatig overal mijn nieuwe root installeren.

Rolfie schreef op dinsdag 17 mei 2022 @ 19:03:
[...]
Volgens mij mag een certificaat niet langer geldig zijn dan 1 jaar.

Inderdaad moderne browsers accepteren tegenwoordig niet langer dan 1 jaar.

[iGadget]

Dank voor jullie antwoorden.
@XiMMiX de apparaten op mijn LAN kijken (zoveel mogelijk) naar mijn pi-hole, ik publiceer interne IP's niet extern. Interne hostnames zullen straks extern wel bekend zijn/worden, maar resolven allemaal naar mijn ene externe IP. Heet dat 'split brain'? Weer wat geleerd

Als je voor de 2e domein oplossing kiest zul je dat sowieso ergens moeten registeren (en dus kosten maken), dan kan je een registrar kiezen die DNS hosting met API ondersteuning levert. Die zijn bij mijn weten niet duurder. Dan is het niet nodig zelf DNS oid te draaien. Als je een registrar kiest met een API die door de DNS-challenge oplossing van Proxmox/je VMs ondersteund wordt heb je op zich verder niets nodig.

Heb vanmiddag een account aangemaakt bij 1984.hosting, deze staat er ook tussen bij Proxmox als Challenge Plugin. Echter als ik deze probeer te gebruiken, volgt er een foutmelding 'login failed'. Dus kennelijk is die plugin niet (meer?) compatible oid. Mocht je een (liefst gratis) dienst weten die het wèl doet, please share.

Een andere oplossing is een wildcard certificaat maken mbv http-challenge op je enkele publieke IP en datzelfde certificaat op Proxmox/alle VMS gebruiken.

Klinkt ook best aantrekkelijk, maar security-wise ook wel een beetje spannend. Want houdt dat niet in dat als één apparaat / vm / container gecompromiteerd wordt, meteen alles gecompromiteerd is?
En hoe gaat het verspreiden (en up-to-date houden) van zo'n wildcard in z'n werk? Nog meer handwerk kan ik er echt niet bij hebben namelijk.

Misschien is het dan handiger als het toch om intern verkeer gaat een selfsigned certificaat te gebruiken.

Heb ik ooit ook geprobeerd, maar kreeg dat ook met geen mogelijkheid werkend op de browsers die ik gebruikte. En dit gaat sowieso handwerk zijn denk ik?

De beste methode is denk ik toch een nieuw domain te registeren bij een DNS provider die wel API ondersteuning heeft.

Heb nu dus een (sub)domein via 1984.hosting lopen. Extern resolven werkt, maar de ACME challenge plugin dus (nog?) niet, zie boven. Hoor graag of jullie aanbieders weten bij wie het wèl werkt, voordat ik weer uren besteed aan het optuigen van accounts en doorverwijzingen om er daarna achter te komen dat ze (ws.) de API hebben gesloop... eh... geupdate

tja, je moet sowieso je letsencrypt certificaten telkens vernieuwen, ze vervolgens verspreiden is toch niet zo veel complexer?

Dat zou Proxmox dus in principe helemaal zelf kunnen doen (hoe heerlijk!) zodra ik ACME aan de praat krijg.

Ik heb 10 jaar lang een eigen CA gebruikt. Ik kan het niet aanraden,

Dank, dat scheelt weer één mogelijke doodlopende weg.

[Frogmen]

Wat je zou kunnen doen op je Nginx server alle certificaten aan laten maken en deze met een cron job dagelijks distribueren naar je interne servers hebben ze allemaal nette certificaten. Het is maar een idee.

[deHakkelaar]

Frogmen schreef op dinsdag 17 mei 2022 @ 20:14:
Wat je zou kunnen doen op je Nginx server alle certificaten aan laten maken en deze met een cron job dagelijks distribueren naar je interne servers hebben ze allemaal nette certificaten. Het is maar een idee.

$ man certbot
[..]
            --pre-hook PRE_HOOK   Command to be run in a shell before obtaining any
                                  certificates. Intended primarily for renewal, where it
                                  can be used to temporarily shut down a webserver that
                                  might conflict with the standalone plugin. This will
                                  only be called if a certificate is actually to be
                                  obtained/renewed. When renewing several certificates
                                  that have identical pre-hooks, only the first will be
                                  executed. (default: None)
            --post-hook POST_HOOK
                                  Command to be run in a shell after attempting to
                                  obtain/renew certificates. Can be used to deploy
                                  renewed certificates, or to restart any servers that
                                  were stopped by --pre-hook. This is only run if an
                                  attempt was made to obtain/renew a certificate. If
                                  multiple renewed certificates have identical post-
                                  hooks, only one will be run. (default: None)
            --deploy-hook DEPLOY_HOOK
                                  Command to be run in a shell once for each
                                  successfully issued certificate. For this command, the
                                  shell variable $RENEWED_LINEAGE will point to the
                                  config live subdirectory (for example,
                                  "/etc/letsencrypt/live/example.com") containing the
                                  new certificates and keys; the shell variable
                                  $RENEWED_DOMAINS will contain a space-delimited list
                                  of renewed certificate domains (for example,
                                  "example.com www.example.com" (default: None)

[Thralas]

iGadget schreef op dinsdag 17 mei 2022 @ 20:05:
Mocht je een (liefst gratis) dienst weten die het wèl doet, please share.

Vultr heeft gratis nameservers / DNS hosting en heeft een API. Dat wordt niet ondersteund in certbot, maar wel door lego. Die ondersteunt overigens weer zoveel providers dat er vast nog andere gratis alternatieven zijn.

Klinkt ook best aantrekkelijk, maar security-wise ook wel een beetje spannend. Want houdt dat niet in dat als één apparaat / vm / container gecompromiteerd wordt, meteen alles gecompromiteerd is?

Wat bedoel je met 'meteen alles gecompromitteerd'? Je bent dan een wildcardcertificaat kwijt. Dat klinkt heel erg, maar ik heb nog nooit een aanwijzing gezien dat iemand geïnteresseerd is in wildcard (of uberhaupt SSL-certificaten) van willekeurige (let op, keyword) gebruikers. Bovendien kan iemand die bij je wildcard kan ook nieuwe (non-wildcard) certificaten issuen: het wildcard-aspect is het probleem zeker niet.

Als een container 'gecompromitteerd' wordt dan is 'ie in de praktijk onderdeel van een dDoS-botnet of is hij bitcoins aan het minen. Meer niet. En daarvoor geldt: als je al je interne services achter een VPN plaatst (zoals je zou moeten doen) dan is de kans daarop ook nul.

En hoe gaat het verspreiden (en up-to-date houden) van zo'n wildcard in z'n werk? Nog meer handwerk kan ik er echt niet bij hebben namelijk.

Dat is het mooie van IT: automatiseren. Je kunt een cronjob of systemd timer gebruiken of de optie die hierboven wordt gegeven (iets van een deploy hook) afhankelijk van of je een push of pull-model wil hanteren.

[Ruben279]

To_Tall schreef op dinsdag 17 mei 2022 @ 18:59:
Of anders een commerciële wildcard aanvragen en deze voor 2 of 3 jaar vast leggen en verspreiden.

Bij commerciele partijen kan je wel certificaten aanvragen voor meerdere jaren, maar dan krijg je elk jaar een nieuwe.
Sinds 1 september 2021 accepteren Chrome (Edge etc.), Firefox, Safari en de meeste andere browsers geen certificaten meer die langer geldig zijn dan 1 jaar.

Enigste voordeel is nog dat je wel je wat korting krijgt bij het afnemen van meerdere jaren.

[Andre-85]

iGadget schreef op dinsdag 17 mei 2022 @ 12:39:
[...]

Het gaat om een thuissituatie, dus één publiek IP en dus gelijk de uitdaging dat een directe letsencrypt aanvraag voor slechts één host werkt - de host waar port 80 / 443 op uitkomen vanaf het publieke IP.

[...]

Niet perse, je kan een reverse proxy toepassen. Ik gebruik https://github.com/dlundquist/sniproxy voor een paar services op mijn thuis netwerk.

[lasermen]

Wellicht heb je hier wat aan? https://www.bounca.org/
Hiermee kan je zelf makkelijk een interne CA aanmaken, zonder dat je zelf met openssl aan de gang moet gaan.
We hadden hetzelfde probleem met interne diensten en hebben het hiermee opgelost. Vooral omdat LetsEncrypt interne adressen niet zo tof vind/vond. Het enige is wel dat je eigen CA moet installeren bij de apparaten waarmee je interne diensten bezoekt.

[SlinkingAnt]

iGadget schreef op dinsdag 17 mei 2022 @ 20:05:
Mocht je een (liefst gratis) dienst weten die het wèl doet, please share.

Ik heb mijn DNS-beheer bij Cloudflare, die doen dit gewoon gratis en hebben een API die goed ondersteund wordt door ACME.

Zo heb ik zowel mijn UDM-Pro als Freenas-doos voorzien van een publiek-geldig certificaat.
De interne DNS-server verwijst gewoon naar het lokale IP, dus de machines zijn niet publiekelijk toegankelijk. Extern bestaan de DNS-namen niet .

[DataGhost]

Voor meerdere interne services achter hetzelfde IP en dezelfde poort ontkom je inderdaad niet aan een proxy. Die proxy kan prima bijv. de http-01 forwarden naar je interne hosts dus kan je de certificaten daarop aanvragen en ook daar bewaren. Blijft nog het dingetje over van daarna verbinden over HTTPS want daar heb je inderdaad de certificaten voor nodig. Ik heb deze configuratie-optie persoonlijk nog nooit gebruikt, maar volgens mij kan je dat met ssl_preread in nginx doen. Dan wordt bij het doen van de handshake de verbinding al doorgegeven naar de eigenlijke host die het certificaat heeft, zo hoeven ze niet allemaal op je proxy te staan. Tenminste, zo heb ik het begrepen, ik weet niet zeker of het ook zo werkt in de praktijk.

Je houdt dan wel het probleem dat je op de machines zelf inderdaad alleen het IP van je proxy te zien krijgt. Een enige manier om dat "op te lossen" is de certificaten toch allemaal op je proxy te houden en het eigenlijke IP in forward-headers mee te laten geven die je vervolgens logt in plaats van het normale IP. Een andere manier kan liggen in proxy_protocol maar dat hangt een beetje van je achterliggende services af. Een betere oplossing kan IPv6 zijn, of dat is in ieder geval een oplossing die je prima naast de ssl_preread-methode kan gebruiken, want die requests hoeven niet via je proxy.

[Voor 4% gewijzigd door DataGhost op 18-05-2022 15:13]

[iGadget]

Na maanden van andere prioriteiten, nu eindelijk weer tijd om dit op te pakken.
Ben inmiddels een klein beetje verder, in de zin dat ik erachter ben waarom de 1984.hosting ACME plugin in Proxmox niet werkt - dit komt door verouderde host info in /usr/share/proxmox-acme/dnsapi/dns_1984hosting.sh, bron

Na alle management.1984hosting.com entries in dat bestand vervangen te hebben door 1984.hosting, werkt de plugin wel. Althans - de ACME DNS challenge TXT entry wordt tijdens het draaien van het script aangemaakt bij 1984.hosting (kan dit zien in de webinterface).

Daarna gaat er echter weer iets mis (mijn feitelijke domein hier vervangen door 'my-redacted-domain'):

code:

Loading ACME account details
Placing ACME order
Order URL: https://acme-staging-v02.api.letsencrypt.org/acme/order/66542803/3857977533

Getting authorization details from 'https://acme-staging-v02.api.letsencrypt.org/acme/authz-v3/3485842723'
The validation for my-redacted-domain is pending!
[Tue Aug 30 20:39:32 CEST 2022] Add TXT record using 1984Hosting
[Tue Aug 30 20:39:35 CEST 2022] Added acme challenge TXT record for _acme-challenge.my-redacted-domain at 1984Hosting
Add TXT record: _acme-challenge.my-redacted-domain
Sleeping 30 seconds to wait for TXT record propagation
Triggering validation
Sleeping for 5 seconds
[Tue Aug 30 20:40:11 CEST 2022] Delete TXT record using 1984Hosting
[Tue Aug 30 20:40:15 CEST 2022] Deleted acme challenge TXT record for _acme-challenge.my-redacted-domain at 1984Hosting
Remove TXT record: _acme-challenge.my-redacted-domain
TASK ERROR: validating challenge 'https://acme-staging-v02.api.letsencrypt.org/acme/authz-v3/3485842723' failed - status: invalid

Ik heb werkelijk geen flauw idee waar dit nu op vastloopt. Wat ik al heb geprobeerd / gecheckt:

• Gecontroleerd of de ACME TXT record wordt aangemaakt bij 1984hosting - ik zie 'm verschijnen als het script wordt gestart en weer verdwijnen als het script is afgerond
• Gecheckt of de domeinnaam waar ik het certificaat voor probeer te krijgen, resolved - dit werkt zowel intern als extern
• De interne DNS verwijzing van mijn PVE node gewijzigd van het interne IP naar het externe IP - maakt geen verschil

Wat kan ik nog meer checken / proberen?