Userbase

Een beetje in lijn met mijn topic over VPN : wat is de beste manier om thuis gebruik te maken van certificates ?
Ben nu al diverse plaatsen thuis tegengekomen waar ik TLS certs kan configureren: Synology GUI, Omada Controller, ... En ik vermoed dat ik ook certs ga nodig hebben als ik een IKEv2 server wil opzetten. Ook ga ik dus zowel server als personal certs nodig hebben.

Ga ik best naar een LetsEncrypt ? Daar moet je dan wel een DNS domain hebben, vermoed ik, en ik kan me inbeelden dat (gratis) Dynamic DNS namen ook niet kunnen ?
Of creëer je beter je eigen self-signed CA die je dan wel in alle cliënts moet toevoegen aan de trust store ?

ik gebruik thuis self signed die ik maak op opnsense (lazy en beetje tegen principe om firewall voor extras te gebruiken) voor lokaal werkt dat wel maar gebruik geen vpn. Syno is hier wat op leeftijd, heeft +- 2 dagen nodig voor de dagelijkse virusscan dus gebruik hem niet graag voor extras

Toevoegen aan clients niet direct probleem als het toch enkel je eigen pcs zijn? Iets lastiger als er andere buitenstaanders bijkomen (in mijn geval klikken die toch op alles dat je ze doorstuurt... behalve als je er expliciet om vraagt )

Ik begrijp dus dat je een Synology diskstation in huis hebt?
Je kan die gebruiken voor je gratis ddns (dienst van Synology). Eens kijken in de gui.
En je kan er zelfs ook letsencrypt certificaten laten aanvragen (poort 80 en 443 opzenzetten)
Én daarna kan je zelfs (nog steeds via GUI) een reverse proxy instellen, zodat je meerdere servers in uw intern netwerk op 1 certificaat hebt (of meerdere certificaten, indien je subdomainen hebt)

Zo draaien uw servers op uw intern netwerk gewoon http zonder ssl. Maar naar buiten toe krijgen ze wel ssl

Dit is alleszins hoe ik het doe

(Enfin, ik heb meerdere (sub-)domeinen, Dit is los van synology ddns.
Maar al die domeinen heb ik C-NAME ingesteld naar de ddns domeinnaam die ik van synology krijg. De reverse proxy vangt dat dan op en kan zien welk subdomain gevraagd wordt, en verbindt dan met de juiste server intern. )

efari schreef:En je kan er zelfs ook letsencrypt certificaten laten aanvragen (poort 80 en 443 opzenzetten)

Die poorten openzetten zijn voor mij een absolute nono. Dat zijn net de poorten die gescanned worden ...

Voordelen en nadelen.

=> Let's Encrypt is gratis en trusted, wel DNS nodig - hou wel rekening met het feit dat het een PITA is op toestellen waar automatisch certificaat management niet mogelijk is en dat alle toestellen waarvoor je certs uitgeeft netjes in publieke logs komen.
=> self-signed is gratis, geen DNS nodig maar niet trusted, op elke client moet je het root cert van je CA dus manueel trusten - je kan ook een miljoen keer op "Proceed anyway" klikken in de plaats maar Chrome wordt meer en meer allergisch aan zo'n zaken

=> Er is ook RapidSSL, het budgetmerk van de Digicert club voor $10/jaar, trusted, DNS nodig. Vooral handig voor toestellen waarbij je geen ACME hebt. Optie om niet te loggen. Noot: Digicert doet op rapidssl.com alsof RapidSSL niet meer bestaat en wil je naar de duurdere midpriced certs onder de Geotrust merknaam pushen. Je moet via een reseller gaan om RapidSSL te kunnen krijgen, daarna kan je het cert gewoon beheren via de management interface van Geotrust.

CCatalyst schreef:een PITA is op toestellen waar automatisch certificaat management niet mogelijk is

Dat is inderdaad wel een goed punt. Die 90d validity bij LetsEncrypt betekent wel dat je je werk hebt aan renewals.
Met mijn eigen CA doe ik een beetje wat ik wil, en die kan ik wellicht zonder veel poespas installeren op de paar Windows en IOS devices die de CA moeten trusten.

Tomby schreef:

CCatalyst schreef:een PITA is op toestellen waar automatisch certificaat management niet mogelijk is

Dat is inderdaad wel een goed punt. Die 90d validity bij LetsEncrypt betekent wel dat je je werk hebt aan renewals.
Met mijn eigen CA doe ik een beetje wat ik wil, en die kan ik wellicht zonder veel poespas installeren op de paar Windows en IOS devices die de CA moeten trusten.

Voor de meest gangbare zaken, inclusief Windows/IIS/Exchange kan je https://certifytheweb.com/ gebruiken. Gratis en handig voor LetsEncrypt (of andere)

devastator schreef:

efari schreef:En je kan er zelfs ook letsencrypt certificaten laten aanvragen (poort 80 en 443 opzenzetten)

Die poorten openzetten zijn voor mij een absolute nono. Dat zijn net de poorten die gescanned worden ...

Voor letsencrypt moet je moet initieel poort 80 openzetten voor het aanvragen van het cert. daarna is enkel 443 nodig voor de renewal. (En mag 80 terug dicht)
Als dat niet gaat voor jou, zal je geen letsencrypt kunnen gebruiken denkik

efari schreef:

devastator schreef:

efari schreef:En je kan er zelfs ook letsencrypt certificaten laten aanvragen (poort 80 en 443 opzenzetten)

Die poorten openzetten zijn voor mij een absolute nono. Dat zijn net de poorten die gescanned worden ...

Voor letsencrypt moet je moet initieel poort 80 openzetten voor het aanvragen van het cert. daarna is enkel 443 nodig voor de renewal. (En mag 80 terug dicht)
Als dat niet gaat voor jou, zal je geen letsencrypt kunnen gebruiken denkik

HomeAssistant kan het zonder dat 1 van die 2 poorten open moet. Geen idee hoe ze het doen.

Ik gebruik m'n eigen CA (voor interne hosted dingen) en Letsencrypt voor publieke zaken. Ik doe de check en renewal via cloudflare Dns method, poorten openzetten is geen vereiste.

devilkin schreef:Ik gebruik m'n eigen CA (voor interne hosted dingen) en Letsencrypt voor publieke zaken. Ik doe de check en renewal via cloudflare Dns method, poorten openzetten is geen vereiste.

Heb je door een tutorial ofzo voor?

Verstuurd vanaf mijn SM-G965F met Tapatalk

https://certbot-dns-cloudflare.readthed ... en/stable/

Voorts vereist dit wel dat je eigen domein bij cloudflare zit als Dns provider.

Adhv de api key kan certbot dan een record aanmaken wat dan gebruikt wordt door letsencrypt om ownership te valideren.

Sent from my SM-T970 using Tapatalk

devastator schreef:

efari schreef:En je kan er zelfs ook letsencrypt certificaten laten aanvragen (poort 80 en 443 opzenzetten)

Die poorten openzetten zijn voor mij een absolute nono. Dat zijn net de poorten die gescanned worden ...

Die poorten enkel openzetten richting de virtual environment die LE nodig heeft, en niet meer dan dat; ander webverkeer dan afdwingen via de VPN?

devastator schreef:HomeAssistant kan het zonder dat 1 van die 2 poorten open moet. Geen idee hoe ze het doen.

Je kan de verificatie ook via een DNS entry laten verlopen.

Voor een HA integratie heb ik een https nodig op een lokaal adres. Hoe kan dat?

Een certificaat heeft niets te maken met een adres... wel met de hostname (common name).

Als jij je lokale server dus aanspreekt als myserver.home.local en hierbvoor een selfs-signed certificaat aanmaakt is dat prima.

Please oh please don't use .local
Dat is al jaren deprecated en geen best practice

DarkV schreef:Een certificaat heeft niets te maken met een adres... wel met de hostname (common name).

Als jij je lokale server dus aanspreekt als myserver.home.local en hierbvoor een selfs-signed certificaat aanmaakt is dat prima.

Het ding is, hij heeft wel een certificaat (lets encrypt), maar als je HomeAssistant lokaal benadert (op IP), is dat dus niet geldig

Verstuurd vanaf mijn SM-G965F met Tapatalk

ITnetadmin schreef:Please oh please don't use .local
Dat is al jaren deprecated en geen best practice

Als je geen eigen domain hebt zijn er weinig alternatieven dan er eentje te verzinnen dat niet bestaat.

Indien je wel een eigen domain hebt is het een ander verhaal (maar dan moet je ook split DNS ed. draaien).

devastator schreef:maar als je HomeAssistant lokaal benadert (op IP), is dat dus niet geldig

Benader het op hostname... zoals hierboven beschreven heb je dan split DNS nodig (of hairpinning).

Het is niet alleen voor de show, .local breekt ook vanalles.
Als het een productie domain is, krijg je miserie met dns security als je met certs wil werken.
En .local wordt door apple gebruikt voor hun bonjour protocol.

Het is dus echt wel afgeraden om dat nog te gebruiken.
Best practice is om altijd een domain te gebruiken voor productie netwerken, zonder discussie.
Wil je een test netwerk, dan is er eigenlijk geen goed alternatief waarvan je zeker bent dat het niks breekt.

Nu, wat mij betreft had men .local gewoon moeten reserveren hiervoor en basta; dat apple maar iets anders gebruikt.

DarkV schreef:
Benader het op hostname... zoals hierboven beschreven heb je dan split DNS nodig (of hairpinning).

Werkt hairpinning als inet down is?


Verstuurd vanaf mijn SM-G965F met Tapatalk

Nee, want dan resolved hij ook je hostname niet en heb je trouwens geen adres ook niet.

Dus best met split DNS werken.

Het rare is dat de integratie expliciet vraagt naar een intern ip adres. Ik heb een domein en een duckdns systeem voor ha met certificaat, maar dat werkt dus niet.

Dit is wat ik wil doen werken:
https://www.home-assistant.io/integrati ... e_connect/

Zie redirect URI

Die Redirect URI wordt gebruikt om de data, die de OAuth flow krijgt van de externe API, door te geven aan HA. Je kan hier dus elk ip adres of hostname gebruiken van je HA installatie, zolang het maar bereikbaar is vanaf de locatie waarop je de authenticatie start.

Dat zou in principe zo moeten zijn. De https...duckdns is van overal te bereiken met certificaat. Toch krijg ik een foutmelding als output.

Als je een domein hebt en controle over de DNS ervan, vraag gewoon een wildcard cert aan bij Lets encrypt?

Krijg je *.domein.tld, kan je het overal waar je wil op installeren en je moet niets een public IP geven.