PKI Viewer — Tipps & Tricks

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 und prüft Signaturen zwischen den Objekten, die du ihm gibst — er trifft aber keine Vertrauensentscheidung. Ein valid bei einer Kette heißt: Jedes Zertifikat wurde von seinem Aussteller in deiner Eingabe signiert — ob sie in der richtigen Reihenfolge stehen, sagt der separate Reihenfolge-Hinweis. Ob die Root in einem Trust-Store steht, ob ein Zertifikat zurückgezogen wurde oder ob ein Browser die Verbindung akzeptieren würde, sagt es dir nicht. Das sind bewusste Grenzen:

Kein Trust-Store — eine selbst gebaute Kette mit eigener Root ist für das Tool genauso „valid" wie eine öffentliche.
Keine OCSP- oder Online-CRL-Sperrprüfung — ein angezeigtes „Valid" im Kartenkopf heißt nur „zeitlich gültig", nicht „nicht widerrufen". Eine CRL, die du selbst herunterlädst und mit in die Eingabe legst, gleicht das Tool aber gegen deine Zertifikate ab.
Kein Server-Test — das Tool verbindet sich nicht zu einem Host. Für „passt das Zertifikat zum laufenden Server?" nimmst du den SSL-Checker und übergibst die Kette von dort per Knopf PKI Viewer.

Nutze den Viewer also als Aufschlüsselung und Konsistenzprüfung 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.

Geht es dagegen um den Schlüssel, ist der Public Key Pin (pin-sha256) der richtige Wert: Er bleibt gleich, wenn ein Zertifikat mit demselben Schlüssel erneuert wird, und ändert sich, sobald ein neuer Schlüssel im Spiel ist. Vergleichst du den Pin eines CSR mit dem des ausgestellten Zertifikats, weißt du sofort, ob die CA wirklich deinen Schlüssel zertifiziert hat.

Den Ablauf im Blick behalten

Das Feld Not After ist farbcodiert und nennt die verbleibenden Tage: Ein gelbes Expires in N days erscheint, sobald höchstens 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. Bei einer Kette lohnt der Blick auf jede Karte: Ein ablaufendes Intermediate legt den Dienst genauso lahm wie ein ablaufendes Server-Zertifikat.

Self-signed und CA richtig lesen

Zwei Badges werden gern verwechselt:

Self-signed heißt: Subject gleich Issuer, und die Signatur des Zertifikats lässt sich mit seinem eigenen Schlüssel bestätigen. 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). Fehlt das Badge trotz „(same as subject)" hinter dem Issuer, ist die Selbstsignatur ungültig oder ließ sich im Browser nicht prüfen — die Zeile Signature zeigt das Ergebnis, gegebenenfalls mit Grund.
CA heißt: Basic Constraints CA: Yes — das Zertifikat darf andere Zertifikate signieren.

Ein Root-CA-Zertifikat trägt typischerweise beide Badges, ein Intermediate nur CA, ein normales Server-Zertifikat keines.

Kettenreihenfolge: Leaf zuerst

Manche Server und Clients erwarten die Kette in einer festen Reihenfolge: zuerst das eigene Zertifikat, dann das Intermediate, das es ausgestellt hat, und so weiter. Genau das prüft der Hinweis unter der Karte Certificate Chain. Steht dort gelb „Not in the usual order", sortierst du die PEM-Blöcke in deiner fullchain.pem um. Die Root musst du in der Regel nicht mitschicken — der Client hat sie ohnehin im eigenen Trust-Store. Fehlt dagegen ein Intermediate („issued by … (not included)"), kann ein Client die Kette nicht bis zu seiner Root verfolgen.

Beim Öffnen sensibler Dateien: die Privacy-Garantie nutzen

Weil die gesamte Analyse im Browser läuft — Parser und Signaturprüfung inklusive —, 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; Anfragen gehen nur raus, wenn du eine Beispieldatei aus dem Example-Menü lädst oder in einer Mail-Vorschau ausdrücklich Load remote images klickst (dann lädt der Browser die Bilder vom Server des Absenders). Bei falschem PKCS#12-Passwort kannst du beliebig oft neu probieren, ohne dass etwas das Gerät verlässt.

Zertifikat und Schlüssel in einem Rutsch prüfen

