JPKCom DB

PKI Viewer — Beispiele

PKI-Viewer-Durchläufe: Zertifikat und Kette prüfen, P7M-Signatur verifizieren, PKCS#12 öffnen, CSR, Schlüsselpaar und Sperrliste gegenprüfen.

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

Diese Seite zeigt den PKI Viewer an konkreten Durchläufen. Wie die einzelnen Funktionen genau arbeiten, steht im Manual.

Beispiel 1: Ein Zertifikat schnell prüfen

Ziel: aus einem PEM-Block ablesen, für wen ein Zertifikat gilt und wie lange.

  1. Im Tab PEM Decoder den Zertifikatstext (-----BEGIN CERTIFICATE----- …) in das Eingabefeld einfügen. Hast du keinen zur Hand, klick auf Example — das lädt ein selbstsigniertes Beispielzertifikat für example.com.
  2. Kurz warten: Die Karte erscheint schon beim Einfügen. Decode brauchst du nur, wenn du die Auswertung erneut anstoßen willst.

Ergebnis: Es erscheint eine Zertifikatskarte mit Subject, Issuer, Seriennummer und dem Gültigkeitszeitraum samt Restlaufzeit („N days left"). Im Kartenkopf sagt dir ein Badge sofort, ob das Zertifikat Valid, Expired, Not yet valid ist oder in wie vielen Tagen es abläuft. Beim Beispiel siehst du zusätzlich Self-signed — Subject und Issuer sind identisch, und die Zeile Signature bestätigt mit valid (self-signed), dass sich das Zertifikat tatsächlich selbst signiert hat — sowie CA, weil es per Basic Constraints als CA markiert ist.

Beispiel 2: Restlaufzeit und Hostnamen eines Server-Zertifikats prüfen

Ziel: vor einem Deployment kontrollieren, welche Domains ein Zertifikat abdeckt und ob es bald abläuft.

  1. Das Server-Zertifikat als .pem/.crt über File Analyzer → Browse Files laden — oder im Browser über das Schloss-Symbol exportieren und hier reinziehen.
  2. Die Karte ansehen.

Ergebnis: Unter Subject Alt Names stehen die abgedeckten Hostnamen als Badges (DNS:www.example.com, DNS:example.com …), gegebenenfalls auch IP-Adressen als IP:…. Das Feld Not After ist farbig: Steht im Kopf ein gelbes Expires in N days, solltest du die Erneuerung anstoßen. Unter Extended Key Usage bestätigt serverAuth, dass es als TLS-Server-Zertifikat gedacht ist. Willst du es direkt vom laufenden Server holen, geht das über den SSL-Checker — siehe Beispiel 8.

Beispiel 3: Eine Zertifikatskette analysieren

Ziel: eine Kette aus End-Entity-, Intermediate- und Root-Zertifikat verstehen und prüfen.

  1. Im File Analyzer das Example-Dropdown öffnen und ECDSA chain (leaf → intermediate → root) wählen. (Alternativ eine eigene Kette einfügen — mehrere -----BEGIN CERTIFICATE------Blöcke nacheinander.)

Ergebnis: Die Zusammenfassung meldet „Found 3 certificates.", darunter steht die Karte Certificate Chain: www.example.com — issued by #2 Example ECC CA E1, das Intermediate — issued by #3 Example Root CA R1, die Root — self-signed root, jeweils mit dem Badge valid. Der grüne Hinweis „Order: leaf first, each certificate followed by its issuer." bestätigt die Reihenfolge, die Server ausliefern sollten. In den Karten siehst du, dass die Kette Schlüsseltypen mischt: das Leaf mit EC P-256 (prime256v1), das Intermediate mit EC P-384 (secp384r1), die Root mit RSA 3072 bit. Das Leaf zeigt außerdem Authority Info Access (OCSP- und CA-Issuer-URL), CRL Distribution Points, die Policy Domain Validated (DV) und neben den DNS-Namen zwei IP-Adressen im SAN. Per Show PEM / Copy PEM / Download .crt ziehst du jedes Zertifikat einzeln heraus — praktisch, um etwa nur die Root in einen Trust-Store zu übernehmen.

Beispiel 4: Inhalt aus einer signierten P7M-Datei holen und die Signatur prüfen

Ziel: das in einer .p7m-Datei eingebettete Dokument sichtbar machen, herunterladen und sicherstellen, dass es seit dem Signieren nicht verändert wurde.

  1. Im File Analyzer das Example-Dropdown öffnen und Signed text document wählen. (Oder eine eigene .p7m-Datei reinziehen.)

Ergebnis: Das Tool erkennt den PKCS#7-Container und zeigt zuerst die Karte Signed content: Typ „Text", Größe, den Download-Namen example-signed.txt und eine Vorschau des Textes. Über Download speicherst du das Dokument. Darunter fasst die Karte Signature zusammen, wer signiert hat (Test Signing Certificate, verlinkt auf seine Zertifikatskarte), wann laut Unterzeichner, mit welchem Verfahren (SHA-256, RSA) — und unter Status valid mit „content unchanged since signing". Wäre auch nur ein Byte des Inhalts verändert, stünde dort invalid mit dem Hinweis, dass der Message Digest nicht passt.

Ist der eingebettete Inhalt eine E-Mail — probier dafür S/MIME e-mail: text + HTML + PDF —, zeigt das Tool statt Signed content die Karte E-mail message mit den Headern (From/To/Subject/Date/Message-ID), den Text- und HTML-Teil und die Anhänge, die du einzeln herunterladen kannst; die Roh-Mail lässt sich über Original (.eml) sichern. Die Signaturkarte darunter funktioniert genauso.

Beispiel 5: Einen PKCS#12-Container öffnen

Ziel: aus einer passwortgeschützten .p12/.pfx-Datei Zertifikat und privaten Schlüssel ansehen.

  1. Im File Analyzer die .p12- oder .pfx-Datei reinziehen oder per Browse Files wählen. Zum Ausprobieren öffnet Example → PKCS#12 (password: example) einen Beispielcontainer und trägt das Passwort selbst ein.
  2. Bei einer eigenen Datei erscheint die Zeile PKCS#12 Password. Das Container-Passwort eingeben und Open klicken (oder Enter drücken).

Ergebnis: Bei korrektem Passwort meldet das Tool, wie viele Zertifikate und privaten Schlüssel es gefunden hat — beim Beispiel „Found 2 certificates, 1 private key." — und zeigt sie als Karten, samt Anzeigename (www.example.com). Die Schlüssel-Karte nennt Typ (EC P-256 (prime256v1)) und Format und meldet unter Matching Certificate „matches #1 www.example.com"; das passende Zertifikat trägt dafür das Badge Private key included. Bei falschem Passwort kommt die Meldung „Wrong password." — alles bleibt lokal, da kannst du beliebig oft probieren.

Beispiel 6: Einen CSR vor dem Einreichen gegenprüfen

Ziel: kontrollieren, dass ein Certificate Signing Request die richtigen Daten enthält, bevor er zur CA geht.

  1. Im PEM Decoder den CSR-Text (-----BEGIN CERTIFICATE REQUEST----- …) einfügen.

Ergebnis: Die Karte Certificate Signing Request zeigt das Subject (also die beantragten DN-Felder wie CN, O, C), Typ und Größe des öffentlichen Schlüssels und den Signaturalgorithmus. Die Zeile Signature sollte valid zeigen — das belegt, dass der CSR mit dem zugehörigen privaten Schlüssel signiert wurde. Sind im CSR Subject Alternative Names oder andere Erweiterungen beantragt, erscheinen sie wie bei einem Zertifikat, die SANs als DNS:-Badges. So fällt ein Tippfehler im Common Name oder eine vergessene Domain auf, bevor das Zertifikat ausgestellt ist. Den Public Key Pin des CSR kannst du später mit dem des ausgestellten Zertifikats vergleichen: Stimmen beide überein, steckt derselbe Schlüssel darin.

Beispiel 7: Prüfen, ob Zertifikat und privater Schlüssel zusammenpassen

Ziel: vor dem Einspielen auf einen Server sicherstellen, dass cert.pem und key.pem ein Paar sind.

  1. Im PEM Decoder zuerst den Zertifikatsblock und direkt darunter den Block des privaten Schlüssels (-----BEGIN PRIVATE KEY-----, RSA PRIVATE KEY oder EC PRIVATE KEY) einfügen — oder eine kombinierte PEM-Datei mit beidem in den File Analyzer ziehen.

Ergebnis: Die Karte Private Key meldet unter Matching Certificate entweder „matches" mit Link auf das passende Zertifikat — das dann das Badge Private key included trägt — oder „matches none of the certificates". Im zweiten Fall hast du das falsche Paar erwischt, etwa den Schlüssel einer früheren Erneuerung. Ist der Schlüssel verschlüsselt, zeigt das Tool nur die Karte Encrypted Private Key mit dem Schutzverfahren; entschlüssle ihn dann lokal (openssl pkey), prüfe das Paar und lösche die Klartext-Kopie wieder.

Beispiel 8: Die Kette eines Servers aus dem SSL-Checker übernehmen

Ziel: die Zertifikatskette, die ein Server tatsächlich ausliefert, im Detail ansehen.

  1. Im SSL-Checker des Tools „DNS, SSL, Redirect & URL" den Host prüfen.
  2. In der Karte Certificate Chain auf PKI Viewer klicken.

Ergebnis: Der PKI Viewer öffnet sich in einem neuen Tab, wechselt in den PEM Decoder und zeigt die übergebene Kette mit Kettenkarte, Reihenfolge-Hinweis und Signaturprüfung je Glied. So siehst du auf einen Blick, ob der Server ein Intermediate vergisst („issued by … (not included)") oder die Zertifikate in der falschen Reihenfolge schickt.

Beispiel 9: Eine Sperrliste gegen ein Zertifikat halten

Ziel: herausfinden, ob ein bestimmtes Zertifikat auf der CRL seines Ausstellers steht.

  1. Die CRL von der URL unter CRL Distribution Points herunterladen (das Tool selbst lädt nichts nach).
  2. Im PEM Decoder das Zertifikat, das Aussteller-Zertifikat und die CRL als PEM untereinander einfügen. Liegt die CRL nur binär (DER) vor, wandelst du sie vorher um:
openssl crl -inform DER -in issuer.crl -out issuer-crl.pem

Ergebnis: Die Karte Certificate Revocation List zeigt Aussteller, CRL-Nummer, This Update und Next Update sowie die Signatur der Liste, geprüft gegen das mitgelieferte Aussteller-Zertifikat. In der Tabelle der gesperrten Seriennummern ist ein Treffer rot markiert und mit dem Namen deines Zertifikats versehen — dann ist es gesperrt, mit Datum und Grund daneben. Fehlt die Markierung, steht es nicht unter den angezeigten Einträgen. Die Tabelle zeigt höchstens 500 Sperrungen; bei einer längeren Liste prüfst du den Rest per openssl crl -in issuer-crl.pem -noout -text.

Mehr zu den einzelnen Funktionen steht im Manual, strategische Hinweise und Stolperfallen in den Tipps & Tricks. Direkt loslegen kannst du im Tool.