(Geautomatiseerd) valide SSL certificaat op UDM Pro of SE

[Davey400]

Natuurlijk weet ik dat je de certificaat-meldingen gewoon aan clientzijde kunt onderdrukken, of gebruik kunt maken van de route buitenom (https://unifi.ui.com/) om geen last te hebben van ontbrekende of invalide certificaten, maar ik wil dat eigenlijk gewoon structureel en bij voorkeur geautomatiseerd netjes oplossen.

Even snel zoeken bracht me bij deze 2 projecten om e.e.a. te realiseren, maar ben er nog niet verder ingedoken.

GitHub - kchristensen/udm-le: Let's Encrypt support for Ubiquiti UniFi OS

Let's Encrypt support for Ubiquiti UniFi OS. Contribute to kchristensen/udm-le development by creating an account on GitHub.

github.com

GitHub - alxwolf/ubios-cert: Manage SSL / TLS certificates with acme.sh (Let's Encrypt, ZeroSSL) for Ubiquiti UbiOS firmwares

Manage SSL / TLS certificates with acme.sh (Let's Encrypt, ZeroSSL) for Ubiquiti UbiOS firmwares - alxwolf/ubios-cert

github.com

Iemand ervaring met één van deze 2 of met een andere procedure om een UDM gewoon weer een beetje met de huidige beveiligingsnormen mee te laten doen, bijv. met Letsencrypt certificaten?

 

[Eddie the Eagle]

Ik heb er geen ervaring mee, maar is dat niet waarom een reverse proxy server gebruikt wordt (als algemene oplossing, niet specifiek Unifi) ?

NGINX Reverse Proxy | NGINX Documentation

Configure NGINX as a reverse proxy for HTTP and other protocols, with support for modifying request headers and fine-tuned buffering of responses.

docs.nginx.com

 

[Davey400]

Dat zou een workaround kunnen zijn, maar dan ga je via een ander device naar de controller.
Intern benader je het device op ip (dan is het certificaat natuurlijk nooit valide) of op hostname.
Standaard is die hostname unifi.local. Daar hangt een certificaat aan, maar deze is niet valide.*
Ik zou graag een certificaat zien dat gewoon uitgegeven is door een vertrouwde uitgever, zoals elke website dan natuurlijk alweer een paar jaar doet.
Met de huidige hostname kan dat natuurlijk niet, want we kunnen niet allemaal 'unifi.local' heten, dat zou ook een beetje tegen het idee in gaan dat je zeker weet dat je weet met 'wie' je aan het communiceren bent.
Ik zou dus willen dat het meest belangrijke device in mijn netwerk ook gewoon op naam te valideren is voordat ik er een wachtwoord op intik.
Dat kan door de mogelijkheid aan te bieden een unieke naam te kiezen (dat mag best op basis van een prefix bijv.) en voor deze naam een certificaat aan te laten vragen bij een gevalideerde instantie.
Omdat het ook weer niet zó kritiek is mag dat best een gratis certificaat zijn met zeer beperkte controle, zoals Letsencrypt dat aan biedt, (graag zelfs, geen fee, auto-renewal) maar zodra een dergelijk mechanisme aanwezig is kan dat natuurlijk waar van toepassing ook een 'echt' gevalideerd en betaald certificaat zijn.

Zie onder voor de eigenschappen van mijn huidige certificaat; dat zal op jullie devices niet veel anders zijn.
Ik hoop dat dit e.e.a. verduidelijkt.


*(Nou ja, in zekere zin is het wel een valide certificaat, maar het is self-signed. Het is dus valide voor de uitgever zelf omdat de uitgever zelf zegt dat ie is wie is is. Dat is net zo iets als dat ik jou @Eddie the Eagle tegen kom en jij je voorstelt en zegt "ik heet Eddie the Eagle". Als ik dan vraag: hoe weet ik dat jij de echte 'Eddie the Eagle' bent? zeg jij: omdat ik dat zeg, en ik vertrouw mezelf.
Als ik dan bewijs wil, kun jij mij een briefje geven waar jouw naam op staat, en dan zeg je: 'kijk maar, hier staat het'.
Dat geeft mij nog niet persé vertrouwen dat jij echt 'Eddie the Eagle' bent, misschien ben jij wel een wannabee.
En dan flip jij jouw paspoort naar voren. Uitgegeven door het Ministerie van Buitenlandse Zaken.
En daar staat 'Eddie the Eagle' op. Het Ministerie van Buitenlandse Zaken vertrouw ik, en als zei zeggen dat jij het echt bent dan geloof ik het ineens wel.

 

[Hofstede]

Het probleem met dat hele locale certificaten gedoe is dat je bij elke UnifiOS update weer opnieuw kunt beginnen of dat dingen niet meer werken omdat je met de certificaatstore "geexperimenteerd" hebt.
Persoonlijk log ik altijd via de unifi portal in en lokaal gebruik ik alleen in noodgevallen.

 

[Timo]

Ik gebruik een Cloudflare tunnel vanaf zowel lokaal als daarbuiten om bij de UI te komen en bij andere devices op mijn netwerk. Hierdoor heb je geen last van self-signed certificates. Ook al is het net zoiets als een reverse proxy, het is (voor mij dan) een vertrouwde partij. Voordeel is dat je ook een identity provider kunt koppelen of andere authenticate middelen om überhaupt naar het netwerk te kunnen. Op mijn netwerk draait hiervoor een Cloudflare tunnel agent. En je hoeft geen gaatjes te prikken in je firewall.

 

[rheinen]

Ik gebruik voor verschillende services een Cloudflare tunnel die verwijst naar mijn Nginx Proxy Manager. Deze wordt op zijn beurt weer gemonitord door Crowdsec (een soort Fail2ban oplossing).

Waarom? Met enkel een reverse proxy zoals NPM, is mijn publieke IP adres makkelijk te achterhalen. Met een Cloudflare tunnel is dat opgelost, maar de gratis versie van Cloudflare biedt minimale bescherming tegen bepaalde aanvallen van buitenaf. Crowdsec biedt een mooie extra beschermingslaag, maar werkt niet op Cloudflare, maar wel op NPM. Vandaar bovenstaande combi.