PKI Viewer — Manual

Vollständige Funktionsbeschreibung des PKI Viewer: File Analyzer, PEM Decoder, Zertifikatsfelder, Signatur- und Kettenprüfung, PKCS#7/12, CRL, S/MIME.

Zurück zur Übersicht: PKI Viewer · Tool live öffnen: www.jpkc.com/tools/pki/

Dieses Manual beschreibt den PKI Viewer vollständig: die vier Tabs, alle erkannten Dateiformate, welche Felder ein Zertifikat preisgibt und wie du sie liest, wie die Signatur-, Ketten- und Schlüsselprüfung arbeitet, sowie die bewussten Grenzen des Tools. Die Oberfläche ist auf Englisch — die Labels stehen hier deshalb in ihrer englischen Originalschreibweise (mit deutscher Erläuterung), damit du dich im echten Interface wiederfindest.

Aufbau der Oberfläche

Der PKI Viewer ist in vier Tabs gegliedert:

  • File Analyzer — Dateien per Drag-and-drop oder Dateiauswahl analysieren (binär oder PEM).
  • PEM Decoder — PEM-kodierten Text oder reines Base64 einfügen; die Ausgabe entsteht schon beim Tippen.
  • Help — unterstützte Formate, Fähigkeiten und Grenzen, ein paar Tipps.
  • Reference — Nachschlagewerk: Dateiendungen, Zertifikatsfelder, OpenSSL-Befehle, Vertrauensmodell.

Die ersten beiden Tabs sind die Arbeitsbereiche, die letzten beiden reine Dokumentation. Beide Arbeitsbereiche haben ihren eigenen Ergebnisbereich — ein Ergebnis im einen Tab bleibt stehen, während du im anderen arbeitest. Ein Hinweis-Banner am Seitenende fasst nochmal zusammen, dass alles im Browser bleibt und die HTML-Vorschau von E-Mails externe Bilder blockiert. Auf schmalen Bildschirmen (unter 576 Pixel) stehen Feldname und Wert in den Ergebnistabellen untereinander.

Tab „File Analyzer"

Hier analysierst du Dateien. Es gibt eine große Drop-Zone mit der Aufschrift „Drag & drop a file here" und darin einen Browse Files-Knopf für den klassischen Datei-Dialog. Die Drop-Zone ist auch per Tastatur bedienbar: Fokus darauf und Enter oder Leertaste öffnen den Dialog. Die angezeigten Endungen (.pem .crt .cer .der .p7b .p7m .p7s .p12 .pfx .csr .crl .key .pub) sind nur eine Orientierung — das Tool erkennt den Typ am Inhalt, nicht am Dateinamen. Eine Datei darf bis zu 50 MB groß sein; größere lehnt es mit einer Meldung ab. PEM-Text und reines Base64 erkennt das Tool allerdings nur in den ersten 4 MB einer Datei (siehe Grenzen und Datenschutz).

