SSL certificaat voor meerdere devices

[joostdejonge123]

Beste Tweakers,

Inmiddels heb ik best veel devices en services in mijn interne netwerk draaien. De meeste via een beveiligde webinterface, hierbij krijg ik dus melding dat de verbinding niet veilig is. Nu is dat op mijn interne netwerk, dus dat maakt me op zich niet veel uit, maar ik irriteer me er wel een beetje aan... het volgende heb ik werkende:

1. Ik heb inmiddels een letsencrypt wildcard SSL voor mijn eigen domein *.example.nl
2. Voor mijn eigen domein naam, example.nl, heb ik diverse a-records aangemaakt (server.example.nl, printer.example.nl), die naar een intern ip-adres verwijzen
3. Als ik deze certificaten handmatig installeer, dan werkt het allemaal prima. Echter verloopt dit certificaat altijd na 90 dagen, en kan ik weer van voren af aan beginnen...

Het liefste wil ik dat op een centrale plek het certificaat bijvoorbeeld elke 60 dagen wordt vernieuwd, en vervolgens wordt gepushed naar alle devices en services (proxmox/printers/scanner/immich/nas/docker/etc...).

Is zoiets mogelijk? Of blijft het handmatig werk elke 90 dagen? Of gewoon niet zeuren en de foutmeldingen laten voor wat het is?

Super veel dank!

[MarchelHoek]

Of een wildcard certificaat aanschaffen die een jaar geldig is.

Via https://sslcertificaten.nl bijvoorbeeld

[gwabber]

Dit zou je kunnen oplossen door op elk device certbot te laren draaien die alles automatisch ververst, of je laat alles verlopen via een reverse proxy zoals Nginx reverse proxy (manager)

[joostdejonge123]

Dank!

Dat Certbot is wel een goeie ja, misschien dat eens proberen.

Nginx ken ik niet, moet ik uitzoeken wat dat doet.

[The_Admin]

Nginx proxy manager is precies wat je zoekt

[Raven]

@joostdejonge123 * Raven gebruikt certbot i.c.m. een aantal bash-scripts die de DNS-verificatie doen bij mijn (externe) hostingpartij, om daarna de certificaten op verschillende apparaten te importeren.

Duurde wel even voordat ik dat goed werkend had

[ElCondor]

NginX Proxy kan, maar wat je eventueel in die lijn zoekt is een 'reverse proxy'. Die zijn er in meer smaken, waarvan NginX er een van is. een andere mogelijkheid is Traefik en zelfs IIS zou het kunnen doen, mocht je een Windows server hebben draaien
Wat een reverse proxy mogelijk maakt is al het web verkeer via één punt in je netwerk te laten lopen en daar kun je dan een TLS/SSL certificaat op draaien. Daarmee zijn dan alle achterliggende sites beveiligd.

[nelizmastr]

Nginx Proxy Manager is een reverse proxy op docker met een eenvoudig te gebruiken web interface. Makkelijker dan traefik en heeft geen speciale configuratie nodig. Proxy hosts aanmaken, certificaat inkloppen en klaar.

[Frogmen]

Reverse proxy om een een beveiligde verbinding in je interne netwerk te maken slaat natuurlijk eigenlijk nergens op. Het enige is het ziet er beter uit. Dan vindt ik de oplossing van @Raven een heel stuk fraaier.

[MasterL]

Als het alleen intern is waarom draai je dan geen interne CA?

[CAPSLOCK2000]

joostdejonge123 schreef op woensdag 18 december 2024 @ 21:41:

Het liefste wil ik dat op een centrale plek het certificaat bijvoorbeeld elke 60 dagen wordt vernieuwd, en vervolgens wordt gepushed naar alle devices en services (proxmox/printers/scanner/immich/nas/docker/etc...).

Hoe beheer je je apparaten? Heb je iets van configuratiebeheer om die certificaten mee naar de devices te pushen? Iets als Puppet of Ansible?
Als je alles handmatig beheert is de eerste stap om een of ander beheerssysteem te nemen om alles mee aan te sturen, anders blijf je bezig.


