WebUI mit SSL

[jmaus]

ich wollte nur auf die 'Inkonsistenz' zwischen lokaler SSL Zertifikatserzeugung und einem trotzdem möglichen http Browseraufruf hinweisen, den ich von einer professionellen Anwendung (Homematic) so nicht erwarten würde.

Was genau ist denn bitte an der Art&Weise wie die WebUI HTTPS Zertifikate usw. handelt unprofessionell? Selbst bei einer FritzBox, Unifi Controller, usw. wird das alles genau so gemacht/angeboten. Auch da werden rein selbst signierte Zertifikate erzeugt und standardmäßig installiert und dann muss man im Browser diese akzeptieren.

[wolwin]

Was genau ist denn bitte an der Art&Weise wie die WebUI HTTPS Zertifikate usw. handelt unprofessionell? Selbst bei einer FritzBox, Unifi Controller, usw. wird das alles genau so gemacht/angeboten. Auch da werden rein selbst signierte Zertifikate erzeugt und standardmäßig installiert und dann muss man im Browser diese akzeptieren.

Nochmal: mir geht es NICHT um die Art der Zertifikaterzeugung und deren Installation!! Es geht - platt gesprochen - darum, dass ich Zertifikate erzeugen kann, und dann trotzdem die WebUI ungesichert aufrufen kann … und das empfinde ich eben als verbesserungswürdig.

[LibertyX]

Das die WebUI HTTPS aktuell nicht erzwingt ist unschön, steht aber auch auf der ToDo liste.
Das hält einem aber nicht davon ab, die WebUI über HTTPS aufzururfen.

Das erzeugen einer CA samt signierter Client Zertifikate ist hierfür aber auch völlig überflüssig und viel zu aufwändig.

[Xel66]

Was passiert eigentlich, wenn der HTTPS-Zwang umgesetzt wird mit dem Zugriff via Cloudmatic (2x https)? Welches Zertifikat ist dann für den Browser relevant? Ich sitze z.B. geschäftlich an einem restriktiven Rechner, dessen Browser keine selbst signierten Zertifikate akzeptiert. Das Cloudmatic-Zertifikat ist kein Problem - das wird akzeptiert. Alternativ muss der Proxy von Cloudmatic ja das kaskadierte HTTPS umsetzten.

Gruß Xel66

[LibertyX]

Der Client sieht immer nur das Zertifikat des Webservers zu dem er Verbindet.

Verbindest du also zu einem Webserver (Reverse Proxy) siehst dein Client nur dessen Zertifikat.

Das ist ähnlich wie bei mir, mein Zugriff läuft über Cloudflare zu meinem Reverse Proxy zur CCU, hier sieht der Client ausschließlich das Zertifikat von Cloudflare.

[Xel66]

Ok, danke für die Info. Sitze gerade (als Passagier) im Stau auf der A7 und konnte keine eigenen Tests machen, aber das mit dem Zertifikat für den Browser ist bei näherem Nachdenken eigentlich logisch. Diesbezüglich sollte ich also kein Problem bekommen. Jetzt muss nur noch der Proxy bei Cloudmatic mit dieser anziehenden Änderung klarkommen. Mein eigener Reverse-Proxy ist derzeit außer Betrieb, weil ich den Raspi für andere Zwecke brauchte. Kann also derzeit nicht selbst probieren. Danke erst mal.

Gruß Xel66

[Turnierkrokodil]

(...)
Das erzeugen einer CA samt signierter Client Zertifikate ist hierfür aber auch völlig überflüssig und viel zu aufwändig.

Eine weitere Möglichkeit: sehr einfach geht das Erzeugen eines validen Zertifikats mit Letsencrypt's certbot,
Vorraussetzung ist, das man eine eigene domain hat und beim Provider per API oder manuell TXT records erzeugen kann (ich habe z.B. bei Cloudflare eine .com domain für 8$/Jahr und mache das per API, bei Strato ging das nur manuell)

die von certbot erzeugten files auf die CCU nach /usr/local/etc/config kopieren und kombinieren:

Code: Alles auswählen

cat private.key cert.pem > server.pem

dann noch schnell den lighttpd neustarten

Code: Alles auswählen

/etc/init.d/S50lighttpd restart

Nachteil: das Letsencrypt Zertifikat ist nur 60 Tage gültig und muss entsprechend erneuert werden. prinzipiell geht das easy mit dem Aufruf von certbot renew Wenn man certbot auf der CCU installieren könnte, dann wäre das per cron und einem kleinen script auch leicht automatisierbar...

[LibertyX]

Bringt dir nur rein gar nichts, wenn du die WebUI über den Hostnamen oder private IP aufrufst, dann erhälst du die gleiche Fehlermeldung.

Es sei denn du biegst deinen internen DNS Server so um, das er den FQDN deiner öffentlichen Domain auf die interne IP auflöst.

[jmaus]

... und die Nutzung von certbot direkt auf der RaspberryMatic setzt noch voraus, das die CCU/RaspberryMatic dann direkt vom Internet erreichbar ist damit die letsencrypt server aus der ferne die validität überprüfen kann. Und das die Bereitstellung einer CCu/RaspberryMatic direkt im Internet (via port forwarding) auch mit https nicht anzuraten ist, wissen wir ba auch nicht erst seit gestern! Ergo, ergibt es wenig bis keinerlei sinn certbot direkt unter RaspberryMatic/CCu zur Verfügung zu stellen.

[LibertyX]

In dem von Ihm genutzten API (wildcard) Verfahren erfolgt die Verifizierung über DNS TXT Records, hier müsste die CCU nicht erreichbar sein, dass setzt aber voraus dass man eine eigene Domain besitzt und hier in der Lage ist DNS Records mittels API zu setzten.