Die häufigste Panne beim Zertifikatstausch: Der neue Schlüssel landet neben dem alten Zertifikat. Leg deshalb Zertifikat und privaten Schlüssel zusammen in den PEM Decoder — die Karte Private Key sagt dir unter Matching Certificate sofort, ob beide zusammengehören, und das passende Zertifikat bekommt das Badge Private key included. Das funktioniert für RSA-, EC- und Ed25519-Schlüssel und in den Formaten PKCS#8, PKCS#1 und SEC1. Ist der Schlüssel verschlüsselt, zeigt dir das Tool nur das Schutzverfahren; dann entschlüsselst du ihn kurz lokal mit openssl pkey und löschst die Klartext-Kopie nach der Prüfung wieder.

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 und Download .crt 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. Die Liste in der Karte Certificate Chain zeigt dir dabei, welches Zertifikat welches ausgestellt hat; ein Klick auf einen Namen springt zur jeweiligen Karte.

P7M: Inhalt, Signatur und Zertifikat gehören zusammen

Bei .p7m-Dateien interessiert meist dreierlei: das signierte Dokument, die Gültigkeit der Signatur und das Signaturzertifikat. Das Tool zeigt alles in dieser Reihenfolge — die Karte Signed content (bzw. E-mail message bei S/MIME) mit Download, die Karte Signature mit dem Prüfergebnis und darunter die enthaltenen Zertifikate. Lies das valid genau: Es bestätigt, dass der Inhalt seit dem Signieren unverändert ist und mit dem Schlüssel des gezeigten Zertifikats signiert wurde. Ob du dem Zertifikat vertraust, entscheidest du selbst — schau dir dafür dessen Karte an: Aussteller, Gültigkeit, Extended Key Usage (emailProtection bei S/MIME, documentSigning bei Dokumentsignaturen). Die Signing Time stammt vom Unterzeichner selbst und ist kein unabhängiger Zeitstempel.

Liegt nur eine abgetrennte Signatur vor (.p7s neben der eigentlichen Datei), lädst du zuerst die .p7s und wählst dann per Select the signed file to verify das Original aus.

Externe Bilder in S/MIME-Mails bewusst laden

Die HTML-Vorschau einer signierten Mail blockiert Bilder von fremden Servern. Das ist Absicht: Ein einziges geladenes Bild — oft ein unsichtbares Tracking-Pixel — verrät dem Absender, dass und wann du die Mail geöffnet hast, und dazu deine IP-Adresse. Eingebettete Bilder (cid:) erscheinen trotzdem. Brauchst du die externen Bilder wirklich, klickst du in der Vorschau auf Load remote images — aber erst, wenn du dem Absender vertraust.

Wenn eine Signatur „not checked" bleibt

not checked ist kein Fehler im Zertifikat, sondern heißt: Das Tool konnte nicht prüfen, und der Grund steht direkt daneben. Die häufigsten Ursachen:

Aussteller fehlt — „Issuer certificate not included". Füge das Intermediate- oder Root-Zertifikat zur Eingabe hinzu.
Unterzeichner-Zertifikat fehlt — „The signer's certificate is not included." Bei P7M-Dateien sucht das Tool das Zertifikat des Unterzeichners nur im Container selbst; ein zusätzlich eingefügtes Zertifikat hilft hier nicht. Dann bleibt die Kommandozeile, etwa openssl cms -verify.
Verfahren nicht in Web Crypto — MD5, SHA-224, Ed448, DSA sowie die Kurven brainpool und secp256k1 kennt die Web Crypto API nicht. Hier hilft nur die Kommandozeile, etwa openssl verify für Zertifikate oder openssl cms -verify für P7M-Dateien.
Ed25519 im Browser — ältere Browser unterstützen Ed25519 in Web Crypto noch nicht; ein aktueller Browser löst das.
Keine HTTPS-Verbindung — Web Crypto steht nur in sicheren Kontexten zur Verfügung. Das betrifft Zertifikate, CSRs und Sperrlisten; P7M-Signaturen bleiben ohne HTTPS bei „checking…" stehen.

Alle übrigen Felder — Subject, SANs, Gültigkeit, Fingerprints, Schlüssel — zeigt das Tool in jedem Fall korrekt an.

Kombination mit anderen JPKCom-Tools

DNS, SSL, Redirect & URL — die Kette eines Servers abrufen und per Knopf PKI Viewer zur Detailanalyse übergeben.
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.
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.