RaspberryMatic
RaspberryMatic copied to clipboard
jens-maus
Verbesserte UI bei SSL-Verschlüsselung
Die Verschlüsselung der SSL-Verbindung wird nicht wie bei der CCU auf dem Server, sondern auf dem Raspberry direkt gemacht.
Deshalb stimmt auf der WebUI die Vorgehensweise nicht mehr:
Ich würde es so weit ändern, dass der untere Button fehlt. Man muß ja nichts mehr hochladen. Die Schritt für Schrit Anleitung besteht hier auch nur noch aus einem Schritt, nämlich der Erstellung der SSL-Verschlüsselung, bzw der Datei, die dafür verantwortlich ist:
Danke für das Feature Request. Allerdings kann es mitunter immer noch sinnvoll sein wenn man ein eigenes Zertifikat hochladen kann. Es gibt ja Situationen wo das Sinn ergibt.
Daher würde ich vorschlagen die prinzipielle Funktionalität das man Zertifikate alternativ selbst hochladen kann nicht gänzlich zu entfernen sondern unterhalt vom standardknopf zum neu erstellen eines Zertifikates anzuzeigen bzw anzubieten.
da hast Du natürlich recht. In wieweit man ein Zertifikat von OpenSSL einpflegen kann, weiß ich nicht, sollte man den einen oder anderen Server zu hause haben. Da könnte man sich von dort ein Zertifikat abzwacken.
Und dann bitte auch certbot integrieren, damit man Let's encrypt Zertifikate direkt implementieren kann. :-) Ich nutze z.B. Cloudflare um DNS mit einer eigenen Domain auch auf private IP-Adressen (192.168.x.x) zu legen und lasse meine Geräte wie Netzwerk-Switches, Router, NAS, etc. seit geraumer Zeit ihre Zertifikate jeweils selbst über Let's encrypt generieren (über Cloudflare DNS API, aber gibt auch andere Methoden).
Aber nicht bei einer CCU! Keine Portfreigaben!
Sowas macht man wenn über einen Reverse Proxy oder besser VPN aber keine direkte Freigabe auf eine CCU!
Und dann bitte auch certbot integrieren, damit man Let's encrypt Zertifikate direkt implementieren kann. :-)
Und wie genau soll das mit LetsEncrypt Unterstützung funktionieren wenn die CCU hinter einer Firewall steckt und natürlich (wie es vorgesehen ist!) nicht direkt aus dem Internet erreichbar ist? Das ist Wunschdenken und wir so nicht kommen solange es nicht von LetsEncrypt möglichkeiten gibt auch Zertifikate für Geräte hinter restriktiven Firewalls ausstellen zu lassen.
Ich habe oben geschrieben, dass ich das bereits bei anderen Geräten so mache. Und meine Geräte sind auch nicht direkt aus dem Internet erreichbar (zumindest die meisten, die IoT Geräte definitiv nicht!) und sollen sie auch nicht sein. Trotzdem kann ich z.B. bei Cloudflare einen DNS A Record erstellen der auf eine private IP-Adresse verweist und dafür kann ich auch ein Let's Encrypt Zertifikat erstellen (in diesem Fall: Cloudflare DNS API). Warum auch nicht? Dafür muss das entsprechende Gerät, auf dem der Client läuft, natürlich aufs Internet zugreifen können. Wenn ein externer Zugriff auf das Gerät aus dem Internet nicht vorgesehen ist, dann klappt es natürlich nicht mit den "einfachen" Let's Ecrypt Methoden, wo Zugriff auf z.B. HTTP von extern notwendig ist...
Und wozu? Weil ich faul bin und keine eigene CA betreiben möchte.
Ein Zertifikat von Let´s Encrypt bringt dir hier dann rein gar nichts, da Let´s Encrypt nur Zertifikate für öffentliche Domains ausstellt, greifst du mit dem internen Hostname auf das Gerät zu, bekommst du die gleiche Warnung wie bei einem Self signed Zertifikat.
Du brauchst auch keine eigene CA betreiben, einfach das Zertifikat der CCU auf deinen Clients als vertrauenswürdiges Root Zertifikat importieren, das wars.
Steht doch im Text, dass ich Cloudflare benutze. Das funktioniert nur mit öffentlichen Domains... Dazu fehlt mir dann doch der Anreiz, den finanziellen Aufwand für eine eigene CA zu betreiben.
Ist mir bekannt, tut aber nichts zur Sache, da du wenn die CCU nicht aus dem Internet erreichbar ist, nicht mit dem öffentlichen FQDN drauf zugreifen kannst, sondern nur mit der internen IP / Hostnamen und der ist im Let´s Encrypt Zertifikat nicht als Alt Name enthalten, daher wird dein Browser eine Warnung anzeigen, somit gewinnst du damit nichts.
Nochmal, du brauchst keine CA zu betrieben, das von der CCU erzeugte Zertifikat exportieren und auf deinen Clients als "Vertrauenswürdige Stammzertifizierungsstelle" importieren, danach wird dein Browser keine Warnung mehr anzeigen.
Nein, tut er nicht. Ich greife mit dem öffentlichen FQDN aus meinem LAN darauf zu. Aber ich habe das doch oben auch geschrieben, dass ich einen DNS A Record mit einer privaten IP-Adresse anlege und über die Cloudflare DNS API die Zertifikate erstelle. Wer zwingt mich denn, meine Hosts mit "öffentlichen" FQDNs im Internet erreichbar zu machen? Das ist auch gar kein so unüblicher Fall, aber ich gebe zu, in privat genutzten Netzwerken eher selten der Fall. Daher vielleicht auch kein Feature, was eine breite Masse nutzen würde. Ich mache es einfach weiterhin mit meinem certbot Raspi und schiebe das Zertifikat nach der Zwangserneuerung per SSH auf die RaspberryMatic.
Man kann es sich auch unnötig schwer machen...
Zum Tema einen öffentlichen DNS Record mit einer privaten IP anzulegen, sage ich jetzt mal nichts...
Den DNS Record bekommst Du im öffentlichen Query doch gar nicht... :-) Das kann man bei Cloudflare konfigurieren. Ich benutze lediglich die DNS Infrastrktur von Cloudflare, weil meine öffentliche Domain auch öffentlich genutzt wird. Und mein LAN und die weiteren VLANs haben halt eine subdomain der öffentlichen Domain. Es gibt ja auch Hosts, die sich in verschiedenen Netzen befinden und sowohl öffentliche als auch private IPs haben.
Und wozu? Weil ich faul bin und keine eigene CA betreiben möchte.
- Brauchst du das auch nicht, denn es ist vollkommen i.O. für die 1-2 Webbrowser die du da verwendest um auf die WebUI von RaspberryMatic zuzugreifen einfach da Zertifikat als dauerhaft akzeptiert zu markieren.
- Und du missbrauchst vollkommen unnötig und nur aus eigener Faulheit die Ressourcen von LetsEncrypt und Cloudfare für eine unnötige vergabe von Zertifikate für eine reine intern zu betreibende Zentrale.
Also nein, von meiner Seite gibt es keinen Grund hier irgendeine Funktionalität bzgl. LetsEncrypt einzubauen. Nutze die selbst signierten Zertifikate einfach oder bastel dir halt selbst etwas zusammen. Denn wenn du dich schon daran so sehr ergötzt das das theoretisch mit wilden konstrukten via CloudFlare, etc. möglich ist, dann sollte es für dich doch auch kein problem sein den certbot auf RaspberryMatic nur für deine Zwecke zu portieren. Also Ende der Diskussion.
Ich glaube das ist einfach Ansichtssache. Punkt 1 möchte ich nicht so machen und für Punkt 2 zahle ich zumindest bei Cloudflare Geld (ich will nicht den CO2-Ausstoß wegdiskutieren, der bei Cloudflare durch ca. 20 Hosts entsteht, die auch eine private IP-Adresse haben und in der Netzwerkzone stehen und wo das Zertifkat alle 30 Tage mal aktualisiert wird). Über das Argument, dass ich Ressourcen von Let's Encrypt verschwende, hatte ich so noch nicht nachgedacht, sehe ich aber persönlich auch nicht unbedingt genau so.
Aber ich hatte ja geschrieben, dass ich es einsehe, da dieses Feature sicher nur wenige nutzen würden und es daher vermutlich keinen Sinn macht, dieses Thema weiter zu verfolgen.
[...] ich es einsehe, da dieses Feature sicher nur wenige nutzen würden und es daher vermutlich keinen Sinn macht, dieses Thema weiter zu verfolgen.
Genau so ist es und ich sehe keinen Grund hier irgendetwas für RaspberryMatic bzgl. LetsEncrypt Unterstützung anzupassen oder zu verbessern und da dies hier kein Diskussionsforum, sondern ein Issue/Bugtracker, ist gibt es hier nichts weiter zu erörtern/diskutieren.
Ich habe es doch akzeptiert. Es ging auch lediglich um einen Featurevorschlag, den ich nächstes Mal besser für mich behalte.
Aber wieso es Mißbrauch sein soll, wenn ich eine private DNS Zone bei Cloudflare verwalte und Let's Encrpt zur Verwaltung meiner Zertifikate dafür einsetze, kann ich dennoch persönlich nicht nachvollziehen.
Praktisch fände ich solch ein Feature auch, so ist das nicht..
Kann aber natürlich auch die Gegenargumente verstehen... ;)
Ist mir bekannt, tut aber nichts zur Sache, da du wenn die CCU nicht aus dem Internet erreichbar ist, nicht mit dem öffentlichen FQDN drauf zugreifen kannst, sondern nur mit der internen IP / Hostnamen und der ist im Let´s Encrypt Zertifikat nicht als Alt Name enthalten, daher wird dein Browser eine Warnung anzeigen, somit gewinnst du damit nichts.
Nochmal, du brauchst keine CA zu betrieben, das von der CCU erzeugte Zertifikat exportieren und auf deinen Clients als "Vertrauenswürdige Stammzertifizierungsstelle" importieren, danach wird dein Browser keine Warnung mehr anzeigen.
Ich schaffe es mit keinem aktuellen Browser das Zertifikat so zu installieren das die Warnung verschwindt da es immer ein self-signed Zertifikat ist. Gibt es dafür eine Lösung oder muss man mit der Warnung leben? Danke
Ich schaffe es mit keinem aktuellen Browser das Zertifikat so zu installieren das die Warnung verschwindt da es immer ein self-signed Zertifikat ist. Gibt es dafür eine Lösung oder muss man mit der Warnung leben?
Selbst signierte Zertifikate erzeugen immer diese Warnung, das liegt in der Natur der Dinge. Du kannst aber in jedem modernen Browser das Zeritifikat importieren lassen und als dauerhaft akzeptiert makieren damit diese Warnungen komplett verschwinden bzw. weg sind. Wie das geht aber bitte bei Google suchen/nachfragen! Das ist hier kein Supportforum.
Wie lautet die Fehlermeldung?
Das Zertifikat wurde in Windows als "Vertrauenswürdige Stammzertifizierungstelle" importiert?
Ich hatte das Zertifikat immer an der falschen Stelle importiert. Jetzt hat er geklappt. Vielen Dank
Und wie genau soll das mit LetsEncrypt Unterstützung funktionieren wenn die CCU hinter einer Firewall steckt und natürlich (wie es vorgesehen ist!) nicht direkt aus dem Internet erreichbar ist? Das ist Wunschdenken und wir so nicht kommen solange es nicht von LetsEncrypt möglichkeiten gibt auch Zertifikate für Geräte hinter restriktiven Firewalls ausstellen zu lassen.
Genau das kann Let's Encrypt doch schon längst. Nämlich über die o.g. DNS API. Und die ist unter anderem genau für solche Anwendungen gedacht, nämlich wenn man keinen (öffentlich zugänglichen) Webserver hosten kann/will/darf.
- Brauchst du das auch nicht, denn es ist vollkommen i.O. für die 1-2 Webbrowser die du da verwendest um auf die WebUI von RaspberryMatic zuzugreifen einfach da Zertifikat als dauerhaft akzeptiert zu markieren.
Das ist natürlich eine Option, aber im Jahr 2020 nicht sonderlich benutzerfreundlich. Klar kann man argumentieren, dass im Fall von RaspberryMatic nur Admins/Profis zugreifen, aber auch die sind nur Menschen, und auch die klicken Zertifikatswarnungen i.d.R. einfach weg.
Auf mobilen Plattformen ist das Wegklicken von Zertifikatswarnungen teilweise auch gar nicht so trivial, d.h., wenn man es mobil verwenden möchte, wird es evtl. herausfordernder.
- Und du missbrauchst vollkommen unnötig und nur aus eigener Faulheit die Ressourcen von LetsEncrypt und Cloudfare für eine unnötige vergabe von Zertifikate für eine reine intern zu betreibende Zentrale.
Es hat nichts mit Faulheit zu tun, sondern ist Good Practice und ordentlicher IT Betrieb. Klar kann man auch eigene CAs betreiben, oder wild und verstreut überall selbst signierte Zertifikate importieren, aber das ist weitaus weniger bequem (aus Sicht des Anwenders) als öffentlich vertrauenswürdige Zertifikate mit wohl definierten Policies und Lebenszyklen.
Let's Encrypt ist es völlig egal, ob und wofür du die Zertifikate verwendest. Du musst nur nachweisen, dass du Kontrolle über eine Domain hast. Der Rest ist Let's Encrypt egal. Es ist (im professionellen Umfeld) üblich auch für interne Ressourcen öffentlich vertrauenswürdige Zertifikate zu verwenden.
Man kann ja gerne in Frage stellen, ob man ein solches Feature in einem Projekt wie RaspberryMatic umsetzen möchte bzw. genug Entwicklungs-Ressourcen hat, oder sie nicht lieber woanders aufwenden soll.
Aber das grundlegende Konzept, nämlich öffentlich vertrauenswürdigen Zertifikate bei internen Ressourcen zu verwenden, in Frage zu stellen, deutet auf ein falsches Verständnis von SSL/TLS hin. In meiner Erfahrung ist das leider viel zu oft der Fall - vor allem unter reinen Entwicklern (keine Ahnung, ob das hier z.b. bei @jens-maus und @libertyx82 auch der Fall ist).
Es hat nichts mit Faulheit zu tun, sondern ist Good Practice und ordentlicher IT Betrieb.
Nein das ist kein good Practice und auch kein ordentlicher IT Betrieb, dass wäre der Betrieb einer internen CA und/oder die Verteilung der Zertifikate mittels GPO etc.
Aber das grundlegende Konzept, nämlich öffentlich vertrauenswürdigen Zertifikate bei internen Ressourcen zu verwenden, in Frage zu stellen, deutet auf ein falsches Verständnis von SSL/TLS hin.
Wer der Meinung ist, für rein interne Ressourcen ein öffentlich signiertes Zertifikat zu verwenden und dann mittels DNS die öffentliche Domian auf eine lokale Ressource umzubiegen hat ein falsches Verständnis von SSL/TLS.
Das Zertifikat wird durch die Signatur kein Stück sicherer, da die Signatur lediglich dazu dient, die Echtheit fremder öffentlicher Zertifikate prüfen zu können, mehr nicht.
Bei lokalen Ressourcen die bekannt sind, ist das völlig überflüssig, da die Ressource bekannt ist.
Genau das kann Let's Encrypt doch schon längst. Nämlich über die o.g. DNS API. Und die ist unter anderem genau für solche Anwendungen gedacht, nämlich wenn man keinen (öffentlich zugänglichen) Webserver hosten kann/will/darf.
Falsch! die DNS challenge wurde zur Erstellung von Wildcard Zertifikaten oder für Systeme die nicht über Port 80 sondern abweichende Ports öffentlich erreichbar sind eingeführt, und nicht um die Zertifikate für lokale Ressourcen zu verwenden, was völlig unnötig ist.
Kann man bitte diese Diskussion endgültig beenden: @kbabioch bitte im Forum diskutieren, hier macht es KEINEN Sinn!
Auch ich bitte darum die Diskussion über das Für- und Wieder hier einzustellen. Das ist hier kein Diskussionsforum, sondern ein Issue Tracker. Das hat hier schlichtweg nichts zu suchen. Also bitte ggf im Diskussionsteil (https://github.com/jens-maus/RaspberryMatic/discussions) oder im HomeMatic-Forum selbst fortsetzen.