Posts Tagged ‘Zertifikat’

Dienstag, 8. August 2017

Google Chrome wieder nützliche Informationen über TLS-Verschlüsselung anzeigen lassen

Als Security Officer befasst man sich gelegentlich auch mit TLS-Zertifikaten von Web-Sites. Wenn man die Zertifikate und die Verschlüsselung einer im öffentlichen Internet ansprechbaren Web-Site bewerten lassen möchte, verwendet man dazu am Besten Qualys SSL Server Test.

Manchmal aber sind Web-Applikationen nur im Intranet erreichbar, oder manchmal möchte man einfach nur ganz rasch in Erfahrung bringen, welche Verschlüsselung eine Web-Site einsetzt.

Bis vor kurzem ging das in Chrome ganz flott: In der URL-Bar klickte man auf das Schloss-Symbol und erhielt mit ein, zwei Klicks alle nötigen Informationen präsentiert. Spätestens seit Version 59 klappt das nicht mehr.

In Version 60 haben die Chrome-Entwickler das Problem resp. den Kundenwunsch erkannt und ermöglichen es neu, die Funktionalität mittels einer Konfigurationseinstellung wieder zu reaktivieren:

  1. Chrome starten
  2. Die URL chrome://flags/#show-cert-link ansurfen
  3. Enable anklicken
  4. Chrome neu starten

Via: Configure Google Chrome to display certificates directly

Und ab sofort gibt es mit Klick auf das Schlosssymbol einer Web-Site wieder den Eintrag „Certificate“:

image-7439

Mit Klick auf Valid öffnet sich danach ein os-spezifisches Fenster mit Informationen zum Zertifikat:

image-7440

Tags: , , , , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 5. Februar 2017

imapfilter wechselnde Zertifikats-Fingerabdrücke ignorieren lassen

imapfilter funktioniert bei mir wunderbar, um in meiner INBOX eintreffende Mails automatisiert in Unterordner zu verschieben.

Dann und wann bricht das per Cron aufgerufene Script seine Arbeit aber ab, weil das Zertifikat des Mail-Servers gewechselt wurde:

imapfilter: certificate mismatch in non-interactive mode

imapfilter muss in einem solchen Fall interaktiv gestartet und das neue Zertifikat permanent akzeptiert werden.

Wen dieses Verhalten stört und die eindeutige Identifikation seiner Gegenseite weniger wichtig ist als ein sauber durchlaufendes Script, fügt oben an seine imapfilter-Regeln folgende Zeile ein:

...
options.certificates = false
...

Quelle: Ignore certificate fingerprint mismatch

Ich habe das bei mir nur für ein kaum genutztes Gmail-Konto aktiviert.

Das Problem könnte mit den hier geschilderten zwei gleichzeitig aktiven, unterschiedlichen Gmail-Zertifikaten zusammenhängen.

Tags: , , , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 4. Januar 2015

Remember The Milk lädt nicht mehr

Frisch zurück aus den Ferien kämpfte ich mit dem Zugriff auf meine Taskliste, welche ich mit der SaaS-Anwendung Remember The Milk verwalte. Wenn ich diese Seite in Safari aufrief, erschien einzig der blaue Hintergrund des Teasers, ohne dass aber die Lade-Animation erschien. In Firefox konnte ich mich problemlos in die Anwendung einloggen.

Ein Blick auf die Web Developer-Konsole in Safari gab mir einen ersten Hinweis, wo das Problem lag:

Safari Web Developer Console
image-6044

Safari akzeptierte das SSL-Zertifikat für die Server s1.rtmcdn.net und s4.rtmcdn.net nicht (mehr). Offenbar hatte Firefox gleichzeitig kein Problem damit, die Server anzusprechen und Ressourcen von dort zu laden. Rückblickend vermute ich, dass Firefox eine eigene Liste vertrauenswürdiger CA Root-Zertifikate mitbringt und nicht auf die OS X-Zertifikate abstellt.

