Nochmal zu den Themen x509 und Zertifikate

vorhergehende Artikel in: PKI-X.509-CA Linux Security
19.04.2026

Eine Diskussion im $dayjob hat mich darauf aufmerksam gemacht, dass meine Präsentation zum Thema digitale und analoge Identitäten noch nicht alle Aspekte klar genug erläutert.

Unter anderem habe ich folgende Sachverhalte nachgeschärft:

  • was genau ist die Grundlage für Vertrauen?
  • was geschieht, wenn Zertifikate aus dem Truststore als Revoked markiert sind?
  • was geschieht beim Zurückziehen von Zertifikaten - speziell: Wie wird gehandhabt, wenn für dasselbe Schlüsselpaar verschiedene Zertifikate ausgestellt wurden?

Die Grundlage von Vertrauen

Man vertraut im Falle von self-signed oder Root-Zertifikaten nicht einem Zertifikat, sondern dem enthaltenen Schlüsselpaar. Diesen Sachverhalt muss man sich merken - sonst kommt einem die Tatsache, dass RFC5280 regelt, dass ein Root-Zertifikat, das im Truststore enthalten, jedoch abgelaufen ist immer noch einen gültigen TrustAnchor darstellt sehr seltsam vor. Ich möchte hier an die Analogie mit analogen Identitäten erinnern: Ein Ausweis enthält Informationen über Merkmale, die der zugehörigen Person unveränderlich zu Eigen sind und Attribute, die der Person lediglich von der auszustellenden Behörde zugeordnet sind.

In einem Beispiel wäre das das Foto in einer Führerscheinkopie, die ich einem Bekannten aushändige mit den Worten: "Wenn die hier abgebildete Person das KFZ führt, kannst Du ohne Bedenken in die Fahrgemeinschaft eintreten". Der Bekannte vertraut dann der Person, für die der Führerschein ausgestellt wurde - nicht dem Führerschein. Genauso funktionieren Truststores: wird dort ein Zertifikat importiert (die Führerscheinkopie), so wird dem Schlüsselpaar vertraut (dem Foto) - nicht dem Zertifikat slbst (dem Führerschein).

Zertifikate im Truststore werden zurückgezogen - was nun?

Daraus ergeben sich unmittelbar Fragen: Was, wenn das Zertifikat im Truststore abläuft? Das stellt kein Problem dar - die Zertifikatskette muss zu einem Trustanchor führen - das kann sie aber nur, wenn in der Zertifikatskette alle Zertifikate gültig und nicht abgelaufen sind. Das Analogon hier ist, dass beim Einsteigen in das Auto der Fahrgemeinschaft der Fahrer einen gültigen Führerschein vorweist. Dann vergleicht der Mitfahrer das Foto noch mit der vor einiger Zeit von mir übergebenen Kopie des inzwischen abgelaufenen Führerscheins und alles ist gut.

Ein weiteres interessantes Szenario ist ein aktiv zurückgezogenes Zertifikat. Handelt es sich dabei um eines im TrustStore, ist auch das kein Problem: Die Entspreching wäre hier, dass der Fahrer vor vielen Jahren Unfug gemacht und daher seinen Führerschein verloren hat. Zeigt er beim Einsteigen aber einen zu diesem Zeitpunkt gültigen, den er inzwischen erneut erworben hat, kann mein Bekannter wieder ohne sich Sorgen machen zu müssen in das KFZ einsteigen.

Zurückziehen eines Zertifikates, für dessen Schlüsselpaar noch weitere Zertifikate existieren

Zunächst noch eine Klarstellung: Zertifikate werden anhand ihrer Seriennummern in Certificate Revocation Lists (CRLs) und den Requests des OCSP-Protokolls identifiziert. Damit ist es also tatsächlich möglich, von mehreren Zertifikaten, die für dasselbe Schlüsselpaar ausgestellt wurden gezielt nur eines zurückzuziehen.

