Zertifikatsfehler erkennen und verstehen

Eine erfolgreiche Zertifikatsprüfung liefert meist nur eine kurze Meldung:

producer.pem: OK

Wenn die Prüfung fehlschlägt, wirken die Fehlermeldungen dagegen häufig kryptisch.

In diesem How-to prüfen wir unsere KAPRI-Zertifikatsstruktur Schritt für Schritt und lernen, typische Fehler zu erkennen.

Unsere Struktur sieht so aus:

Root CA
   ↓
Intermediate CA
   ├── Producer
   └── Recipient

Dabei gelten unterschiedliche Aufgaben:

Root CA           stellt das Intermediate-CA-Zertifikat aus
Intermediate CA   stellt Producer- und Recipient-Zertifikate aus
Producer          signiert Package Manifests und KAP-KDMs
Recipient         empfängt verschlüsselte File Keys

Die vollständige Kette prüfen

Zuerst prüfen wir das Producer-Zertifikat:

openssl verify \
  -CAfile root-ca.pem \
  -untrusted intermediate-ca.pem \
  producer.pem

Das erwartete Ergebnis lautet:

producer.pem: OK

Für das Recipient-Zertifikat verwenden wir:

openssl verify \
  -CAfile root-ca.pem \
  -untrusted intermediate-ca.pem \
  recipient.pem

Das erwartete Ergebnis lautet:

recipient.pem: OK

OpenSSL verwendet dabei:

• producer.pem beziehungsweise recipient.pem als zu prüfendes Endzertifikat;
• intermediate-ca.pem zum Aufbau der Zertifikatskette;
• root-ca.pem als vorgegebenen Vertrauensanker.

Mit -show_chain können wir uns die aufgebaute Kette anzeigen lassen:

openssl verify \
  -show_chain \
  -CAfile root-ca.pem \
  -untrusted intermediate-ca.pem \
  producer.pem

Die Kette sollte sinngemäß so aussehen:

producer.pem: OK
Chain:
depth=0: CN=KAPRI Example Producer
depth=1: CN=KAPRI Example Intermediate CA
depth=2: CN=KAPRI Example Root CA

depth=0 ist das Endzertifikat.

depth=1 ist die Intermediate CA.

depth=2 ist die Root CA.

Strenge Prüfung aktivieren

OpenSSL unterstützt aus Kompatibilitätsgründen auch manche älteren oder unvollständigen Zertifikate.

Mit -x509_strict verlangen wir eine strengere Prüfung nach den X.509-Regeln:

openssl verify \
  -x509_strict \
  -show_chain \
  -CAfile root-ca.pem \
  -untrusted intermediate-ca.pem \
  producer.pem

Diese Variante sollte für die Diagnose bevorzugt werden.

Sie erkennt unter anderem:

• fehlende CA-Kennzeichnungen;
• unzulässige pathlen-Angaben;
• fehlende keyCertSign-Berechtigungen;
• inkonsistente Zertifikatserweiterungen.

Subject und Issuer prüfen

Jedes Zertifikat besitzt einen Subject und einen Issuer.

Wir zeigen beide Angaben mit:

openssl x509 \
  -in producer.pem \
  -noout \
  -subject \
  -issuer

Das Ergebnis sollte sinngemäß lauten:

subject=CN=KAPRI Example Producer
issuer=CN=KAPRI Example Intermediate CA

Für die Intermediate CA:

openssl x509 \
  -in intermediate-ca.pem \
  -noout \
  -subject \
  -issuer

Erwartet wird:

subject=CN=KAPRI Example Intermediate CA
issuer=CN=KAPRI Example Root CA

Für die Root CA:

openssl x509 \
  -in root-ca.pem \
  -noout \
  -subject \
  -issuer

Erwartet wird:

subject=CN=KAPRI Example Root CA
issuer=CN=KAPRI Example Root CA

Bei der selbstsignierten Root CA sind Subject und Issuer identisch.

Die Beziehungen müssen zusammenpassen:

Issuer des Producer-Zertifikats
        =
Subject der Intermediate CA

Issuer der Intermediate CA
        =
Subject der Root CA

Passende Namen allein beweisen jedoch noch keine gültige Verbindung. Zusätzlich muss die Zertifikatssignatur mit dem Public Key des Issuers validiert werden.

Diese kryptografische Prüfung übernimmt openssl verify.

Seriennummer anzeigen

Jedes ausgestellte Zertifikat besitzt eine Seriennummer.

Wir zeigen sie mit:

openssl x509 \
  -in producer.pem \
  -noout \
  -serial

Beispiel:

serial=03

Seriennummern müssen innerhalb des Geltungsbereichs einer CA eindeutig sein.

Sie werden unter anderem benötigt, um ein bestimmtes Zertifikat eindeutig zu identifizieren und gegebenenfalls zu widerrufen.

