Certificate Chaining – Prozess mit dem Anwendungen Zertifikate validieren

Eine Anwendung muss zunächst die Gültigkeit eines Zertifikats (meist mit Hilfe der Crypto-API des Betriebssystems) genau prüfen, bevor sie es sicher verwenden kann.

Der Prozess der Zertifikatsverkettungsprüfung wird  dabei in zwei Teilen- durchgeführt

• Aufbau der Certificate Chain und
• Validierung der Certificate Chain

Aufbau der Certificate Chain:

a) Sammeln der Zertifikate für die Kette

Für eine erfolgreiche Zertifikatvalidierung muss sich jedes CA-Zertifikat der zugehörigen Zertifikatkette (von der ausstellenden CA bis zur Root CA) im Zertifikats-Store oder Cache des Clients befinden.

Um die Zertifikate im Cache aufzufinden und in die richtige Ordnung zu bringen, nutzt der Client den Umstand, dass jedes ausgestellte X.509 Zertifikat immer einen Verweis auf die übergeordnete Zertifizierungsstelle hat.

Der Client beginnt dann beim zu validierenden Endanwender-Zertifikat und verwendet – je nachdem welche Extensions im Zertifikat befüllt sind – nacheinander verschiedene Abgleichverfahren, die in ihrer Exaktheit differieren, um jeweils das nächste übergeordnete Zertifikat zu ermitteln

1. Exact Match: Erstellt immer eine eindeutige Zuordnung über den Namen und die Seriennummer des Zertifikats der übergeordneten CA.
2. Key Match: Falls Exakt Match fehlschlägt, versucht dieses Verfahren eine Zuordnung über den Public Key Fingerprint der übergeordneten CA.
3. Name Match: Falls Key Match fehlschlägt, versucht dieses Verfahren eine einfache Zuordnung über den Namen der übergeordneten CA.

Falls alle Abgleichmethoden fehlschlagen, um das entsprechende Zertifikat am Client zu finden, wird versucht, über die URL (FTP, http, LDAP etc.), die in der Authority Information Access (AIA) Extension hinterlegt ist, online die fehlenden Zertifikate in den Cache herunterzuladen. Wenn auch auf diesem Weg keine entsprechenden Zertifikate gefunden werden, schlägt die Validierung fehl und das Zertifikat wird als unsicher eingestuft.

Siehe auch Zertifikatverkettung und Validierung im Detail

b) Finden der vertrauenswürdigen CA

Andernfalls geht der Certificate Chaining Prozess nun über die erstellte Zertifikatkette immer solange eine CA Ebene nach oben, bis ein Root- oder Intermediate CA Zertifikat in der Kette gefunden wird, das sich in der Liste der vertrauenswürdigen Zertifizierungsstellen der Anwendung befindet.

Wurde ein solcher Trust Anchor gefunden – so wird der Chain Validation Process gestartet. Ist dies dagegen nicht der Fall, so wird das Zertifikat als nicht vertrauenswürdig eingestuft.

Achtung für viele Chaining Implementierungen kann der Trust Anchor nur eine Root CA sein, daher ein Trust Anchor wie in der Grafik auf der Intermediate CA wäre dann nicht möglich – dem Endzertifikat würde nicht vertraut!

Chain Validation:

Nun wird vom gefundenen Trust Anchor aus die Zertifikatskette in  entgegengesetzter Richtung durchlaufen, wobei für jedes Zertifikat folgende Punkte geprüft werden:

• Gültigkeitszeitraum: Das aktuelle Datum muss zwischen dem Beginn und dem Ende der Gültigkeitsperiode liegen –  ist die Uhrzeit der Rechner im Netzwerk nicht synchron, kann es hier zu großen Problemen kommen
• Erkennung: Das Zertifikat muss dem X.509 Standard entsprechen.
• Inhalt: Erforderliche Attribute, kritische Extensions und evtl. Anwendungsrichtlinien müssen korrekt befüllt sein.
• Integrität: Ein von einer CA signiertes Zertifikat kann jederzeit auf korrekte Integrität geprüft werden.  Dabei wird ein Hashwert über die Payload des Zertifikats gebildet und dann die Digitale Signatur des Zertifikats mit dem öffentlichen Schlüssel der CA entschlüsselt. Anschließend wird der entschlüsselte Hashwert mit dem vorher berechneten verglichen – stimmen beide Werte überein, so ist die Integrität gewährleistet.
• Sperrprüfung – Certificate Revocation Checking: Falls die Anwendung für eine Sperrprüfung konfiguriert wurde, prüft das System mittels der Seriennummer des Zertifikats die Zertifikatsperrliste CRL, um zu ermitteln, ob das Zertifikat gesperrt wurde. Hat der prüfende Client keine aktuelle CRL im Cache, kann er sie über die CRL Distribution Point Extension (CDP), die im Zertifikat referenziert ist, nachladen. Schlägt dies fehl oder ist das Zertifikat auf der Sperrliste, so lehnt die Anwendung das Zertifikat ab

Anm.: Alle seit dem letzten Reboot durchgeführten Verkettungsprozesse werden im Cache hinterlegt und müssen nicht jedes Mal neu durchgeführt werden.

Vgl. De Clercq, Jan et al.: „A Guide to Windows Certification & Public Keys“, S.27-30.
Guide to Windows Certification & Public Keys
Vgl. Microsoft Corporation: „Implementieren und Verwalten der Sicherheit in einem Microsoft Windows 2003 Netzwerk (MOC 2238)“, S.2-34/2-35.