Die Antwort der Frage, was geschieht wenn ein Zertifikat zurückgezogen wird, für dessen Schlüsselpaar weitere gültige existieren, hängt jetzt ganz von der internen Struktur und den in den Certificate Practise Statements festgelegten Grundsätzen der jeweiligen CA ab. Da wären zum Beispiel solche Entscheidungen wie

  • Zu ein und demselben Zeitpunkt existiert nur ein gültiges Zertifikat für ein Schlüsselpaar (und eine key usage)
  • Ein Zertifikat wird immer nur für genau eine key usage ausgestellt
  • Eine Sub-CA existiert für jede unterstützte Key usage
  • ...
Generell ist es aber möglich - und es existiert keine technische Beschränkung, die das verhindern würde, dass für ein Schlüsselpaar zu einem gegebenen Zeitpunkt mehrere gültige Zertifikate existieren (zum Beispiel mit jeweils unterschiedlichen key usages). Dann ist es auch durchaus möglich, dass einzelne Zertifikate ungültig gemacht werden und andere - für dasselbe Schlüsselpaar ausgestellte - weiterhin gültig bleiben. Eine CA kann aber entscheiden, dass sie - wenn sie zur Revocation aufgefordert wird - nicht nur das im Auftrag genannte Zertifikat für ungültig erklärt, sondern eben alle anderen von ihr für dieses Schlüsselpaar ausgestellten das gleiche Schicksal ereilt. Auch das ist ganz klar ein Fall für Regelungen im Certificate Practise Statement. Es gibt keine objektiven Fakten oder technischen Einschränkungen, die das eine oder andere Verhalten verbieten bzw. bevorzugen.

Artikel, die hierher verlinken

Absichern von Truststores und Keystores

17.05.2026

Hin und wieder erlebe ich es persönlich oder lese davon, dass jemand die Frage stellt, wie kryptographische Geheimnisse gesichert werden können. Ich gebe hier mal einen Anstoß, darüber aus der Sicht der Software-Architektur auf Systemebene nachzudenken...

Alle Artikel rss Wochenübersicht Monatsübersicht Codeberg Repositories Mastodon Über mich home xmpp


Vor 5 Jahren hier im Blog

  • Styles für GeoJSON in EBMap4D

    22.08.2021

    Ich habe bereits darüber berichtet, dass EBMap4D jetzt über die Möglichkeit verfügt, beliebige GeoJSON-Layer darzustellen. Nun ist die Anwendung um die Möglichkeit erweitert worden, in diesen GeoJSON-Daten enthaltene Stilinformationen für die Darstellung zu nutzen.

    Weiterlesen

Neueste Artikel

  • Linux-System SBOM visualisiert als Graph - für YUM!

    Ich schrieb vor einiger Zeit über die Visualisierung und Analyse von Abhängigkeiten in Linux-Distributionen, die auf Debian aufbauen. Damals habe ich noch behauptet, dass andere Distributionen, die zum Beispiel auf yum als Paketmanagement-Lösung setzen nur schwer in dieser Art und Weise analysierbar sind. Ich habe weiter recherchiert und nun auch dafür eine Lösung gefunden.

    Weiterlesen
  • 35 Jahre Antipatterns in Datenmodellen

    Ich habe inzwischen 35 Jahre Softwareentwicklung auf dem Buckel - viele davon für Geld...

    Weiterlesen
  • Highlights der DefCon 34

    Hier meine Highlights der DefCon 34 in Las Vegas

    Weiterlesen

Manche nennen es Blog, manche Web-Seite - ich schreibe hier hin und wieder über meine Erlebnisse, Rückschläge und Erleuchtungen bei meinen Hobbies.

Wer daran teilhaben und eventuell sogar davon profitieren möchte, muss damit leben, daß ich hin und wieder kleine Ausflüge in Bereiche mache, die nichts mit IT, Administration oder Softwareentwicklung zu tun haben.

Ich wünsche allen Lesern viel Spaß und hin und wieder einen kleinen AHA!-Effekt...

PS: Meine öffentlichen Codeberg-Repositories findet man hier.