Mitunter hantiert man im Webdesign mit selbst-signierten SSL-Zertifikaten – was heutige Web-Browser zu Recht sehr verunsichert, hier am Beispiel von Google Chrome 40 unter Mac OS X 10.10 „Yosemite”. Definitiv vertrauenswürdigen Zertifikate kann man aber händisch vertrauen, damit Chrome einem nicht den Workflow versaut.
Hintergrund
Oft sieht man selbst-signierte SSL-Zertifikate im Zusammenhang mit Server-Admin-Oberflächen a’la Plesk oder WHM/cPanel, oft auch bei Vorab-URLs während der Web-Entwicklung. Mitunter siegt schlicht die Knauserigkeit für Dienste, die nur von einem kleinen Personenkreis genutzt werden, für die sich folglich kein kostenpflichtiges Zertifikat lohnt.
Im Grunde wäre das kein Beinbruch – würde Google Chrome einem nur dabei nicht den Spaß verderben. Denn: Zwar kann man wie im o.a. Screenshot gezeigt auf „Erweitert“ klicken, um von dort aus trotz eindringlicher Warnung auf die gewünschte Webseite vorzudringen. Aber während Kollege Firefox an dieser Stelle die Option anbietet, für justament dieses Zertifikat eine permanente Ausnahmeregel zu definieren, ist diese Funktion in Chrome leider auf den ersten Blick nicht vorhanden.
Folglich müsste man das Zertifikat in jeder neuen Session erneut abnicken – was aber leider nicht der einzige Pferdefuß ist:
I see that #Chrome 37 no longer saves and even deletes previously saved passwords for self-signed SSL sites? THANKS, #GOOGLE! (not) :-/ #fb
— Gero (@GerZah) 27. August 2014
Für nicht-vertrauenswürdige Verbindungen streikt seit Chrome Version 37 (von August 2014) der Passwortmanager, unter OSX in Form der Schlüsselbundverwaltung. Sprich: Selbst wenn ein Passwort bereits während der Verwendung einer Chrome-Version vor 37 im Schlüsselbund hinterlegt worden ist: Der jüngere Chrome bietet es für die Webseite mit dem durchgewinkten, nicht vertrauenswürdigen SSL-Zertifikat schlicht nicht mehr zum automatischen Ausfüllen an.
Ausnahmeregel für Chrome (und Safari) unter Mac OS X
„Aber wie lege ich denn nun in Chrome am Mac eine Ausnahmeregel für ein eigenhändig selbst-signiertes und folglich vertrauenswürdiges Zertifikat an?“
Ich wollte gerade sagen „ganz einfach“, was aber untertrieben wäre. 😉 Aber im Grunde ist es doch keine Hexenwissenschaft.
Der Weg führt vom Chrome durchs Mac OS X. Wir exerzieren dies hier anhand meines trauten VM-Entwicklungsservers durch, dessen Name am lokalen DNS-Server „ranger“ lautet. Die ganze Rutsche einmal Schritt für Schritt in Wort und Bild, damit es auch jeder nachvollziehen kann:
Zuerst einmal klickt man auf das Schloss-Symbol mit dem roten „X“, direkt links neben dem durchgestrichenen roten „https“, und anschließend auf das blaue „Zertifikatinformationen“.
Achtung, hier kommt ein Karton: Die Grafik mit dem gelben Rahmen und dem Siegel kann man mit der Maus aus dem Fenster ziehen und folglich das Zertifikat auf dem lokalen Computer speichern. … Und so sieht das dann anschließend aus, wenn man es einfach auf den Desktop gezogen hat. 🙂
… Sorry, darauf wäre ich persönlich vermutlich niemals von selbst gekommen.
Doppelklickt man nun die .cer-Datei, öffnet sich prompt die Schlüsselbundverwaltung:
Wie da schon steht: Wählt man das „Anmeldung“-Schlüsselbund, gilt die Ausnahme nur für den gerade angemeldeten Benutzer. Soll sie für alle Benutzer des Macs gelten, wählt man stattdessen „System“.
In der Schlüsselbundverwaltung wählt man zum eigentlichen Import vorerst „Immer vertrauen“ – auch wenn das an dieser Stelle noch keine Auswirkungen hat. Scheinbar geht es hier primär darum, das Zertifikat überhaupt erst mal ins Schlüsselbund zu bekommen. … Nicht erschrecken: Dabei wird die Schlüsselbundverwaltung das Anmeldepasswort einfordern.
Und schon geht die Sucherei los: Am einfachsten findet man das frisch importierte Zertifikat durch durch Filterung nach Zertifikaten unten links und durch Eingabe des Zertifikatsnamens oben rechts. Auf jeden Fall muss das Zertifikat im Schlüsselbund gesucht, gefunden und anschließend nochmals doppelgeklickt werden.
Gefunden: An dieser Stelle bitte den oben blau markierten kleinen Pfeil neben „Vertrauen“ anklicken, um die Vertrauenseinstellungen auszuklappen.
Da ist er ja, der Schlingel: Für „Secure Sockets Layer (SSL)“ wählt man „Immer vertrauen“. … Wer dem Zertifikat auch anderweitig vertrauen will, kann auch die generelle Einstellung von „System-Standards verwenden“ auf „Immer vertrauen“ umstellen – aber für https-Seitenaufrufe ist dies unnötig.
Schließt man abschließend das Zertifikats-Fenster durch Klick auf die rote Murmel, wird ein weiteres Mal die Eingabe des Anmeldepassworts erforderlich.
Und siehe da: Nach dem Reload der Webseite erscheint eben keine SSL-Warnung mehr, sondern das Schloss-Symbol und das Wort „https“ präsentieren sich nun im freundlichen Grün.
Nebeneffekt
Da das Zertifikat an zentraler Stelle im User-Schlüsselbund von Mac OS X als vertrauenswürdig markiert ist, erkennt neben Chrome auch Safari diese Einstellung sofort an.
Update: Chrome folgt Safari – statt Safari folgt Chrome
Auch anders herum wird ein Schuh draus – und es ist viel einfacher: Ruft man die betreffende Seite mit Safari auf (hier am Beispiel von Safari 8.0.2 unter OSX 10.10.1 Yosemite) …
… und klickt auf „Zertifikat einblenden“ …
… so kann man hier direkt oben auf „Beim Verbinden […] immer […] vertrauen“ anwählen …
… was man nach Klick auf das kleine Dreieck neben „Vertrauen“ auch nachvollziehen kann. Ein Klick auf „Fortfahren“ führt zur Aufnahme des Zertifikats ins Anmeldeschlüsselbund, erfragt also das Anmeldepasswort.
Es ist in diesem Fall nicht mehr nötig, das Schlüsselbund erneut zu öffnen, das Zertifikat zu suchen, um es doppelt zu klicken und in seinen Einstellungen herumzusuchen: Safari ist glücklich – und Chrome ist ebenfalls glücklich, weil Chrome ja dasselbe Schlüsselbund und die darin gespeicherten Zertifikate wie Safari verwendet.
Abschlusserwägung
„Ist das überhaupt sicher?“
Ja. Punkt. Wer eine Ausnahmeregel für ein Zertifikat definiert, das er selbst erstellt und auf dem Webserver installiert hat, der kann der SSL-Datenverschlüsselung ebenso vertrauen wie der seiner Bank.
Sollte der Server nun, was Gott verhüten möge, gehackt werden und sich der Einbrecher am SSL-Zertifikat zu schaffen machen, wird der Browser das geänderte Zertifikat monieren, für das die einzelne Ausnahmeregelung aufgrund des neuen, geänderten Fingerprints ja nicht gilt.
Inspiriert durch …
… den Beitrag „Google Chrome, Mac OS X and Self-Signed SSL Certificates“ von Rob Peck.
Keine Kommentare möglich.