SSL ca, cert und key
0 
dedlfix
0 0 dedlfix
0 0 0 0 0 0 0 dedlfix
0 -1 Die Moral von der Gschicht
SSL ca, cert und key
Hier ist beschrieben, wie der Server für SSL umgebaut werden kann. Hat mal jemand eine Anleitung dafür, wie die beiden Dateien
SSL_cert_file => '/path/to/server.crt',
SSL_key_file => '/path/to/server.key',
zu erstellen sind? Was mir noch nicht ganz klar ist: Wie bringe ich dann dem Browser bei, dass meinem selbst erstellten Certifikat vertraut werden kann? MfG
-
Tach!
Hat mal jemand eine Anleitung dafür, wie die beiden Dateien [...] zu erstellen sind?
Ja, gibts genügend im Internet. Welche davon hast du denn nicht nachvollziehen können?
Was mir noch nicht ganz klar ist: Wie bringe ich dann dem Browser bei, dass meinem selbst erstellten Certifikat vertraut werden kann?
Kommt auf den Browser an. Firefox schreit und da gibts dann weiterführende Dialoge, mit einem Häkchen drin. Der Firefox hat eine eigene Zertifikatsverwaltung.
Chrome unter Windows nutzt die im Betriebssystem enthaltene Zertifikatsverwaltung, der Internet Explorer ebenfalls. Das kann man nicht über den Browser verwalten, aber es gibt eventuell Links in den Warnmeldungen zur Zertifikatsverwaltung. Es kann sein, dass man dann aber nur das Zertifikat lesen aber nicht hinzufügen kann. Dann muss man die Verwaltung zu Fuß aufrufen (oder mal mit dem jeweils anderen Browser probieren). Auch dafür gibt es Anleitungen mit Bildern zu finden.
dedlfix.
-
Tach!
Hat mal jemand eine Anleitung dafür, wie die beiden Dateien [...] zu erstellen sind?
Ja, gibts genügend im Internet. Welche davon hast du denn nicht nachvollziehen können?
Nach dieser hier hab ich die Dateien erstellt, Chrome meldet jedoch einen Fehler beim Handshake. Was ist da schiefgegangen und wie kann ich das bereinigen?
Beschreib doch einfach mal, wie Du das gemacht hast so das es bei Dir funktioniert.
-
Tach!
Nach dieser hier hab ich die Dateien erstellt,
Eine aktuellere als aus dem Jahr 2006 hast du nicht gefunden? (Wenn man das Zertifikatspasswort leer lässt, muss man es auch ncht hinterher entfernen.)
Chrome meldet jedoch einen Fehler beim Handshake. Was ist da schiefgegangen und wie kann ich das bereinigen?
Am besten den Text der Fehlermeldung lesen und noch besser, ihn der Suchmaschine der Wahl vorsetzen. Und wenn jemand helfen soll, muss es das Problem so konkret wie möglich beschrieben werden. Aus unpräzisen Angaben kann man keine Fakten für zielführende Antworten entnehmen.
Beschreib doch einfach mal, wie Du das gemacht hast so das es bei Dir funktioniert.
Kann ich nicht, hab ich wieder vergessen. Ich suche mir das die seltenen Male, die ich das brauche im Internet zusammen.
dedlfix.
-
Beschreib doch einfach mal, wie Du das gemacht hast so das es bei Dir funktioniert.
Kann ich nicht, hab ich wieder vergessen. Ich suche mir das die seltenen Male, die ich das brauche im Internet zusammen.
Werd ich nun auch machen, gute Idee!
-
-
-
-
Wer möchte kann den SSL Chat nun testen.
Zuerst Zertifikat http://handwerkzeugs.de/zertifikat-pub.pem installieren
Das Zertifikat ist für rolfrost.dnshome.de
Dann tut der Chat via SSL.
PS: Im FF könnte die Zertikfikatinstallation auch klappen, wenn der URL https://rolfrost.dnshome.de:6667 aufgerufen wird (Ausnahme hinzufügen). Ich bin offen für Ideen wie das vereinfacht werden kann.
-
Hallo pl,
Zuerst Zertifikat http://handwerkzeugs.de/zertifikat-pub.pem installieren
Davon möchte ich dringend abraten.
- Quelle ist unverschlüsselt (
httpvshttps) - kein Fingerprint angegeben
- keine Möglichkeit zu prüfen, ob das Zertifikat wirklich von pl ausgestellt wurde
- der common name ist ein Dysdns-Name, der jederzeit auch auf einen anderen Host auflösen kann
Keine gute Idee.
LG,
CK-
Hallo pl,
Zuerst Zertifikat http://handwerkzeugs.de/zertifikat-pub.pem installieren
Davon möchte ich dringend abraten.
- Quelle ist unverschlüsselt (
httpvshttps) - kein Fingerprint angegeben
- keine Möglichkeit zu prüfen, ob das Zertifikat wirklich von pl ausgestellt wurde
- der common name ist ein Dysdns-Name, der jederzeit auch auf einen anderen Host auflösen kann
Keine gute Idee.
Mein Ziel war es, den Chat über SSL einzurichten und das habe ich geschafft. Die Umstände beim Einrichten jedoch sprechen nicht gerade für die Browserhersteller. Weder FF noch Chrome geben beim Aufruf der ChatURL eine verständliche Meldung aus. Hier gibt es noch Einiges zu verbessern und erst dann werde ich mir überlegen, ob es sich überhaupt lohnt einen SSL-Chat via wss: öffentlich zu betreiben.
-
Hallo pl,
Mein Ziel war es, den Chat über SSL einzurichten und das habe ich geschafft.
Das ist ja schön und gut, aber die Art und Weise wie du dein Zertifikat hier veröffentlicht hast lässt einem keine Möglichkeit sicherzustellen, dass das Zertifikat wirklich von dir ist. Und dazu noch lieferst du es über eine unverschlüsselte Verbindung aus. Darum geht es.
Wenn du das Zertifikat selbst signieren möchtest, dann halte dich an ein paar Grundregeln. Veröffentliche es nur über
https, schreibe den Fingerprint dazu und überlege, ob es eine kluge Idee ist, deinen DynDNS-Namen zu verwenden. Wer sagt denn, dass der Name morgen noch dir gehört? Oder wer sagt mir, dass du nicht vergessen hast den DNS-Record zu updaten? Wenn ich dann darauf zugreife, vertraue ich dann vielleicht einem wildfremden Host?LG,
CK-
DNS ist dazu da, dass sich die IP/Host ändern darf. Deswegen ja wird ein Certifikat auf den Namen ausgestellt und nicht uf die IP.
wss: auf einer HTTp-Seite ist auch ok. Der Chat ist via Websocket und das ist verschlüsselt. Nicht erlaubt ist ws: in einer Seit die per htttp ausgeliefert wird.
-
Hallo pl,
DNS ist dazu da, dass sich die IP/Host ändern darf. Deswegen ja wird ein Certifikat auf den Namen ausgestellt und nicht uf die IP.
Für sich allein genommen ist da nichts gegen auszusetzen. Setze es in Zusammenhang mit dem Rest, den ich dazu geschrieben habe.
wss: auf einer HTTp-Seite ist auch ok.
Darum ging es nicht.
LG,
CK -
Tach!
DNS ist dazu da, dass sich die IP/Host ändern darf. Deswegen ja wird ein Certifikat auf den Namen ausgestellt und nicht uf die IP.
Ja, aber dynamisches DNS und damit die Vergabe der IP an Dritte ist nicht das, was dabei vorgesehen ist. In Bezug auf Vertraulichkeit schon gleich gar nicht.
wss: auf einer HTTp-Seite ist auch ok. Der Chat ist via Websocket und das ist verschlüsselt. Nicht erlaubt ist ws: in einer Seit die per htttp ausgeliefert wird.
Darum geht es in diesem Teil der Diskussion nicht, sondern um die Vertraubarkeit des Zertifikats. Wenn man das schon nicht kann, nützt die Verschlüsslung selbst auch nicht viel.
dedlfix.
-
-
- Quelle ist unverschlüsselt (
- Quelle ist unverschlüsselt (
-
-
Bevor du weitere Workarounds für selbst signierte Zertifikate überlegst oder einbaust: Schau dir bitte letsencrypt an.
-
Bevor du weitere Workarounds für selbst signierte Zertifikate überlegst oder einbaust: Schau dir bitte letsencrypt an.
Ja, gut. Die Frage ist jedoch, wann nach nunmehr "6 Jahren WebSocket" die Browser auch in der Lage sind, ein eingebautes wss: dem Nutzer so durchzureichen, dass er nicht den Eindruck gewinnt, er sei auf einem der LINUX-Tage und müsse sich erst selbst zertifizieren ;)
-
Irgendwie reden wir aneinander vorbei.
Lets Encrypt befreit den Endnutzer von solchen Überlegungen und Schwierigkeiten.
Der Einzige, der ein klein wenig nachdenken muss, ist derjenige, welcher das Zertifikat einbauen / in seiner Anwendung haben will. Der Endnutzer bekommt nur eine https-Seite zu sehen und keine Warnung oder Aufforderung zu irgendwas - so, wie es sein sollte.
Die Browser gehen alle dazu über, nur noch von einer vertrauenswürdigen CA ausgestellten Zertifikate zu akzeptieren und für den Rest Fehlermeldungen zu werfen, mit denen nur noch ITler etwas anfangen können.
Es gibt kostenlose Zertifikate und daher verlieren selbst-signierte Zertifikate ihre Notwendigkeit.
Und ja, ich weiß, dass ein Zertifikat nicht automatisch vertrauenswürdig wird, nur weil es von einer üblicherweise vertrauenswürdigen CA kommt. Aber das muss jeder für sich selber entscheiden.
-
Irgendwie reden wir aneinander vorbei.
Nein.
Der Einzige, der ein klein wenig nachdenken muss, ist derjenige, welcher das Zertifikat einbauen / in seiner Anwendung haben will. Der Endnutzer bekommt nur eine https-Seite zu sehen und keine Warnung oder Aufforderung zu irgendwas - so, wie es sein sollte.
Ich vermute auch, dass es, wenn wss: (WebSocket SSL) in einer HTTPS-Seite ausgeliefert wird, für den Benutzer keine weiteren Dialoge gibt.
Dazu müsste ich jedoch erst einen HTTPS-Server aufsetzen um das zu testen.
MfG
-
-
-
-
zu erstellen sind? Was mir noch nicht ganz klar ist: Wie bringe ich dann dem Browser bei, dass meinem selbst erstellten Certifikat vertraut werden kann?
Unabhängig von SSL ist es schon für die meisten Chrome Benutzer eine Zumutung, einen Startparameter --explicitly-allowed-ports=6000,6667 in die Desktop-Verknüpfung zu setzen. Darüber haben sich aber auch schon andere aufgeregt, da bin ich nicht der Einzige.
Ansonsten ist es unsinnig, das Geschnatter eines Websocket-Chat verschlüsseln zu wollen: Weil sowieso jeder mithören kann (Broadcast). Da erübrigt sich auch die Frage, ob dem Zertifikat vertraut werden kann.
Ich bin mal gespannt, wie die Entwicklung weitergeht, immerhin gibt es schon seit 6 Jahren Browser die Websocket können. Für meinen Chat habe ich jedenfalls auch ne Lösung, wie mehrere Channels über einen Port abgewickelt werden können und eine Lösung zur Darstellung der aktiven Benutzer zur Echtzeit. MfG
-
Tach!
Unabhängig von SSL ist es schon für die meisten Chrome Benutzer eine Zumutung, einen Startparameter --explicitly-allowed-ports=6000,6667 in die Desktop-Verknüpfung zu setzen. Darüber haben sich aber auch schon andere aufgeregt, da bin ich nicht der Einzige.
Natürlich kann man für Websocket einen anderen Port als 80 nehmen. Das geht ja auch für HTTP. Der Sinn von Websockets ist aber, dass man eine bidirektionale Kommunikation über den Standard-Port 80 laufen lassen kann. Dieser Port ist in den meisten Firewalls freigegeben. Im Gegensatz dazu ist der Port 6667 für IRC vorgesehen und nicht selten gesperrt, weil die lieben Arbeitnehmer arbeiten und im Internet recherchieren können sollen, aber nicht chatten. Es ist also nicht verwunderlich, dass man gegen Wände läuft, wenn man vom Standard abweicht.
Ansonsten ist es unsinnig, das Geschnatter eines Websocket-Chat verschlüsseln zu wollen: Weil sowieso jeder mithören kann (Broadcast). Da erübrigt sich auch die Frage, ob dem Zertifikat vertraut werden kann.
Na, das kommt ja wohl ganz stark darauf an, wen man in den Chat reinlässt. Das mag in deinem Fall so sein, dass es da keine Eingangskontrolle gibt, gilt aber nicht generell.
Ein Anwendungsfall für Chat über Websocket kann ein Support-Chat sein. Da spricht meist ein Mitarbeiter mit einem Kunden direkt, so wie die Kunden am Schalter einzeln mit Diskretionsabstand und nicht alle gleichzeitig bedient werden. Dafür ist vertrauliche und vertrauenswürdige Kommunikation keineswegs irrelevant.
dedlfix.
-
Natürlich kann man für Websocket einen anderen Port als 80 nehmen. Das geht ja auch für HTTP. Der Sinn von Websockets ist aber, dass man eine bidirektionale Kommunikation über den Standard-Port 80 laufen lassen kann. Dieser Port ist in den meisten Firewalls freigegeben. Im Gegensatz dazu ist der Port 6667 für IRC vorgesehen und nicht selten gesperrt, weil die lieben Arbeitnehmer arbeiten und im Internet recherchieren können sollen, aber nicht chatten. Es ist also nicht verwunderlich, dass man gegen Wände läuft, wenn man vom Standard abweicht.
Das war klar, dass Du gar nicht verstehst, worum es eigentlich geht: Nämlich um die proprietäre Lösung die Chrome beschreitet. Anstatt die Einstellungen in der Anwendung Chrome zu verwalten muss ein Parameter in die Desktop Verknüpfung gesetzt werden. Das ist nicht nur schlecht für Benutzer die damit gar nichts am Hut haben sondern auch für diejenigen, die sich jede Extrawurst, die Chrome da brät merken müssen. Die Fehlermeldung, die Chrome da wirft, ist nämlich nicht besonders aussagekräftig.
Und ja, selbstverständlich kann man auch einen anderen Port verwenden womit Chrome den Startparameter gar nicht braucht (z.B. 8080), das hängt aber noch von ein paar anderen Sachen ab über die auch ein Theoretiker gelegentlich mal nachdenken sollte.
-
Tach!
Das war klar, dass Du gar nicht verstehst, worum es eigentlich geht: Nämlich um die proprietäre Lösung die Chrome beschreitet. Anstatt die Einstellungen in der Anwendung Chrome zu verwalten muss ein Parameter in die Desktop Verknüpfung gesetzt werden. Das ist nicht nur schlecht für Benutzer die damit gar nichts am Hut haben sondern auch für diejenigen, die sich jede Extrawurst, die Chrome da brät merken müssen. Die Fehlermeldung, die Chrome da wirft, ist nämlich nicht besonders aussagekräftig.
Ich verstehe schon sehr gut, dass es dir darum geht, den Chrome als Schuldigen hinzustellen. Mit proprietär hast aber du angefangen, indem du einen anderen Port als den vorgesehenen verwendest. Ich erwähnte ja auch noch andere Unwägbarkeiten (Firewall), die deinen Anwendern widerfahren können, die du bisher noch nicht auf dem Schirm hast. Bleib bei 80/443 und die Probleme entstehen gar nicht erst. Welche Not hast du denn, ausgerechnet Ports zu verwenden, die für andere Dienste vorgesehen sind?
dedlfix.
-
-
Na, das kommt ja wohl ganz stark darauf an, wen man in den Chat reinlässt. Das mag in deinem Fall so sein, dass es da keine Eingangskontrolle gibt, gilt aber nicht generell.
Hast Du sowas schonmal programmiert? Access-Control für einen Websocket-Chat mit Broadcast? Soviel ich weiß gibt es sowas noch gar nicht.
Nun Port 443 aber bitte nicht laufend draufklicken, da klingelt mein PC (Sound ist aber abschaltbar).
-
Tach!
Hast Du sowas schonmal programmiert? Access-Control für einen Websocket-Chat mit Broadcast? Soviel ich weiß gibt es sowas noch gar nicht.
Nicht für einen Chat, aber für eine andere Echtzeitkommunikation. Und dafür habe ich SignlR verwendet, das hat Mechanismen zur Authentifizierung und Autorisierung an Bord.
dedlfix.
-
-
-