cert8.db ist kein Wegwerf-Cache: Prüfen Sie den Besitzer des Speichers

Ein alter Support-Thread rät, eine Datei namens cert8.db zu löschen, und das VPN läuft wieder. Diese Abfolge ist öfter ein Zufall als eine Reparatur. Die Datei ist eine Zertifikatsdatenbank, und ihr Entfernen ändert dauerhaften Sicherheitszustand auf Weisen, die ein erfolgreicher Start nicht zeigt.

Ein eingefrorener Login ist kein Cache-Problem

Ein Browsercache speichert Kopien von Ressourcen; eine Zertifikatsdatenbank speichert Vertrauensentscheidungen, Zertifikate und die zugehörigen Schlüssel. Die zweite zu löschen ist näher an einem Zurücksetzen der Identität als an einem Löschen des Verlaufs. Wenn der Client beim Anmelden eingefroren ist, ist der nützliche Beweis, welcher Prozess welches Profil geöffnet und was er protokolliert hat, nicht welche Datei ein Forenbeitrag entfernt hat. Das Einfrieren zu reproduzieren und das Client-Log zu lesen dauert länger als das Löschen einer Datei, und es ist der einzige Weg zu einer echten Ursache.

Der Dateiname trägt auch Geschichte: NSS unterscheidet die alten cert8.db und key3.db von den SQLite-Dateien cert9.db und key4.db. Notieren Sie die Logzeile, die Sie vor dem Einfrieren gesehen haben, denn sie ist der einzige dauerhafte Beweis.

Welches Profil der Client tatsächlich öffnet

Bestimmen Sie den Client, seine Authentifizierungsmethode und den Speicher, den er liest. Es gibt hier drei Anmeldewege: browserunterstützt, eingebetteter Browser und nativer Client, und sie müssen kein Profil teilen. Eine Datenbank mit dem richtigen Namen in einem anderen Verzeichnis ist kein Beweis dafür, dass der eingefrorene Prozess sie geöffnet hat. Unter Linux liegt der NSS-Speicher meist unter ~/.pki/nssdb des Benutzers oder in einem anwendungseigenen Profilverzeichnis. Beide Anordnungen können auf einer Maschine koexistieren, prüfen Sie also beide, wenn die Migration kürzlich erfolgte.

Listen Sie vor einer Änderung auf, was der Speicher enthält: certutil -L -d sql:$HOME/.pki/nssdb gibt die Zertifikate aus, und dasselbe Werkzeug mit -K zeigt, ob Schlüssel vorhanden sind.

Meldet der Befehl, die Datenbank lasse sich nicht öffnen, haben Sie das Profil gefunden, das das Werkzeug nutzt, nicht unbedingt das, welches das VPN nutzte.

Sichern Sie das Profil vor jeder Reparatur

Schließen Sie die betroffenen Anwendungen und kopieren Sie dann das gesamte Profilverzeichnis mit der genehmigten Sicherungsmethode. Zertifikats- und Schlüsseldatenbanken sind verwandter, aber getrennter Zustand, und eine beliebige Datei zu sichern ist kein Wiederherstellungsplan für die ganze Identität. Schützen Sie die Kopie, denn das Profil kann private Schlüssel enthalten. Halten Sie fest, was Sie wohin gesichert haben, damit eine gescheiterte Reparatur einen Rückweg hat.

Bestätigen Sie dann den genauen Umfang der Reparatur mit dem Betreuer. Ein vollständiges Zurücksetzen des Speichers, das Entfernen eines bekannten veralteten Zertifikats und eine Reparatur des Browserprofils sind drei verschiedene Änderungen mit drei verschiedenen Risiken.

Nach der Reparatur anmelden und den Speicher prüfen

Melden Sie sich nach einer autorisierten Reparatur an der VPN an und bestätigen Sie, dass das Serverzertifikat weiterhin wie vorgesehen validiert wird. Prüfen Sie, dass die für den Ablauf nötigen Identitäten noch vorhanden sind und kein unerwarteter Vertrauensanker aufgetaucht ist. Eine Reparatur, die die Verbindung durch mehr Vertrauen als zuvor zum Laufen bringt, ist keine Reparatur.

Trennen Sie Beobachtung und Anweisung: eine Löschung und ein erfolgreicher Start sind keine allgemeine Lösung.

Kehrt das Einfrieren zurück, erfassen Sie Client-Log und genutztes Profil, bevor Sie sonst etwas ändern. Dieser Datensatz macht aus einer Vermutung eine Diagnose.