Beschädigter (SSL-)Schlüsselspeicher / Erkennen gefälschter SSL-Zertifikate

Question

Haftungsausschluss: Ich bin neu bei SSL, finde es ein wenig verwirrend und brauche relativ schnell eine Antwort.

Mir wurde gesagt, dass die Gefahr besteht, dass mein „Keystore“ beschädigt sein könnte, also versuche ich, ihn zu untersuchen und zu verstehen. Ich verwende Arch Linux.

Ich sehe eine Menge lustiger Sachen in /etc/ssl/certs(und ich nehme an, Frage Nr. 1 lautet: „Ist das der ‚Schlüsselspeicher‘?“), aber diese Liste wurde viel sinnvoller, als ich sie vollständig durchging readlink -fund Duplikate entfernte. Es sieht so aus, als ob alle meine Zertifikate von stammen /usr/share/ca-certificates/. Der Großteil davon befindet sich im mozilla/Unterverzeichnis, aber es gibt noch andere Unterverzeichnisse wie:

brazil.gov.br/
cacert.org/
debconf.org/
gouv.fr/
signet.pl/
spi-inc.org/

Mein Hauptproblem ist, dass ich nicht weiß, wie ich ein verdächtiges Zertifikat erkenne. Einfach diese Seiten aufzurufen, erscheint mir kontraintuitiv (d. h. sie könnten dieselbe Malware enthalten, die meinen Schlüsselspeicher möglicherweise überhaupt erst beschädigt hat).

ca-certificatesist ein Paket, das von meinem Paketmanager installiert wurde. Kann ich es einfach löschen und dann neu installieren? Ist das sicher?

AKTUALISIEREN:

Der Grund für diese Untersuchung war ein nicht anerkanntes VeriSign-Zertifikat. Genauer gesagt erhielt ich eine Signatur mit einem Zertifikat, das ich nicht hatte (aber vermutlich haben sollte) und dem ich nicht vertraute.

Ich habe auf der Website von VeriSign diese Seite gefunden, auf der eine ganze Reihe von Zertifikaten aufgelistet sind: http://www.verisign.com/support/roots.html ... und so begann ich, die Fingerabdrücke der von mir installierten Zertifikate mit denen auf der Site zu vergleichen.

for cert in /etc/ssl/certs/Veri[Ss]ign*; do
    printf "%s: " $cert
    openssl x509 -noout -in $cert -fingerprint
done

Das Ergebnis: Eines stimmt nicht überein. Klingt auch nach einem wichtigen: „VeriSign Class 1 Public Primary CA“.

Komplikationen: Mein Paketmanager sagt mir, dass die Prüfsumme meiner vorhandenen Zertifikate in Ordnung ist. Außerdem stimmt der Fingerabdruck auf dem Zertifikat, das ich haben sollte, mitwederweder das, das ich habe, noch das, das auf der Site von VeriSign aufgeführt ist.

Answer 1

Von einer Zertifizierungsstelle an Endteilnehmer (z. B. Webserver) ausgestellte Zertifikate werden normalerweise über eine Zwischenzertifizierungsstelle (auch Kettenzertifizierungsstelle genannt) ausgestellt. Dafür gibt es mehrere Gründe. Als Zertifizierungsstellen erstmals damit begannen, Zertifikate auf diese Weise auszustellen, kam es sehr häufig vor, dass Serverbetreiber die Zwischenzertifizierungsstelle nicht installierten, sodass Benutzer, die keine zwischengespeicherte (oder installierte) Kopie des Kettenzertifikats hatten, in einer Situation waren, in der sie sowohl das Stammzertifikat als auch das EE-Zertifikat hatten, aber keine Möglichkeit hatten, sie zu verbinden. Dies kommt heute viel seltener vor, könnte aber das Problem sein, mit dem Sie konfrontiert sind – kommt dies vom Besuch eines öffentlichen Servers? Wenn ja, werde ich für Sie nachsehen. Sie können sich immer den IssuerName des EE-Zertifikats ansehen, das Sie nicht verifizieren können, und prüfen, ob Sie auf der Website von VeriSign ein passendes „Zwischen-CA“-Zertifikat finden. Wenn ja, sollten Sie das EE mit dem Zwischenzertifikat und das Zwischenzertifikat mit der Stammzertifizierungsstelle verifizieren können. Wenn Sie dies manuell angehen, empfehle ich Ihnen, auch eine Zertifikatsvalidierung durchzuführen – OCSP wird von VeriSign auf allen CAs unterstützt … die meisten (alle?) Premium-CAs übertreffen diese Form der Echtzeit-/nahezu Echtzeitvalidierung … andernfalls wären CRLs die nächstbeste Lösung.