Ik gebruik net als Raven DNS-verificatie omdat ik die centraal kan doen op mijn mgmt-server. Die stuurt dan naar alle vm's en services die een certificaat nodig hebben, voornamelijk via Puppet.

[joostdejonge123]

Dank voor alle informatie, allemaal nieuw voor me.

Pushen van certificaten vind ik wel een erg mooie, Puppet ga ik ook naar kijken.

Ik hou jullie op de hoogte...

En inderdaad, echt nodig voor een lokaal netwerk is het natuurlijk niet, maar ik vind het wel leuk om het uit te zoeken of het mogelijk is...

[joostdejonge123]

MasterL schreef op donderdag 19 december 2024 @ 16:00:
Als het alleen intern is waarom draai je dan geen interne CA?

Maar moet ik dan niet op elke computer in mijn netwerk certificaten accepteren?

[pennywiser]

MasterL schreef op donderdag 19 december 2024 @ 16:00:
Als het alleen intern is waarom draai je dan geen interne CA?

Doen mensen dit nog nu er Letsencypt is? Is zo'n gedoe. Letsencrypt kent ook wildcards.

[pennywiser]

joostdejonge123 schreef op vrijdag 20 december 2024 @ 11:10:
[...]


Maar moet ik dan niet op elke computer in mijn netwerk certificaten accepteren?

Ja dmv CA importeren, maar gebruik gewoon Letsencrypt en automatiseer vervolgens met Certbot de verlenging.

[pennywiser]

ElCondor schreef op donderdag 19 december 2024 @ 08:05:
NginX Proxy kan, maar wat je eventueel in die lijn zoekt is een 'reverse proxy'. Die zijn er in meer smaken, waarvan NginX er een van is. een andere mogelijkheid is Traefik en zelfs IIS zou het kunnen doen, mocht je een Windows server hebben draaien
Wat een reverse proxy mogelijk maakt is al het web verkeer via één punt in je netwerk te laten lopen en daar kun je dan een TLS/SSL certificaat op draaien. Daarmee zijn dan alle achterliggende sites beveiligd.

Apache mod proxy. Nginx Proxy Manager is wat jij omschrijft, maar dan containerized.

[RiDo78]

joostdejonge123 schreef op vrijdag 20 december 2024 @ 11:10:
[...]


Maar moet ik dan niet op elke computer in mijn netwerk certificaten accepteren?

Ja en nee.

Ja: je zet een interne CA op en die heeft een root-certificate. Die moet je op al je computers installeren. Maar die is standaard vele jaren geldig, dus dat is -min-of-meer- een eenmalige actie.

Nee: eens de root certificate op al je computers staat, dan vertrouwen die alle certificaten die zijn ondertekend door de rootcertificate van je interne CA. Dus als je van de week een nieuw speeltje onder de boom vindt, dan maak je daar een certificaat voor die je laat ondertekenen door je interne CA en klaar.

[ Voor 4% gewijzigd door RiDo78 op 20-12-2024 11:26 ]

[coolkil]

gwabber schreef op woensdag 18 december 2024 @ 21:47:
Dit zou je kunnen oplossen door op elk device certbot te laren draaien die alles automatisch ververst, of je laat alles verlopen via een reverse proxy zoals Nginx reverse proxy (manager)

Op elk device certbot vereist wel dat je ergens een http 80 poort open zet en dat bereikbaar hebt voor Letsencrypt

Of als je voor dns challenge gaat je overal api credentials voor je dns moet opslaan…

Daarnaast lek je je interne netwerk structuur op een publieke dns server.

[MasterL]

pennywiser schreef op vrijdag 20 december 2024 @ 11:14:
[...]

Doen mensen dit nog nu er Letsencypt is? Is zo'n gedoe. Letsencrypt kent ook wildcards.

Het probleem is alleen dat TS in zijn DNS heeft ingesteld dat public domains naar zijn "interne" DNS verwijst dus certbot kan deze certificaten nooit vernieuwen aangezien deze niet publiek benaderbaar zijn.
Ik ga er voor het gemak even vanuit dat er geen poorten o.i.d. open staan naar het interne netwerk dus certbot kan dus ook nooit automatisch vernieuwen.

Buiten dat is het natuurlijk een slordige oplossing om records aan te maken op een public domain welke verwijzen naar private IP adressen.