Nach etwas herumpröbeln entschied ich mich, Remember The Milk in Chrome zu öffnen. Der Google-Browser, welcher auch auf WebKit aufsetzt, lud die Applikation ebenfalls nicht, gab aber wenigstens eine deutlich klarere Fehlermeldung von sich:

Google Chrome SSL Error
image-6045

… server presented a certificate that is not yet valid.

Hä? Irgendetwas war also definitiv mit dem Zertifikat nicht in Ordnung, welches von RTM eingesetzt wird. Ein Klick auf den durchgestrichenen https: zeigte mir Details zur Zertifikatskette an. Ich folgte der Kette bis zum Ursprung des Fehlers und sah folgende Fehlermeldung:

DigiCert High Assurance EV Root CA: This certificate has expired
image-6046

Das Zertifikat ist seit dem 26. Juli 2014 nicht mehr gültig? Wieso ich in all dieser Zeit keine Probleme mit dem Zugriff auf RTM hatte, ist mir schleierhaft — evtl. haben die Entwickler erst kürzlich auf dieses Zertifikat gewechselt.

Das war die gesuchte Information. Mittels einer Google-Suche stiess ich äusserst rasch auf einen Blog-Artikel von DigiCert, der genau dieses Problem beschrieb und eine einfache Lösung anbot:

Fix for an Expired Intermediate SSL Certificate Chain

In meiner OS X Keychain war wie in den Screenshots von DigiCert beschrieben ein (abgelaufenes) DigiCert High Assurance EV Root CA abgelegt, welches problemlos gelöscht werden konnte. Keychain schliessen, Safari schliessen und neu öffnen — und ich konnte mich wieder in Remember The Milk einloggen.

Tags: , , , , , , , ,
Labels: Web

Keine Kommentare | neuen Kommentar verfassen

Donnerstag, 27. September 2012

Wenn imapfilter plötzlich mit meinem bei Cyon gehosteten Mail-Server nicht mehr funktioniert

Da verreise ich als auf einen IT-Audit ins „Ländle“, und prompt versagt mein geliebter imapfilter seinen Dienst. Fazit: Meine INBOXes sind plötzlich voller Mails, welche von imapfilter sonst schön brav spätestens 5 Minuten nach deren Ankunft auf meinen Mail-Konti in einen Unterordner verschoben werden. Zuerst dachte ich, dass mein lokaler Linux-Server, auf welchem imapfilter läuft, wegen eines Stromunterbruchs ausgefallen ist.

Doch mittels des äusserst nützlichen SSH-Clients Prompt hatte ich bereits am Dienstag realisiert, dass der Server am Netz hängt und ansprechbar ist.

Ein Blick in das von meinem imapfilter.sh-Script erzeugten Log zeigte, dass das Problem erstmals am Montag um 17 Uhr 15 Minuten aufgetaucht ist (Montag kurz vor Feierabend – dann scheinen die Cyon Sysadmins am liebsten ihre Zertifikate zu erneuern?)

2012-09-24 17:15 - <imapfilter Script> - Error '5' checking mail

Nun gut … letzter Ausweg: Ich versuche mich mittels

imapfilter -d -c <imapfilter Script>

interaktiv anzumelden und Debug-Meldungen abzulegen. Doch zur Analyse dieses Debug-Dumps kommt es nicht, denn auf der Kommandozeile strahlt mich folgender Hinweis an:

Server certificate subject: /OU=Domain Control Validated/CN=*.cyon.ch
Server certificate issuer: /C=BE/O=GlobalSign nv-sa/CN=GlobalSign Domain Validation CA - G2
Server key fingerprint: 39:E9:08:A5:D9:EC:C3:A3:3E:0F:73:7C:14:B7:F2:A5
(R)eject, accept (t)emporarily or accept (p)ermanently? p

Mittels Eingabe von p akzeptiere ich das neue Zertifikat, und gut isses.

Da hat Cyon also einfach nur sein Server-Zertifikat geändert. Wieso nimmt man immer gleich das Schlimmste an?

Tags: , , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen