NEWS
SSL ohne letsencrypt
-
Hallo zusammen,
da mein IObroker nicht am externen Netz hängen soll, bin ich auf der Suche nach einer Möglichkeit der Passwort-Eingabe.
Leider oder Gott sei dank ist das nur SSL-verschlüsselt möglich.
Da mein System von außen NICHT erreichbar sein soll, fällt letsencrypt schon mal weg.
Gibt es eine andere Möglichkeit, ein SSL-Zertifikat einzubinden?
Mein Raspberry ist im Moment offline, solange ich keine Möglichkeit habe, das umzuetzen.
Mit meinem NUC hat es damals gut funktionert, der ist aber für's erste aus dem Verkehr gezogen.
Gruß,
Mathias
-
ich greife auf IObroker sowieso nicht von ausserhalb meines (W)LAN-Netzes zu.
da dürften die Risiken meiner Ansicht nach recht überschaubar bleiben.
Mit der CCU sieht es etwas anders aus. Aber wozu gibt es VPN? Dazu muß man nicht mal einen Port öffnen, was wiederum ein Sicherheitsrisiko darstellen würde.
Was ich auch gesehen habe, man kann auch einen eigenen SSL-Schlüsssel importieren. Nun frage ich mich, ob man denn nicht die Raspberrymatic bemüheen kann, erst einen SSL-Schlüssel zu generieren (für IObroker), dann einen zweiten für sich selber.
Gruß,
Mathias
-
Hat jemand vielleicht mittlerweile dennoch eine Lösung gefunden, wie man ioBroker via SSL verschlüsseln kann OHNE dass man von außen Zugriff haben möchte, also ohne letsencrypt Certs? Ich weiß dass man die PW-Abfrage auch ohne Certs einstellen kann, möchte aber dennoch verschlüsselte Kommunikation.
-
Hi
Das ist relativ einfach. Du kannst Du eine eigene PKI Umgebung bauen.
Z.B.: mit dem Benutzerfreundlichen Tool XCA oder mit OPENSSL. Anleitungen dazu gibt es genug im Netz. Allerdings sollte man sich ein wenig einlesen.
Gerade wie die Handhabung der RootCA und des PRIVAT-KEY's.
Als Empfehlung würde ich Dir eine zweistufige CA geben. Die RootCA (OFFLINE) und dann die Intermediate/Issuing-CA um die Identity Zertifikate zu erstellen.
Gruß Daniel
-
Ist das eine Mehrstufige CA? Ich meine nein und deshalb gilt dies als UN-Secure oder handelt es sich um Self-Signed Zertifkate?
Gib mir Doch mal ein Feedback, würde mich Interessieren ob es sich bei Deiner benannten Variante um eine vollwertige Private CA handelt. DANKE…
Auf dem raspberry kannst du lokale Zertifikate anlegen (geschieht halbautomatisch wenn du den PI einrichtest. Diese kannst du als Zertifikate für ssl angeben.
Das sollte auch auf anderen Systemen gehen.
A `
-
Hallo Zusammen,
das Thema Zertifikate ist mit Sicherheit kein einfaches Thema… mal schnell eine eigene PKI unter dem Tisch zu generieren ohne sich um wichtige Prozesse Gedanken gemacht zu haben, führt in der Zukunft zu echten Problemen.
Die einzelnen Hersteller von Browsern und auch Middleware Applikationen haben begonnenn strikte Prozesse zur Kettenprüfung von Zertifikaten zu integrieren. In den meisten Fällen führt die Verwendung von einstufigen "Self Signed Certificates" zu Problemen, da diese von vielen Browsern nicht mehr akzeptiert werden, selbst wenn diese im eigenen Truststore des Browsers liegen.
Wer sich eine eigene PKI bauen will, muss sich Gedanken machen wie er das private Schlüsselmaterial schützen will z.B mittels einem HSM, er braucht eine Root CA und eine Subordinate CA u.U auch einen kleinen Verzeichnisdienst wo die aktuellen Zustände der einzelnen Zertifikate hinterlegt werden und gegen Prüfregeln geprüft werden können.
Unter Umständen verlangt eine Technologie aber auch, dass die Prüfkette in einem bestimmten Format z.B PKCS#7 hinterlegt sein muss.
Ebenso muss man sich Gedanken machen über die verwendeten Algorithmen und Verwendungszwecke der Zertifikate, das diese Umständen von Prüfinstanzen einer Applikation überprüft werden, wenn dann eine wichtige OID fehlt (z.B Digital Signature), führt dies zu einem Systemausfall.
Zertifikate ohne eine echte Möglichkeit der Kettenprüfung zu generieren, diese durch die Gegend zu kopieren ohne zu dokumentrieren, wo diese hinterlegt werden und wurden führt bei der Laufzeitprüfung wenn ein Zertifikat EOL ist, zu Systemausfällen.
In vielen Fällen ist es auch nicht einfachen mittels kopieren von Zertifikaten getan, die Hersteller einzelner Technologien erwarten das die Zertifikate samt Schlüsselmaterial in einem Truststore in einem spezifischen Format vorliegen und eine Konfiguration entsprechend angepasst wird.
Dann findet man aufeinmal ein Passwort im Klartext in einer Konfigurationsdatei... auch nicht gerade sicher......
Manche Node-Red Flows haben echte Probleme mit "Self Signed Certificates", in diesem Fall kann man die Ketten- Zertifikatsprüfung einfach abschalten, was aber auch nicht im Sinne der Sicherheit ist.
Alles in Allem muss man sich mal klar machen, das z.B ein Windows 10 Rechner über 100.000 Zertifikate mit sich bringt, von denen sind dann die meisten abgelaufen, viele nutzen bereits gebrochene Sicherheitsalgorithmen z.B RC4, MD5 oder SHA-1.
Zertifikate sind mittlerweile Bestandteil von Cybersicherheits Angriffen, weswegen wie oben beschrieben die Hersteller von Technologie reagieren was für einen "normalen Anwender" fast nicht mehr überblickt und verstanden werden kann.
Ein Schlüssel muss nicht nur zum Schloss passen, dass Schloss selbst muss dann auch noch in die Türe eingebaut werden - und neben dran lasse ich das Fenster offen......
Wir haben diese Themen bei uns im Unternehmen jeden Tag, selbst die großen Unternehmen welche viel Geld investieren kämpfen hier mit echten Problemen.
Das Thema ist komplex, wer sich eine eigene PKI Umgebung bauen will muss sich halt grundlegend Gedanken machen wie er einen solchen Infrastukturbestandteil integrieren und auch pflegen will.
My2Cents
Equilora aka Harald
-
Ich kann Harald da zustimmen - eine eigene PKI für "Heimzwecke" zu bauen ist durchaus … komplex - ich habs nämlich gemacht, nach dieser Anleitung:
https://jamielinux.com/docs/openssl-cer ... authority/
Das funktioniert im Prinzip schon, dann kommt aber schon noch bisschen Fummelei in den Konfigurationen, und wenn man über die IP-Adresse zugreifen will (weil das DNS der Fritzbox über VPN zickt), legt nochmal eins drauf.
Und ja, man muss sich unbedingt überlegen, wie man die Private Keys der CA sicher aufbewahrt, und das auch dokumentieren, damit mans später wiederfindet, wenn z.B. das Zertifikat der Intermediate CA nach 5 (?) Jahren ausläuft und plötzlich nix mehr geht ...
Ein HSM find ich allerdings ein etwas zu großes Geschütz für Heimzwecke, aber wenn jemand will :)
Ich habs damals für die VIS Oberfläche gemacht, weil ich unbedingt die Spracheingabe nutzen wollte, und die Browser den Zugriff auf das Mikrofon nicht ohne HTTPS Verbindung zugelassen haben.
ABER: Es gibt dann auch einiges, das NICHT mehr so einfach klappt:
-
Ich hatte ne Menge Arbeit, z.B. die eingebetteten Flots umzustellen. Da steht dann nämlich überall eine http:// ... Adresse, und das funktioniert dann nicht mehr. Tip: Flot immer ohne Protokoll und Serveradresse in VIS reinschreiben ...
-
Andere eingebettete Pages mit http:// werden vom Browser rausgeschmissen. Wenn https, dann muss alles https sein. Folge: z.B. die Sonos Webkonfiguration, die im Sonos Webadapter aufgerufen werden kann, ist nicht mehr im iFrame oder Dialog darstellbar, das muss ne eigene Seite sein. Squeezebox evt. genau so.
-
SayIt auf den Sonos Boxen klappt auch nicht mehr, die generierten MP3 Dateien werden immer mit http:// adressiert. Workaround: Zweiter web-Adapter OHNE https ... was natürlich das Konzept ein bisschen ad absurdum führt ...
Fazit: "Einfach" mal https machen ... man kann schon, aber "einfach" führt zu ner ganzen Menge Aufwand :)
-
768
Online32.5k
Benutzer81.7k
Themen1.3m
Beiträge