Als je het netjes wil doen heb je IMO 2 opties:

1: Gebruik een local domain en draai een eigen CA.
2: Gebruik een public domain, gebruik public IP's met (loopback) NAT naar bijvoorbeeld een reverse proxy en installeer een "echt" certificaat dit kan dan met Letsencypt of een gekocht certificaat.

[pennywiser]

MasterL schreef op vrijdag 20 december 2024 @ 14:43:
[...]


Het probleem is alleen dat TS in zijn DNS heeft ingesteld dat public domains naar zijn "interne" DNS verwijst dus certbot kan deze certificaten nooit vernieuwen aangezien deze niet publiek benaderbaar zijn.
Ik ga er voor het gemak even vanuit dat er geen poorten o.i.d. open staan naar het interne netwerk dus certbot kan dus ook nooit automatisch vernieuwen.

Buiten dat is het natuurlijk een slordige oplossing om records aan te maken op een public domain welke verwijzen naar private IP adressen.

Als je het netjes wil doen heb je IMO 2 opties:

1: Gebruik een local domain en draai een eigen CA.
2: Gebruik een public domain, gebruik public IP's met (loopback) NAT naar bijvoorbeeld een reverse proxy en installeer een "echt" certificaat dit kan dan met Letsencypt of een gekocht certificaat.

.local domeinen moet je echt een keer afschaffen. Eigen CA echt serieus wie doet dit privaat. De meeste bedrijven hebben intussen iets zoals firmanaaminternal.com draaien. Reverse proxy alles laten regelen kan ook.

[coolkil]

Het kan prima met een letsencrypt wildcard. Je resolved op je publieke dns gewoon netjes een txt record.

Op 1 interne host doe je renewal met de dns challenge en distribueer je het certificaat met ansible (push methode) of je zet het op een nfs of iets dergelijks en laat de cliënts het certificaat ophalen (pull methode)

Beide hebben voor en nadelen ansible vereist dr de renew host een ssh connectie van doen en privilege’s heeft

De nfs share is potentieel een klein security risico omdat iemand je certificaat zou kunnen stelen( zie zelf in home lab situatie niet zo snel een issue)

Dan ga ik er wel een beetje van uit dat alle target systemen niet alleen een gui upload functie hebben voor certificaten.

[ Voor 9% gewijzigd door coolkil op 20-12-2024 14:55 ]

[servies]

Ik gebruik een wildcard van Let's Encrypt. Je DNS provider moet het overigens ook ondersteunen.
Die wildcard wordt 1x in de bijna 3 maand vernieuwd door de certbot applicatie en op de goede plek op m'n server gezet.
Hierna wordt de certificaten door een cronjob gekopieerd naar de verschillende systemen die er ook gebruik van maken en de desbetreffende services worden herstart.

[pennywiser]

servies schreef op vrijdag 20 december 2024 @ 14:54:
Je DNS provider moet het overigens ook ondersteunen.

Indien niet move je je zone naar Cloudflare (gratis account optie) en kan het alsnog.

[coolkil]

Of als je provider een api heeft knutsel je zelf wat met de manual hook optie van certbot

[holygame]

Gebruik ACME icm Let's Encrypt certs.

[pennywiser]

coolkil schreef op vrijdag 20 december 2024 @ 14:58:
Of als je provider een api heeft knutsel je zelf wat met de manual hook optie van certbot

Dan ondersteunt die provider het toch?

[coolkil]

Je hebt ook supported plug-ins voor certbot ik dacht dat dat bedoeld werd

https://eff-certbot.readt...le/using.html#dns-plugins

[ Voor 35% gewijzigd door coolkil op 20-12-2024 15:04 ]

[MasterL]

pennywiser schreef op vrijdag 20 december 2024 @ 14:54:
[...]

.local domeinen moet je echt een keer afschaffen. Eigen CA echt serieus wie doet dit privaat. De meeste bedrijven hebben intussen iets zoals firmanaaminternal.com draaien. Reverse proxy alles laten regelen kan ook.

Ik ben het echt niet oneens met je maar als ik dingen lees als "proxmox/printers/scanner/immich/nas/docker/etc" hebben we het niet perse over een enterprise omgeving...
In hoeverre is het reëel om zaken te pushen/scripten en/of certbot te draaien op printers/scanners/nas?

Als je dit centraal doet op een reverse proxy is dit natuurlijk prima te managen maar decentraal op al deze devices? Ik zou er niet aan beginnen. Vandaar mijn alternatief voor een CA technisch echt niet ingewikkeld en een eenmalige actie. Misschien een hiaat in mijn kennis maar hoe zou jij zoiets doen? Gegeven dat:
- A records verwijzen naar interne IP-adressen (dus niet publiek bereikbaar).
- (Aanname) geen open poorten richting interne netwerk.
- (Aanname) waarschijnlijk niet elk device de mogelijkheid heeft tot scripting/certbot.

[pennywiser]

MasterL schreef op vrijdag 20 december 2024 @ 15:50:
[...]


Ik ben het echt niet oneens met je maar als ik dingen lees als "proxmox/printers/scanner/immich/nas/docker/etc" hebben we het niet perse over een enterprise omgeving...
In hoeverre is het reëel om zaken te pushen/scripten en/of certbot te draaien op printers/scanners/nas?

Als je dit centraal doet op een reverse proxy is dit natuurlijk prima te managen maar decentraal op al deze devices? Ik zou er niet aan beginnen. Vandaar mijn alternatief voor een CA technisch echt niet ingewikkeld en een eenmalige actie. Misschien een hiaat in mijn kennis maar hoe zou jij zoiets doen? Gegeven dat:
- A records verwijzen naar interne IP-adressen (dus niet publiek bereikbaar).
- (Aanname) geen open poorten richting interne netwerk.
- (Aanname) waarschijnlijk niet elk device de mogelijkheid heeft tot scripting/certbot.

Ja agreed, soho KA, dat wordt dus al vrij snel handwerk. Ook met een eigen CA, grote kans dat de firmware Letsencrypt inmiddels ondersteunt? Geen ervaring met KA icm SSL.

Wat betreft challenge zijn meerdere opties.

Op mijn platform laat ik Cloudflare de LE api regelen en zet ik de (widlcard) certificaten met sftp waar ze moeten zijn + reload service.

[MasterL]

Duidelijk. Er zit met dat betreft ook helemaal geen verschil in LE of een eigen CA buiten het feit dat LE een (vastgestelde) geldigheid heeft en een eigen CA een zelf bepaalde geldigheid (5j+?) heeft. Als alles te automatiseren valt ga lekker voor LE no questions asked. Mocht automatiseren van de certificaten lastig zijn door een gebrek aan de mogelijkheden voor automatisering/scripting en/of het draaien van een reverse proxy zou ik er nog eens over nadenken.

[joostdejonge123]

MasterL schreef op vrijdag 20 december 2024 @ 15:50:
[...]


Ik ben het echt niet oneens met je maar als ik dingen lees als "proxmox/printers/scanner/immich/nas/docker/etc" hebben we het niet perse over een enterprise omgeving...
In hoeverre is het reëel om zaken te pushen/scripten en/of certbot te draaien op printers/scanners/nas?

Als je dit centraal doet op een reverse proxy is dit natuurlijk prima te managen maar decentraal op al deze devices? Ik zou er niet aan beginnen. Vandaar mijn alternatief voor een CA technisch echt niet ingewikkeld en een eenmalige actie. Misschien een hiaat in mijn kennis maar hoe zou jij zoiets doen? Gegeven dat:
- A records verwijzen naar interne IP-adressen (dus niet publiek bereikbaar).
- (Aanname) geen open poorten richting interne netwerk.
- (Aanname) waarschijnlijk niet elk device de mogelijkheid heeft tot scripting/certbot.

Je drie punten kloppen inderdaad helemaal, en het is puur gehobby, om niet elke keer meldingen te krijgen over missende certificaten...

Linux servers krijg ik nog wellicht werkende met automatische updates, overige apparaten gaat wel lastiger worden denk ik.

[joostdejonge123]

Even een update...inmiddels lijkt het allemaal met nginx te werken zoals ik wil! Super bedankt voor alle hulp.