Erweiterung des Distinguished Name für x509-Zertifikate

24.05.2021

Ich habe das Projekt zu Pflege und Management einer PKI aus beliebig vielen CAs erweitert.

Das Projekt wurde zunächst um einige kleinere Verbesserungen der Dokumentation erweitert - unter anderem betrifft das die explizite Anleitung zur Beantragung und Ausstellung von Zertifikaten für beliebig viele E-Mail-Adressen - zum Beispiel zur Verwendung von S/Mime zur vertraulichen EMail-Kommunikation:

Nutzt man diese Möglichkeit, benötigt man auch im Besitz mehrerer EMail-Adressen lediglich ein Zertifikat, da die EMail-Adressen - genau wie für Serverzertifikate, die für mehrere Hostnamen ausgestellt werden - einfach als Subject Alternative Names (SAN) angegeben werden können.

Funktional wurden die Skripte dahingehend erweitert, dass es möglich ist, die nutzerdefinierten OIDs nicht nur für custom Policies einzusetzen, sondern damit auch nutzerdefinierte Extensions und weitere Felder für den Distinguished Name (DN) zu definieren. Dazu werden bei der Erstellung einer Issuing CA entsprechende Konfigurationsdateien erstellt, die durch die End Entities zur Erzeugung des Zertifikatsrequests benutzt werden können. In diesen Dateien sind Platzhalter für sämtliche bei der Erstellung der CA definierten custom OIDs sowohl als Erweiterung des DN, als auch als custom Erweiterung enthalten. Vor Aktivierung der CA sind diese Platzhalter entsprechend zu aktivieren.

Entsprechende Platzhalter existieren ebenfalls in der Konfigurationsdatei für den Betrieb der CA - auch dort müssen die entsprechenden Änderungen - passend zu denen in den CSR-Konfigurationen - aktiviert werden. Ein entsprechender Abschnitt, der diese Änderungen demonstriert, wurde in die Dokumentation eingefügt.

Weiterhin wurde erste Tests zur Verwendung des Projektes für Cross-Zertifizierungen erfolgreich ausgeführt:

Erstellt man zwei PKI - je eine für Domain A und Domain B - wie hier dargestellt, so vertraut user1 einer EMail von user2 nicht, da dessen Zertifikat +ber keine von user1 als vertrauenswürdig eingestufte Wurzel verfügt.

Dieses Bild zeigt die Vertrauensketten, die user1 und user2 kennen - sie liegen jeweils in der eigenen Domain.

Beide könnten nun überein kommen, den Wurzelzertifikaten der jeweils anderen Domain das Vertrauen auszusprechen. Dann sind aber beide auf die Integrität und Vertrauenswürdigkeit der jeweils anderen Root CA angewiesen. Besser ist es, wenn dieses gegenseitige Vertrauen entkoppelt wird wie in der nächsten Abbildung dargestellt:

Dadurch, dass in Domain A eine CA eingerichtet wurde, die das Zertifikat der Identity CA B beglaubigt, entsteht eine Vertrauenskette, die user1 nutzen kann, um Zertifikate der Identity CA B zu prüfen - er muss dazu jetzt nicht mehr der Root CA (oder der Intermediary CA) der Domain B vertrauen. Außerdem kann ein Administrator auf einfache Art und Weise diese Kopplung wieder aufheben - er benötigt dazu nicht die Unterstützung der Administratoren aus Domain B - falls er den Verdacht hat, dass Domain B kompromittiert worden ist. Dazu muss er einfach das Zertifikat, das durch die Bridge cA für Identity CA B asusgestellt wurde widerrufen. Die untenstehende Abbildung zeigt die zwei bekannten Vertrauensketten und die durch die Bridge CA zusätzlich hinzugekommene:

Die Administration der Domain B kann sich entscheiden, dasselbe Vorgehen spiegelbildlich ebenfalls auszuführen - damit wird auch die Herkunft des Begriffes Cross Certification plausibel: Würde man diese zusätzliche Vertrauenskette ebenfalls noch in die Darstellung integrieren, würden sich die zwei kreuzen.

Artikel, die hierher verlinken

Was bedeutet das Vorhängeschloss im Browser?

12.11.2021

Ich habe immer wieder Anlauf genommen, mir das Folgende mal von der Seele zu schreiben und es immer wieder aufgeschoben - jetzt ist es aber soweit!

Datei verschlüsseln mit LUKS/dmcrypt

10.10.2021

Ich habe hier bereits öfter über die Einrichtung und Konfiguration von PKI bzw. CS gesprochen. Beides benötigt für die sensiblen Daten nicht wirklich viel Platz - allerdings wäre es schön, wenn diese Daten besonders geschützt wären...

Zertifikatsgültigkeit überwachen mit Grafana

04.10.2021

Ich habe ausprobiert, die verbleibende Lebenszeit von X.509-Zertifikaten per Telegraf, Influx und Grafana zu überwachen

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


Vor 5 Jahren hier im Blog

  • Virtuelles Netzwerklabor

    11.01.2017

    Nachdem ich hin und wieder vor der Herausforderung stehe, Anwendungen unter realen Netzwerkbedingungen zu testen, habe ich bereits vor längerer Zeit begonnen, ein virtuelles Netzwerklabor aufzubauen...

    Weiterlesen...

Neueste Artikel

  • Stratum-1-NTP-Server Links

    Ich habe meinen eigenen Stratum-1-NTP-Server mittels eines GPS-Empfängers, einer Adapterschaltung und einem Raspi gebaut. Hier fasse ich einige nützliche Links zu diesem Themengebiet zusammen

    Weiterlesen...
  • EBCMS threaded und mit mehr Markdown-Unterstützung

    Mein eigener Static Site Generator hat in den letzten Wochen einige größere Umbauten erfahren

    Weiterlesen...
  • Fork der BeanShell wegen Trojan Source

    Es gibt inzwischen einen von mir erstellten Fork des originalen Repository, in dem ich die Komponente zur Darstellung der Konsole gegen die ausgetauscht habe, die in der sQLshell in den Plugins MDIJavaEditor und MDISqlEditor zum Einsatz kommt - dadurch wird wenigstens durch das Syntax-Highlighting auf problematische Stellen im Code hingewiesen.

    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, muß 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 GitHub-Repositories findet man hier.