Gültigkeitszeitraum prüfen

Ein Zertifikat ist nur innerhalb seines Gültigkeitszeitraums gültig.

Die Zeitangaben zeigen wir mit:

openssl x509 \
  -in producer.pem \
  -noout \
  -dates

Beispiel:

notBefore=Aug 18 10:00:00 2026 GMT
notAfter=Nov 20 10:00:00 2028 GMT

notBefore bezeichnet den Beginn der Gültigkeit.

notAfter bezeichnet das Ende der Gültigkeit.

OpenSSL prüft standardmäßig gegen die aktuelle Systemzeit.

Die gesamte Zertifikatskette muss zum verwendeten Prüfzeitpunkt gültig sein:

Root CA              gültig
Intermediate CA      gültig
Producer/Recipient   gültig

Ein Endzertifikat kann nicht sinnvoll länger verwendet werden als die CA-Kette, von der es abhängt.

Einen bestimmten Prüfzeitpunkt verwenden

Mit -attime können wir die Kette zu einem bestimmten Zeitpunkt prüfen.

Der Wert wird als Unix-Zeitstempel angegeben:

openssl verify \
  -attime 1798761600 \
  -CAfile root-ca.pem \
  -untrusted intermediate-ca.pem \
  producer.pem

Das ist nützlich, wenn wir nachvollziehen wollen, ob eine Zertifikatskette zu einem früheren oder zukünftigen Zeitpunkt gültig war beziehungsweise sein wird.

Für reproduzierbare Tests sollte der verwendete Prüfzeitpunkt ausdrücklich festgelegt werden.

Basic Constraints prüfen

Die Erweiterung Basic Constraints legt fest, ob ein Zertifikat Zertifikate ausstellen darf.

Wir zeigen die Erweiterung der Intermediate CA mit:

openssl x509 \
  -in intermediate-ca.pem \
  -noout \
  -text

Gesucht wird:

X509v3 Basic Constraints: critical
    CA:TRUE, pathlen:0

Das bedeutet:

• CA:TRUE: Das Zertifikat gehört zu einer CA.
• pathlen:0: Diese CA darf Endzertifikate, aber keine weitere untergeordnete CA ausstellen.

Beim Producer erwarten wir:

X509v3 Basic Constraints: critical
    CA:FALSE

Dasselbe gilt für den Recipient.

Producer und Recipient sind Endzertifikate. Sie dürfen keine weiteren Zertifikate ausstellen.

Key Usage prüfen

Key Usage legt fest, wofür der zugehörige Schlüssel verwendet werden darf.

Root CA

Die Root CA benötigt:

Certificate Sign
CRL Sign

Intermediate CA

Die Intermediate CA benötigt ebenfalls:

Certificate Sign
CRL Sign

Producer

Der Producer benötigt:

Digital Signature

Der Producer verwendet seinen Private Key zum Signieren von:

• Package Manifests;
• KAP-KDMs.

Recipient

Der Recipient benötigt:

Key Encipherment

Der Public Key des Recipients wird verwendet, um File Keys für diesen Recipient zu verschlüsseln.

Die Key Usage eines Zertifikats zeigen wir beispielsweise mit:

openssl x509 \
  -in producer.pem \
  -noout \
  -text

Unter X509v3 Key Usage sollte stehen:

Digital Signature

Beim Recipient sollte stehen:

Key Encipherment

Fehler: Intermediate-Zertifikat fehlt

Lassen wir -untrusted intermediate-ca.pem weg:

openssl verify \
  -CAfile root-ca.pem \
  producer.pem

kann OpenSSL die Verbindung zwischen Producer und Root CA nicht aufbauen.

Eine typische Meldung lautet:

error 20 at 0 depth lookup: unable to get local issuer certificate

Bedeutung:

Producer → ? → Root CA

Das Endzertifikat benennt zwar die Intermediate CA als Issuer, aber das zugehörige Intermediate-Zertifikat wurde nicht bereitgestellt.

Lösung:

openssl verify \
  -CAfile root-ca.pem \
  -untrusted intermediate-ca.pem \
  producer.pem

Fehler: Falsche Root CA

Verwenden wir eine andere Root CA:

openssl verify \
  -CAfile other-root-ca.pem \
  -untrusted intermediate-ca.pem \
  producer.pem

kann die Kette nicht bis zum angegebenen Vertrauensanker aufgebaut werden.

Typische Meldungen sind:

unable to get issuer certificate

oder:

unable to get local issuer certificate

Bedeutung:

Die Zertifikate können möglicherweise untereinander zusammenpassen, enden aber nicht bei der Root CA, die wir als Vertrauensanker angegeben haben.

Fehler: Zertifikat ist noch nicht gültig

