14. Juli 2025
Einführung
Ein digitales Zertifikat prüfen Sie systematisch, indem Sie Vertrauenskette und Aussteller validieren, Gültigkeit und Widerrufsstatus kontrollieren, den Inhaber mit dem konkreten Vorgang abgleichen und die Entscheidung nachvollziehbar dokumentieren.
Ein Sicherheitsanalyst prüft dazu nicht nur, ob ein Zertifikat in einer Anwendung als „gültig“ angezeigt wird. Entscheidend ist, ob sich für den relevanten Prüfzeitpunkt ein gültiger Zertifizierungspfad zu einem nach der eigenen Richtlinie vertrauenswürdigen Vertrauensanker aufbauen lässt, ob das Zertifikat widerrufen wurde und ob Identität sowie Verwendungszweck zum Vorgang passen.
Die Prüfung trennt deshalb fünf Fragen: Ist die Zertifikatskette technisch konsistent? Ist der Aussteller vertrauenswürdig? Lag der relevante Zeitpunkt innerhalb des Gültigkeitszeitraums? Welchen Widerrufsstatus meldet die vorgesehene Statusquelle? Passt der Zertifikatsinhaber zum erwarteten Unterzeichner oder zur erwarteten Organisation? Erst die zusammengeführten Befunde führen zu einer dokumentierten Annahme- oder Ablehnungsentscheidung.
Für die schrittweise Zertifikatsprüfung unterstützt die Nota Sign in nationalen deutschen und grenzüberschreitenden Signaturprozessen die qualifizierte elektronische Signatur (QES) und die fortgeschrittene elektronische Signatur nach der eIDAS-Verordnung. Die technische Validierung ersetzt jedoch nicht die interne Entscheidung, ob ein bestimmtes Zertifikat für den konkreten Dokumenttyp, die beteiligten Parteien und den vorgesehenen Zweck akzeptiert wird.
Empfangenes Zertifikat erfassen
Zu Beginn wird genau das Zertifikat erfasst, das geprüft werden soll. Quelle, Empfangsweg, Dateiformat, erwarteter Inhaber und vorgesehene Verwendung gehören in das Prüfprotokoll. So bleibt später nachvollziehbar, auf welches Zertifikat sich die Bewertung bezog.
Ein kryptografischer Hash des Zertifikats kann als eindeutiger Fingerabdruck in das Protokoll aufgenommen werden. Er hilft, die geprüfte Datei von späteren Kopien oder ausgetauschten Zertifikaten zu unterscheiden. Ändert sich die Datei, ändert sich auch der Hash.
Ebenso wichtig ist der Prüfanlass. Ein Zertifikat, das für eine Dokumentensignatur verwendet werden soll, kann anderen Anforderungen unterliegen als ein Zertifikat für Authentisierung oder eine Organisationssignatur. Soweit die interne Richtlinie dies vorsieht, werden deshalb auch Key Usage, Extended Key Usage und relevante Certificate Policies mit dem erwarteten Zweck abgeglichen.
Kette und Aussteller prüfen
Bei der Kettenprüfung wird ein Zertifizierungspfad vom Endzertifikat über mögliche Zwischenzertifikate bis zu einem vertrauenswürdigen Vertrauensanker aufgebaut. Maßgeblich ist dabei nicht, ob ein Root-Zertifikat zusammen mit der Datei geliefert wurde, sondern ob der Vertrauensanker nach der eigenen Richtlinie oder dem eingesetzten Trust Store tatsächlich akzeptiert wird.
Der Aussteller lässt sich nicht allein aus dem angezeigten Namen ableiten. Die Issuer-Angabe im Zertifikat muss zum Ausstellerzertifikat passen, und die Zertifikatssignatur muss sich kryptografisch mit dessen öffentlichem Schlüssel verifizieren lassen. Auch Einschränkungen der Zwischenzertifikate, etwa für Zertifizierungsstellen oder zulässige Pfade, gehören zur technischen Bewertung.
Kette und Inhaber bleiben zwei getrennte Befunde. Eine technisch korrekte Kette bestätigt, dass das Zertifikat über den aufgebauten Pfad zu einem akzeptierten Vertrauensanker führt. Sie beweist noch nicht, dass die im Zertifikat genannte Person oder Organisation für den konkreten Vorgang die erwartete Partei ist.
Abweichungen sollten nicht pauschal als „ungültig“ zusammengefasst werden. Fehlt beispielsweise ein Zwischenzertifikat, ist der Vertrauensanker nicht zugelassen oder kann eine Zertifikatssignatur nicht verifiziert werden, wird der konkrete Befund mit seiner Ursache dokumentiert.
Gültigkeit und Widerruf kontrollieren
Als Nächstes werden Beginn und Ende des Gültigkeitszeitraums gegen den relevanten Prüfzeitpunkt gestellt. Liegt dieser vor notBefore oder nach notAfter, war das Zertifikat für diesen Zeitpunkt außerhalb seines Gültigkeitsfensters.
Bei der Prüfung einer bereits vorhandenen elektronischen Signatur kann der relevante Zeitpunkt vom aktuellen Zeitpunkt abweichen. Dann sollte das Protokoll klar unterscheiden, ob der Zertifikatsstatus zum Signaturzeitpunkt, zu einem vertrauenswürdigen Zeitstempel oder zum Zeitpunkt der aktuellen Prüfung bewertet wird.
Der Widerrufsstatus ist davon getrennt zu behandeln. Je nach Zertifikat und Richtlinie erfolgt die Abfrage beispielsweise über OCSP oder eine Zertifikatsperrliste (CRL). Datum und Uhrzeit der Abfrage, verwendete Quelle und gemeldeter Status werden gemeinsam festgehalten.
„Abgelaufen“ und „widerrufen“ sind unterschiedliche Befunde. Ebenso sollte ein nicht ermittelbarer oder unbekannter Widerrufsstatus nicht automatisch als erfolgreicher Status interpretiert werden. Welche Folge daraus entsteht, bestimmt die für den Vorgang geltende Richtlinie.
Inhaber mit dem Prozess abgleichen
Anschließend wird geprüft, ob der im Zertifikat ausgewiesene Inhaber zur erwarteten Person oder Organisation passt. Dafür werden die relevanten Subject- und gegebenenfalls Subject-Alternative-Name-Angaben mit den im Geschäftsprozess hinterlegten Identitätsdaten verglichen.
Der angezeigte Common Name allein reicht für eine belastbare Zuordnung häufig nicht aus. Entscheidend ist, welche Identitätsmerkmale das Zertifikat tatsächlich enthält, wie der Aussteller diese Merkmale geprüft hat und welche Nachweise die interne Richtlinie für den konkreten Vorgang verlangt.
Das Ergebnis des Abgleichs wird mit Datum, Prüfverantwortlichem und Referenz auf den Vorgang dokumentiert. So bleibt sichtbar, dass die technische Zertifikatskette und die geschäftliche Zuordnung des Inhabers unabhängig voneinander bewertet wurden.
Ergebnis aufzeichnen
Ein belastbares Prüfprotokoll hält die Befunde zu Zertifikatskette, Aussteller, Gültigkeitszeitraum, Widerrufsstatus, Inhaber und Verwendungszweck getrennt fest. Zusätzlich sollten Werkzeug, Version, verwendeter Trust Store oder Vertrauensbereich und Zeitpunkt der Auswertung dokumentiert werden.
Offene Fragen werden als offene Befunde geführt, statt bestätigte Prüfschritte zu überschreiben. Das ist besonders wichtig, wenn etwa die Kette technisch aufgebaut werden kann, der Widerrufsstatus aber nicht eindeutig ermittelbar ist oder der Inhaber noch nicht ausreichend mit dem Vorgang abgeglichen wurde.
Die Aufzeichnung sollte außerdem erkennen lassen, welche Daten unmittelbar aus dem Zertifikat stammen und welche Ergebnisse aus externen Statusdiensten oder internen Richtlinien abgeleitet wurden. Dadurch kann eine spätere Prüfung denselben Entscheidungsweg nachvollziehen.
Entscheidung freigeben
Am Ende steht nicht nur das technische Ergebnis, sondern eine freigegebene Geschäftsentscheidung: Das Zertifikat wird für den konkreten Vorgang angenommen, abgelehnt oder bei offenem Befund einer definierten Nachprüfung zugeführt. Die Entscheidung verweist auf die Befunde, die sie tragen.
Eine Anwendung kann ein Zertifikat technisch erfolgreich validieren, während die Organisation es für einen bestimmten Prozess dennoch nicht akzeptiert — etwa weil ein erforderlicher Vertrauensanker, eine Certificate Policy oder ein Identitätsmerkmal fehlt. Umgekehrt darf eine bekannte Ausstellerbezeichnung eine fehlgeschlagene technische Validierung nicht überstimmen.
Der Referenzfall endet daher mit einem vollständigen Prüfprotokoll, einer benannten verantwortlichen Person und einer nachvollziehbaren Freigabe. So wird aus einzelnen Zertifikatsdaten eine reproduzierbare Annahme- oder Ablehnungsentscheidung.