Die Datei wird als Binärdaten eingelesen und automatisch erkannt. Die Reihenfolge der Erkennung:

  1. Enthält der Inhalt -----BEGIN …, wird er als PEM verarbeitet — jeder Block einzeln, wie im PEM Decoder.
  2. Besteht er nur aus Base64 ohne PEM-Zeilen (mindestens 64 Zeichen), wird das Base64 dekodiert und als DER weiterverarbeitet. Typisch sind als Text gespeicherte .p7m-Dateien, etwa elektronische Rechnungen.
  3. Andernfalls wird die Datei als DER/BER (binär) gelesen und an ihrer ASN.1-Struktur eingeordnet: PKCS#7/CMS, PKCS#12, Zertifikat, CSR, Sperrliste (CRL), privater Schlüssel (PKCS#8, verschlüsselt PKCS#8, SEC1, PKCS#1) oder öffentlicher Schlüssel (SPKI, PKCS#1). BER mit unbestimmter Länge wird ebenfalls gelesen.
  4. Ist es zwar gültiges ASN.1, aber keines davon, meldet das Tool das ehrlich („Valid ASN.1, but not a recognised certificate, key, CSR, CRL, PKCS#7 or PKCS#12 structure."). Lässt sich gar nichts lesen, steht im Ergebnisbereich „Cannot read this input:" mit dem Grund.

Example und Clear

Über dem Ergebnisbereich liegen zwei Bedienelemente:

  • Das Example-Dropdown lädt mitgelieferte Beispieldateien, gruppiert in zwei Abschnitte:
    • Certificates: ECDSA chain (leaf → intermediate → root) — eine dreigliedrige Kette mit EC-Schlüsseln und RSA-Root; RSA certificate + CA — End-Entity-Zertifikat www.example.com plus Root-CA; PKCS#12 (password: example) — ein Container, den das Tool gleich mit dem Passwort example öffnet.
    • Signed files (P7M): Signed text document, drei S/MIME-Mails (text + HTML + PDF, text + PDF, HTML + 2 attachments), MIME without e-mail headers, MIME starting with a boundary und Plain text (not an e-mail).
  • Clear leert den Ergebnisbereich und das Passwortfeld und blendet die Passwortzeile aus.

PKCS#12-Passwort

Erkennt der File Analyzer einen PKCS#12-Container — egal, ob die Datei .p12, .pfx oder ganz anders heißt —, blendet er eine Zeile PKCS#12 Password mit einem Passwortfeld und einem Open-Knopf ein; im Ergebnisbereich steht „Enter its password above.". Du gibst das Container-Passwort ein und klickst Open (oder drückst Enter). Stimmt es, werden die enthaltenen Zertifikate und privaten Schlüssel angezeigt; stimmt es nicht, meldet eine Einblendung „Wrong password." und das Passwortfeld bleibt zur Korrektur markiert. Andere Fehler beim Öffnen erscheinen als „PKCS#12 error: …". Unterstützt werden aktuelle Container mit AES-Verschlüsselung ebenso wie ältere Formate.

Tab „PEM Decoder"

Dieser Tab nimmt PEM-kodierten Text in einem großen Eingabefeld entgegen — Zertifikate, Ketten, CSRs, CRLs, Schlüssel, PKCS#7 — oder Base64 ohne PEM-Zeilen. Die Ausgabe entsteht schon beim Tippen oder Einfügen (kurz nach der letzten Eingabe); der Knopf Decode stößt die Auswertung zusätzlich von Hand an und meldet bei leerem Feld „Please paste PEM-encoded data first.". Ein Example-Knopf lädt ein selbstsigniertes Beispielzertifikat für example.com, Clear leert Ein- und Ausgabe.

Der Decoder erkennt anhand der Marker, worum es sich handelt:

  • CERTIFICATE, X509 CERTIFICATE, TRUSTED CERTIFICATE → Zertifikat; beliebig viele Blöcke werden einzeln gerendert und zu einer Kette verknüpft.
  • PKCS7, CMS, PKCS #7 SIGNED DATA → PKCS#7/CMS-Container.
  • CERTIFICATE REQUEST, NEW CERTIFICATE REQUEST → CSR.
  • X509 CRL → Sperrliste.
  • PRIVATE KEY, RSA PRIVATE KEY, EC PRIVATE KEY → privater Schlüssel; ENCRYPTED PRIVATE KEY und Blöcke mit Proc-Type: 4,ENCRYPTED → verschlüsselter privater Schlüssel.
  • PUBLIC KEY, RSA PUBLIC KEY → öffentlicher Schlüssel.

Einige weitere Typen erkennt das Tool, kann sie aber nicht darstellen, und sagt das auch („Recognised: … This tool cannot show it."): DH PARAMETERS, EC PARAMETERS, DSA PRIVATE KEY, OPENSSH PRIVATE KEY (mit dem Hinweis, den Schlüssel per ssh-keygen -p -m PEM -f key umzuwandeln), PGP PUBLIC KEY BLOCK und PGP MESSAGE. Unbekannte Marker meldet es als „Unknown PEM type". Einen PKCS#12-Container nimmt der PEM Decoder nicht an — er verweist dafür auf den File Analyzer.

Übergabe aus dem SSL-Checker

Der SSL-Checker im Tool „DNS, SSL, Redirect & URL" hat in seiner Karte Certificate Chain einen Knopf PKI Viewer. Er öffnet den PKI Viewer in einem neuen Tab, wechselt dort in den PEM Decoder, fügt die vom Server gelieferte Kette ein und wertet sie sofort aus („Certificate chain from the SSL checker loaded."). Die Übergabe läuft über den lokalen Speicher deines Browsers; der PKI Viewer löscht den Eintrag, sobald er ihn gelesen hat.

Ergebnisübersicht und Meldungen

Über den Ergebniskarten steht eine Zusammenfassung, etwa „Found 3 certificates, 1 private key." — gezählt werden Zertifikate, private und öffentliche Schlüssel, CSRs („signing requests"), Sperrlisten („revocation lists") und signierte Nachrichten. Zertifikate und Sperrlisten aus einem PKCS#7-Container zählen mit und fließen auch in die Ketten- und Schlüsselprüfung ein.

Die Karten folgen einer festen Reihenfolge: zuerst signierte Inhalte (E-Mail oder Dokument, dann die Signaturen), danach die Kette und die Zertifikate. Dann folgen CSRs, Schlüssel, Sperrlisten und Hinweise in der Reihenfolge der Eingabe; Sperrlisten aus einem PKCS#7-Container kommen zuletzt. Blöcke, die sich nicht lesen lassen, erscheinen als gelbe oder rote Hinweiskarte mit ihrem PEM-Label und dem Grund — die übrigen Blöcke der Eingabe werden trotzdem angezeigt.

Was eine Zertifikatskarte zeigt

Für jedes erkannte Zertifikat rendert das Tool eine Karte. Im Kopf steht der Common Name des Subjects (bei mehreren Zertifikaten mit laufender Nummer #1, #2 …, bei PKCS#12 zusätzlich der hinterlegte Anzeigename) sowie je nach Lage diese Badges:

  • Self-signed — Subject gleich Issuer und die Selbstsignatur ist gültig.
  • Private key included — ein privater Schlüssel in derselben Eingabe gehört zu diesem Zertifikat.
  • CA — laut Basic Constraints ein CA-Zertifikat.
  • der Gültigkeits-Status (siehe Not Before / Not After).

In der Tabelle darunter:

Subject und Issuer

Die Distinguished Names von Inhaber (Subject) und Aussteller (Issuer), zusammengesetzt aus Komponenten wie CN, O, OU, C, ST, L, E, DC, serialNumber oder organizationIdentifier, in der Reihenfolge des Zertifikats. Sind Subject und Issuer identisch, steht hinter dem Issuer „(same as subject)".

Serial Number

Die Seriennummer als großgeschriebener Hex-String mit Doppelpunkten als Trenner (z. B. 30:41:91:13:75:…), ohne führende Null-Bytes.

Version

Die X.509-Version des Zertifikats, heute praktisch immer v3.

Not Before / Not After

Der Gültigkeitszeitraum im Format 2026-03-16 08:19:38 UTC. Hinter Not After steht die Restlaufzeit („N days left"), bei abgelaufenen Zertifikaten „expired N days ago", bei noch nicht gültigen „valid from …". Den Status zeigt das Badge im Kartenkopf; bei Valid, Expires in N days und Expired ist auch das Not-After-Datum in derselben Farbe eingefärbt:

  • Valid (grün) — gültig und mehr als 30 Tage vom Ablauf entfernt.
  • Expires in N days (gelb) — läuft innerhalb der nächsten 30 Tage ab.
  • Expired (rot) — Ablaufdatum bereits überschritten.
  • Not yet valid (graues Badge, Datum ohne Farbe) — Beginn der Gültigkeit liegt noch in der Zukunft.

Signature Algorithm

Der Signaturalgorithmus, übersetzt aus seinem OID. Erkannt werden u. a. MD5/SHA-1/SHA-224/SHA-256/SHA-384/SHA-512 with RSA, RSA-PSS (mit Hash, MGF1-Hash und Salt-Länge), ECDSA with SHA-1/224/256/384/512, Ed25519, Ed448 und DSA. SHA-1- und MD5-Signaturen bekommen ein gelbes Badge weak. Ist der OID unbekannt, zeigt das Tool ihn als rohe Ziffernfolge.

Signature

Hier steht das Ergebnis der Signaturprüfung. Das Tool sucht den Aussteller des Zertifikats in derselben Eingabe (oder nimmt bei selbstsignierten Zertifikaten das Zertifikat selbst) und prüft die Signatur über die Web Crypto API des Browsers:

  • valid — die Signatur stammt vom Schlüssel des genannten Ausstellers, dahinter z. B. „(by #2 Example ECC CA E1)" oder „(self-signed)". Bei SHA-1 kommt der Hinweis SHA-1 (weak) dazu.
  • invalid — die Signatur passt nicht; in manchen Fällen mit Grund, etwa wenn ein ECDSA-signiertes Zertifikat gegen einen RSA-Schlüssel geprüft würde.
  • not checked — mit Grund, z. B. „Issuer certificate not included — not checked." oder weil der Browser das Verfahren nicht unterstützt.

Prüfbar sind RSA (PKCS#1 v1.5) mit SHA-1/256/384/512, RSA-PSS, sofern Hash und MGF1-Hash gleich sind, ECDSA auf P-256, P-384 und P-521 sowie Ed25519, wenn der Browser es kann. Nicht prüfbar sind MD5, SHA-224, Ed448, DSA und die Kurven brainpool und secp256k1 — die Web Crypto API kennt sie nicht. Die Prüfung setzt eine HTTPS-Verbindung voraus, weil der Browser Web Crypto nur dort bereitstellt.

Public Key

Typ und Größe des öffentlichen Schlüssels: bei RSA und RSA-PSS die Bitlänge samt Exponent (z. B. RSA 2048 bit (e = 65537)), bei EC die Kurve (z. B. EC P-256 (prime256v1), auch secp256k1 und die brainpool-Kurven), außerdem Ed25519, Ed448, X25519, X448, DSA und DH.

SHA-1 und SHA-256 Fingerprint

Zwei Fingerprints über die Originalbytes (DER) des Zertifikats, als großgeschriebene Hex-Strings mit Doppelpunkten. Neben jedem steht ein Kopier-Knopf. Der Fingerprint ist der praktischste Wert, um zwei Zertifikate zweifelsfrei als identisch zu bestätigen.

Public Key Pin

Der Public-Key-Pin im Format pin-sha256="…": der Base64-kodierte SHA-256-Hash über den öffentlichen Schlüssel (SubjectPublicKeyInfo), mit Kopier-Knopf. Anders als der Fingerprint bleibt er gleich, wenn ein Zertifikat mit demselben Schlüssel neu ausgestellt wird — nützlich für Certificate Pinning in Apps oder zum Abgleich, ob ein erneuertes Zertifikat den alten Schlüssel weiterverwendet.

Subject Alt Names

Falls vorhanden, die Subject Alternative Names als Badges, je nach Typ mit Präfix DNS:, IP: (IPv4 und IPv6 in lesbarer Kurzform), Email:, URI:, DirName:, otherName: (etwa der Windows-UPN) oder RID:. Bei TLS-Server-Zertifikaten stehen hier die abgedeckten Hostnamen.

Key Usage und Extended Key Usage

Die in der Key Usage-Erweiterung gesetzten Bits (z. B. digitalSignature, keyEncipherment, keyCertSign, cRLSign) und die Extended Key Usage (z. B. serverAuth, clientAuth, codeSigning, emailProtection, timeStamping, OCSPSigning, smartcardLogon, documentSigning), jeweils als Badges. Ist eine Erweiterung als kritisch markiert, steht dahinter das Badge critical — bei Subject Alt Names, Key Usage, Extended Key Usage, Basic Constraints und den übrigen Erweiterungen unter Other Extensions. Bei Key-IDs, Authority Info Access, CRL Distribution Points, Certificate Policies, Certificate Transparency und TLS Feature zeigt das Tool kein Kritisch-Flag an.

Basic Constraints

Ob das Zertifikat ein CA-Zertifikat ist (CA: Yes/No) und, falls gesetzt, die Pfadlängen-Beschränkung (path length: 0 …).

Key Identifier, AIA, CRL-Verteilpunkte und Policies

  • Subject Key ID und Authority Key ID — die Schlüsselkennungen als Hex-String. Über sie ordnet das Tool in einer Kette Zertifikat und Aussteller einander zu.
  • Authority Info Access — die URLs des OCSP-Responders (OCSP) und des Aussteller-Zertifikats (CA Issuers).
  • CRL Distribution Points — die URLs, unter denen die Sperrliste des Ausstellers liegt.
  • Certificate Policies — die Policy-OIDs, bekannte mit Namen wie Domain Validated (DV), Organization Validated (OV), Extended Validation (EV) oder der Let's-Encrypt-Policy, dazu gegebenenfalls die CPS-URL.

Das Tool zeigt diese Adressen nur an; es ruft sie nicht ab.

Certificate Transparency, TLS Feature und weitere Erweiterungen

  • Certificate Transparency — die Anzahl der eingebetteten Signed Certificate Timestamps (SCTs), z. B. „2 signed certificate timestamps".
  • TLS Feature — etwa status_request (OCSP Must-Staple).
  • Other Extensions — alle übrigen Erweiterungen mit Namen (sofern bekannt) und OID, z. B. Name Constraints, Qualified Certificate Statements oder Microsoft-Zertifikatsvorlagen.

PEM-Export

Im Fuß jeder Karte gibt es Show PEM (klappt den PEM-Block auf), Copy PEM (kopiert das einzelne Zertifikat als PEM) und Download .crt (speichert es als Datei, benannt nach dem Common Name). So ziehst du etwa aus einer Kette gezielt ein einzelnes Zertifikat heraus. Dieselben drei Knöpfe haben auch CSR-, Schlüssel- und CRL-Karten, jeweils mit passender Dateiendung (.csr, .pem, .crl) — ausgenommen die Karte für verschlüsselte private Schlüssel, die keinen PEM-Export hat.

Zertifikatskette

Enthält die Eingabe mehr als ein Zertifikat, erscheint vor den Zertifikatskarten die Karte Certificate Chain. Das Tool sucht zu jedem Zertifikat den Aussteller unter den übrigen: Der Issuer-DN muss dem Subject-DN entsprechen, und wo vorhanden, müssen Authority und Subject Key ID übereinstimmen. Die Liste zeigt je Zertifikat einen Sprunglink zur Karte und dahinter:

  • „issued by #N …" mit dem Ergebnis der Signaturprüfung,
  • „self-signed root" (bzw. „self-signed") für selbstsignierte Zertifikate,
  • „issued by … (not included)", wenn der Aussteller nicht in der Eingabe steckt.

Darunter bewertet das Tool die Reihenfolge: „Order: leaf first, each certificate followed by its issuer." in Grün, wenn das End-Entity-Zertifikat vorne steht und jedes weitere das vorherige ausgestellt hat — so erwarten es viele Server und Clients. Andernfalls warnt es gelb „Not in the usual order …". Fehlt ein Aussteller, weist es darauf hin, dass dieser nicht geprüft wird und eine Root in der Regel ohnehin nicht mitgeschickt werden muss. Geprüft werden nur die Signaturen zwischen den gezeigten Zertifikaten; ob du der Root vertraust und ob ein Zertifikat gesperrt ist, bleibt außen vor.

PKCS#7 / CMS und P7M-Inhalt

Bei einem PKCS#7- oder CMS-Container (.p7m, .p7s, .p7b, .p7c, als PEM, DER, BER oder reines Base64) zeigt das Tool zuerst den signierten Inhalt und die Signaturen, danach die enthaltenen Zertifikate als Karten und gegebenenfalls enthaltene Sperrlisten. Ein reines Zertifikats-Bündel (P7B/P7C) ohne Signatur erkennst du daran, dass keine Signaturkarte erscheint — nur die enthaltenen Zertifikate (ab zwei samt Kettenkarte); ein ganz leerer Container wird als solcher gemeldet.

Steckt im Container ein Inhalt, der keine E-Mail ist, erscheint die Karte Signed content. Den Typ erkennt das Tool über Magic Bytes: PDF, XML, HTML, ZIP (auch Office/OOXML), ältere MS-Office-Dateien, PNG, JPEG und GIF; alles andere wird als Text oder als Binärdaten eingestuft. Angezeigt werden Typ mit MIME-Type, Größe und der Dateiname für den Download — der Name der Quelldatei ohne .p7m/.p7s/.p7c/.p7b, bei Bedarf um die passende Endung ergänzt. Bei Text, XML und HTML gibt es zusätzlich eine Vorschau der ersten 4000 Bytes. Der Knopf Download speichert den Inhalt.

Verschlüsselte CMS-Nachrichten (envelopedData, authEnvelopedData) öffnet das Tool nicht. Es meldet stattdessen, dass sie sich nur mit dem privaten Schlüssel des Empfängers öffnen lassen (Mail-Client oder openssl cms -decrypt), und nennt bei envelopedData die Zahl der Empfänger. Andere CMS-Typen außer SignedData, etwa encryptedData, meldet das Tool in einer gelben Hinweiskarte als nicht unterstützt.

Signaturprüfung (Signature)

Die Karte Signature (bei mehreren Signierenden Signatures (N)) listet je Signatur:

  • Signer — das Zertifikat des Unterzeichners mit Common Name und DN, verlinkt auf seine Karte.
  • Signing Time — der vom Unterzeichner angegebene Zeitpunkt, ausdrücklich „(claimed by the signer)".
  • Algorithm — Hash- und Signaturverfahren.
  • Status — valid mit „content unchanged since signing", invalid, gegebenenfalls mit Grund (etwa „The content was changed after signing (message digest does not match).") oder not checked mit Grund (z. B. „The signer's certificate is not included.").

Das Tool vergleicht dazu den Hash des Inhalts mit dem signierten Hashwert und prüft die Signatur mit dem öffentlichen Schlüssel des Unterzeichners. Dessen Zertifikat sucht es nur unter den Zertifikaten im Container selbst, nicht im Rest der Eingabe. Prüfbar sind RSA-, ECDSA- und Ed25519-Signaturen, mit denselben Einschränkungen wie bei Zertifikaten. „Valid" heißt: Der Inhalt ist unverändert und wurde mit dem Schlüssel des gezeigten Zertifikats signiert. Ob du diesem Zertifikat vertraust (Trust-Store, Sperrstatus), prüft das Tool nicht.

Abgetrennte Signaturen (detached)

Bei einer abgetrennten Signatur (typisch .p7s) liegt der signierte Inhalt in einer eigenen Datei. Der Status lautet dann zunächst „needs the signed file", und ein Hinweis „Detached signature — the signed file is separate." bietet den Knopf Select the signed file to verify. Wählst du die Originaldatei aus, prüft das Tool die Signatur gegen sie und bestätigt das mit „Checked against …". Auch diese Datei verlässt deinen Browser nicht.

Eingebettete MIME-E-Mail

Sieht der signierte Inhalt wie eine MIME-E-Mail aus (Header wie From:/To:/Subject:, ein multipart/-Content-Type mit Boundary, oder ein MIME-Text, der direkt mit einer Boundary beginnt), schlüsselt das Tool sie auf:

  • E-mail message — die Header From, To, Cc, Subject, Date und Message-ID; kodierte Header (RFC 2047) werden dekodiert. In der Überschrift steht die Zahl der Anhänge, der Knopf Original (.eml) lädt die rohe MIME-Quelle als .eml-Datei herunter.
  • Text body — der Textteil mit Copy-Knopf.
  • HTML body — der HTML-Teil als Quelltext; Preview schaltet auf eine Vorschau in einem abgeschotteten sandbox-iframe um (zurück mit Source), Copy kopiert den Quelltext. Eingebettete Bilder (cid:) zeigt die Vorschau direkt an. Externe Bilder sind blockiert, weil ihr Abruf dem Absender verraten würde, dass und wann du die Mail geöffnet hast, und deine IP-Adresse. Enthält die Mail solche Bilder, erscheint in der Vorschau ein Hinweis und der Knopf Load remote images, der sie auf deinen ausdrücklichen Wunsch nachlädt.
  • Attachments — jeder Anhang einzeln mit Name, Typ, Größe und gegebenenfalls „inline", samt Download-Knopf; quoted-printable und Base64 werden dabei dekodiert.

Jeder Teil wird mit dem Zeichensatz dekodiert, den er angibt; Dateinamen nach RFC 2231 (etwa filename*=UTF-8''…) und Namen mit Leerzeichen werden korrekt gelesen, sodass Umlaute stimmen.

PKCS#12 / PFX, CSR und Schlüssel

  • PKCS#12 / PFX: Nach Eingabe des Passworts (siehe PKCS#12-Passwort) werden die enthaltenen Zertifikate und privaten Schlüssel angezeigt, jeweils mit ihrem Anzeigenamen (friendlyName), sofern hinterlegt. Gehört ein Schlüssel zu einem der Zertifikate, zeigen das beide Karten an.
  • CSR (PKCS#10): Die Karte Certificate Signing Request zeigt Subject, öffentlichen Schlüssel (alle Typen wie beim Zertifikat), Signaturalgorithmus, das Ergebnis der Signaturprüfung — ein gültiger Status beweist, dass der Antragsteller den passenden privaten Schlüssel besitzt —, den Public-Key-Pin, weitere Attribute (ein gesetztes challengePassword nur als „(set)") und die beantragten Erweiterungen wie Subject Alternative Names, Key Usage oder Extended Key Usage. Export als PEM oder Download .csr.
  • Privater Schlüssel: Die Karte Private Key nennt Typ und Größe (RSA, RSA-PSS, EC, Ed25519 …), das Format (PKCS#8, PKCS#1 oder SEC1) und unter Matching Certificate das Ergebnis des Schlüsselabgleichs: „matches" mit Link auf das passende Zertifikat, „matches none of the certificates", „No certificate in this input — add it to check the pair." oder — selten — „Could not derive the public key in this browser.". Verglichen wird der öffentliche Teil (RSA-Modulus, EC-Punkt, Ed25519-Schlüssel); fehlt er im Schlüssel, leitet das Tool ihn über die Web Crypto API ab. Der Fuß warnt „Private key — keep it secret" und bietet PEM-Export und Download .pem.
  • Öffentlicher Schlüssel: Die Karte Public Key zeigt Typ und Größe, das Format (SPKI oder PKCS#1) und den Public-Key-Pin mit Kopier-Knopf; Export als PEM oder Download .pem.
  • Verschlüsselter privater Schlüssel: Die Karte Encrypted Private Key entschlüsselt nichts, nennt aber das Schutzverfahren unter Protection — bei PBES2 etwa PBKDF2 (HMAC-SHA256, 2,048 iterations) + AES-256-CBC, außerdem das ältere PKCS#12-PBE (SHA-1 + 3DES) und die klassische OpenSSL-PEM-Verschlüsselung mit ihrem Cipher. Zum Ansehen schlägt sie vor, den Schlüssel lokal zu entschlüsseln und die Klartext-Kopie danach zu löschen:
openssl pkey -in key.pem -out key-plain.pem

Sperrlisten (CRL)

Eine Certificate Revocation List (PEM X509 CRL oder DER, auch innerhalb eines PKCS#7-Containers) zeigt das Tool mit Issuer, Version, CRL Number, This Update, Next Update und Signaturalgorithmus. Ist der nächste Aktualisierungszeitpunkt überschritten, erscheint das Badge Next update overdue. Die Zeile Signature prüft die Signatur der Liste, sofern das Aussteller-Zertifikat in derselben Eingabe steckt — sonst meldet das Tool, dass es fehlt, und lässt die Signatur ungeprüft.

Unter Revoked steht die Zahl der gesperrten Zertifikate, darunter eine Tabelle mit Seriennummer, Sperrdatum und Grund (keyCompromise, superseded, cessationOfOperation …), maximal 500 Zeilen, der Rest als „… and N more.". Steckt ein Zertifikat desselben Ausstellers in der Eingabe und steht seine Seriennummer auf der Liste, wird die Zeile rot markiert und mit dem Namen des Zertifikats versehen. Das gilt nur für die angezeigten 500 Zeilen: Ein Treffer weiter hinten in einer großen CRL bleibt unmarkiert. So prüfst du eine heruntergeladene CRL von Hand gegen ein Zertifikat; das Tool selbst lädt keine CRLs herunter.

Tab „Help"

Reine Dokumentation im Tool: eine Tabelle der Supported Formats (Endung, Format, Beschreibung — von .pem über .p7m/.p7s/.p7b/.p7c bis .key/.pub und .crl), je eine Liste What This Tool Can Do und What This Tool Cannot Do sowie Tips — etwa wie du ein Zertifikat aus dem Browser exportierst (Schloss-Symbol in der Adressleiste → Zertifikatsdetails → als .pem/.crt exportieren) und nützliche OpenSSL-Befehle.

Tab „Reference"

Ein kompaktes Nachschlagewerk: eine Tabelle gängiger PKI-Dateiendungen mit Standard, Kodierung und typischem Inhalt (inklusive .ca-bundle und dem nicht unterstützten Java-KeyStore .jks); eine Zertifikatsfeld-Referenz (DN-Komponenten mit OIDs und die wichtigsten X.509v3-Erweiterungen wie SAN, Key Usage, Basic Constraints, Authority/Subject Key Identifier, CRL Distribution Points, Authority Information Access, Certificate Policies); eine Sammlung OpenSSL-Befehle zum Ansehen, Konvertieren, Prüfen und Fingerprinten; und eine kurze Erklärung des PKI-Vertrauensmodells (Root-CA → Intermediate-CA → End-Entity).

Grenzen und Datenschutz

  • Rein clientseitig: Ein eigener Parser auf Basis von node-forge (öffnet in neuem Tab) (englisch) liest die Dateien im Browser, die Signaturen prüft die Web Crypto API. Es gibt keinen Server, der Dateien entgegennimmt, und kein API. Zertifikate, private Schlüssel und PKCS#12-Passwörter verlassen dein Gerät nicht — überprüfbar im Netzwerk-Tab. Vom Server geladen werden nur die Beispieldateien aus dem Example-Menü. Fremde Server kontaktiert der Browser nur, wenn du in der HTML-Vorschau einer E-Mail ausdrücklich Load remote images klickst.
  • Nur Inspektion, keine Erzeugung: Das Tool signiert und generiert nichts — keine Zertifikate, keine Schlüssel, keine CSRs.
  • Keine Vertrauensentscheidung: Es prüft Signaturen nur zwischen den Objekten deiner Eingabe. Es gibt keinen Trust-Store und keine Sperrprüfung per OCSP oder per Download einer CRL.
  • Kein Netzwerkzugriff zu Servern: Es baut keine TLS-Verbindung auf und ruft keine Server-Zertifikate ab — dafür gibt es den SSL-Checker, der die Kette per Knopf übergibt.
  • Nicht prüfbare Signaturen: MD5, SHA-224, Ed448, DSA sowie die Kurven brainpool und secp256k1 kennt die Web Crypto API nicht; solche Signaturen bleiben „not checked". Ed25519 prüft nur ein Browser, der es unterstützt.
  • Keine Entschlüsselung: Passwortgeschützte private Schlüssel und verschlüsselte S/MIME-Nachrichten öffnet das Tool nicht; unterstützt werden ausschließlich PKCS#12-Passwörter.
  • Dateigröße: maximal 50 MB je Datei. PEM-Text und reines Base64 erkennt das Tool nur in den ersten 4 MB einer Datei; die 50-MB-Grenze gilt damit praktisch für binäre (DER/BER-)Dateien. Eine größere Base64-.p7m speicherst du vorher binär, etwa mit base64 -d rechnung.p7m > rechnung-der.p7m.

Für den Einstieg und die Zielgruppen siehe die Übersichtsseite. Konkrete Durchläufe stehen in den Beispielen, Strategie und Stolperfallen in den Tipps & Tricks. Ausprobieren kannst du alles direkt im Tool.