PKI Viewer — Tipps & Tricks
Strategie und Stolperfallen für den PKI Viewer: Fingerprints abgleichen, Ablauf im Blick behalten, was der Viewer nicht prüft, Privacy und Kombinationen.
Zurück zur Übersicht: PKI Viewer · Tool live öffnen: www.jpkc.com/tools/pki/
Der PKI Viewer ist schnell bedient — der Mehrwert liegt darin, die richtigen Felder zu lesen und die Grenzen des Tools zu kennen. Diese Seite sammelt, worauf es in der Praxis ankommt. Die technischen Grundlagen dazu stehen im Manual.
Der Viewer prüft, er urteilt nicht
Die wichtigste Einordnung zuerst: Der PKI Viewer liest Zertifikate, bewertet sie aber nicht im Sinne einer Vertrauensentscheidung. Er sagt dir nicht, ob ein Zertifikat von einer vertrauenswürdigen CA stammt, ob es zurückgezogen wurde oder ob die Kette lückenlos zu einem Root führt. Das sind bewusste Grenzen:
- Keine Ketten-Validierung gegen einen Trust-Store.
- Keine OCSP-/CRL-Sperrprüfung — ein angezeigtes „Valid" heißt nur „zeitlich gültig", nicht „nicht widerrufen".
- Kein Server-Test — das Tool verbindet sich nicht zu einem Host. Für „passt das Zertifikat zum laufenden Server?" brauchst du
openssl s_clientoder einen Online-SSL-Checker.
Nutze den Viewer also als Aufschlüsselung dessen, was in der Datei steht — nicht als Trust-Urteil.
Fingerprints sind der zuverlässigste Abgleich
Willst du sicher sein, dass zwei Zertifikate identisch sind, vergleiche den SHA-256 Fingerprint, nicht den Common Name oder die Seriennummer. Der Fingerprint hängt am gesamten Zertifikat; schon ein verändertes Byte ergibt einen völlig anderen Wert. Der Kopier-Knopf neben dem Fingerprint macht den Abgleich mit dem Wert aus dem Browser oder einem Monitoring-System bequem. SHA-1 zeigt das Tool zusätzlich, vor allem für ältere Systeme — verlasse dich für Abgleiche aber auf SHA-256.
Den Ablauf im Blick behalten
Das Feld Not After ist farbcodiert: Ein gelbes Expires in N days erscheint, sobald weniger als 30 Tage Restlaufzeit bleiben, rot bei Expired. Das ist ein guter Schnelltest, ersetzt aber kein Monitoring — der Viewer prüft nur, was du ihm gerade gibst. Für produktive Endpunkte gehört die Ablaufüberwachung automatisiert; der Viewer ist das Werkzeug für den schnellen manuellen Blick zwischendurch.
Self-signed und CA richtig lesen
Zwei Badges werden gern verwechselt:
- Self-signed heißt: Subject gleich Issuer — das Zertifikat hat sich selbst signiert. Das ist bei jedem Root-CA-Zertifikat normal, bei einem End-Entity-Zertifikat dagegen ein Zeichen, dass es nicht von einer CA stammt (z. B. ein Test- oder internes Zertifikat).
- CA heißt: Basic Constraints
CA: Yes— das Zertifikat darf andere Zertifikate signieren.
Ein Root-CA-Zertifikat trägt typischerweise beide Badges, ein normales Server-Zertifikat keines.
Beim Öffnen sensibler Dateien: die Privacy-Garantie nutzen
Weil die gesamte Analyse clientseitig über node-forge läuft, ist es unbedenklich, echte private Schlüssel und PKCS#12-Passwörter hier einzugeben — nichts wird hochgeladen. Wenn du ganz sichergehen willst, öffne vorher den Netzwerk-Tab der Entwicklertools: Beim Analysieren siehst du keinen Upload deiner Datei. Bei falschem PKCS#12-Passwort kannst du beliebig oft neu probieren, ohne dass etwas das Gerät verlässt.
Aus der Kette einzelne Zertifikate herauslösen
Wenn du eine Kette oder ein .ca-bundle lädst, rendert das Tool jedes Zertifikat einzeln — inklusive Copy PEM pro Karte. Das ist der schnelle Weg, um etwa nur das Intermediate- oder nur das Root-Zertifikat aus einem Bündel zu ziehen, ohne die Blöcke von Hand zu trennen. Den Issuer/Subject-Abgleich der Karten nutzt du, um die Reihenfolge der Kette zu verstehen.
P7M: erst der Inhalt, dann die Zertifikate
Bei .p7m-Dateien interessiert oft beides: das signierte Dokument und das Signaturzertifikat. Das Tool zeigt beides — die Karte Encapsulated Content für den Inhalt (mit Download und, falls es eine MIME-Mail ist, mit Header/Anhang-Aufschlüsselung) und darunter die enthaltenen Zertifikate. Beachte: Der Viewer extrahiert den signierten Inhalt, er verifiziert die Signatur nicht kryptografisch. Für die reine Inhalts-Rettung aus einer signierten Mail reicht das; für „ist die Signatur gültig?" brauchst du ein S/MIME-fähiges Werkzeug.
RSA jetzt, EC nur teilweise
Volle Schlüssel-Details (Bitlänge usw.) gibt es derzeit nur für RSA. Bei EC-Zertifikaten erkennt das Tool zwar den Signaturalgorithmus (ECDSA with SHA-256 …), zeigt beim öffentlichen Schlüssel aber unter Umständen nur Unknown type. Lass dich davon nicht irritieren — das restliche Zertifikat (Subject, SANs, Gültigkeit, Fingerprints) wird trotzdem korrekt angezeigt.
Kombination mit anderen JPKCom-Tools
- Cryptor (AES-256) — wenn ein gemeinsames Passwort statt asymmetrischer Kryptografie reicht, um einen Text vertraulich weiterzugeben.
- Hash-Generator — Prüfsummen über Zertifikats- oder Schlüsseldateien legen, um Beschädigungen oder Vertauschungen zu erkennen.
- Passwort- & Schlüssel-Generator — ein starkes Passwort erzeugen, etwa für einen neuen PKCS#12-Container.
Die vollständige Funktionsbeschreibung steht im Manual, konkrete Durchläufe in den Beispielen. Ausprobieren kannst du alles im Tool.