Liegt die aktuelle oder vorgegebene Prüfzeit vor notBefore, meldet OpenSSL sinngemäß:

certificate is not yet valid

Mögliche Ursachen:

• falsche Systemzeit;
• falsch gesetzter Zertifikatsbeginn;
• Prüfung gegen einen falschen Referenzzeitpunkt;
• Zertifikat wurde vorzeitig eingesetzt.

Fehler: Zertifikat ist abgelaufen

Liegt die Prüfzeit nach notAfter, erscheint:

certificate has expired

Dabei muss beachtet werden, auf welcher Ebene der Fehler liegt:

depth=0   Producer oder Recipient
depth=1   Intermediate CA
depth=2   Root CA

Ein abgelaufenes CA-Zertifikat kann die gesamte davon abhängige Kette ungültig machen.

Fehler: Intermediate-Zertifikat ist keine CA

Fehlt bei der Intermediate CA:

CA:TRUE

oder steht dort:

CA:FALSE

kann OpenSSL melden:

invalid CA certificate

Bedeutung:

Das Zertifikat wird als Issuer verwendet, ist aber nicht als Certification Authority gekennzeichnet.

Fehler: keyCertSign fehlt

Eine CA muss Zertifikate signieren dürfen.

Fehlt in ihrer Key Usage:

Certificate Sign

kann OpenSSL die Kette ablehnen.

Typische Meldungen sind:

key usage does not include certificate signing

oder:

invalid CA certificate

Die Intermediate CA benötigt deshalb:

keyUsage=critical,keyCertSign,cRLSign

Fehler: pathlen wird überschritten

Unsere Intermediate CA besitzt:

CA:TRUE, pathlen:0

Sie darf damit Endzertifikate ausstellen, aber keine weitere untergeordnete CA.

Würde sie trotzdem eine Sub-CA ausstellen, kann die Prüfung melden:

path length constraint exceeded

Die erlaubte Struktur ist:

Root CA
   ↓
Intermediate CA
   ↓
Endzertifikat

Nicht erlaubt wäre:

Root CA
   ↓
Intermediate CA
   ↓
weitere Intermediate CA
   ↓
Endzertifikat

Fehler: Zertifikat wurde verändert

Wird ein Zertifikat nach seiner Ausstellung verändert oder ist seine Signatur beschädigt, schlägt die kryptografische Prüfung fehl.

Eine typische Meldung lautet:

certificate signature failure

Das bedeutet:

Die Zertifikatssignatur lässt sich mit dem Public Key des angegebenen Issuers nicht erfolgreich validieren.

Mögliche Ursachen sind:

• das Zertifikat wurde beschädigt;
• das falsche Issuer-Zertifikat wurde verwendet;
• Zertifikatsdaten und Signatur passen nicht zusammen.

Fehlertiefe verstehen

OpenSSL gibt bei Fehlern häufig eine Tiefe an:

error 24 at 1 depth lookup: invalid CA certificate

Die Tiefe wird vom geprüften Endzertifikat aus gezählt:

depth=0   Producer oder Recipient
depth=1   Intermediate CA
depth=2   Root CA

Im Beispiel liegt der Fehler bei depth=1, also bei der Intermediate CA.

Das hilft, die problematische Stelle schnell einzugrenzen.

Zertifikatskette und Vertrauen unterscheiden

Ein Ergebnis wie:

producer.pem: OK

bedeutet:

• OpenSSL konnte eine Zertifikatskette aufbauen.
• Die Zertifikatssignaturen sind gültig.
• Die Zertifikate waren zum Prüfzeitpunkt gültig.
• Die CA-Constraints erlauben die Kette.
• Die angegebene Root CA wurde als Vertrauensanker verwendet.

Es bedeutet nicht automatisch:

• dass die Root CA organisatorisch vertrauenswürdig ist;
• dass der Producer zur Veröffentlichung eines bestimmten Knowledge Asset berechtigt ist;
• dass der Inhalt eines Packages akzeptiert werden soll.

Für den Test haben wir root-ca.pem ausdrücklich als Vertrauensanker angegeben.

Die Entscheidung, dieser Root CA tatsächlich zu vertrauen, bleibt eine getrennte organisatorische Entscheidung.

Systematischer Prüfablauf

Bei einem Zertifikatsproblem gehen wir immer in derselben Reihenfolge vor.

1. Zertifikat lesbar?

openssl x509 \
  -in producer.pem \
  -noout \
  -text

2. Subject und Issuer korrekt?

openssl x509 \
  -in producer.pem \
  -noout \
  -subject \
  -issuer

3. Gültigkeitszeitraum korrekt?

openssl x509 \
  -in producer.pem \
  -noout \
  -dates

4. Constraints und Key Usage korrekt?

openssl x509 \
  -in producer.pem \
  -noout \
  -text
``