Anpassen der Expect-Dialog-CA

26.12.2019

Meine Variante einer Certificate Authority generiert bereits ein Setup für diverse CAs, das auch anspruchsvollen Szenarien genügen sollte.

Allerdings gibt es noch diverse Stellen, an denen man vielleicht Anpassungen vornehmen möchte und die nicht durch den Dialog-gestützten Erstellungsprozess adressiert werden.

Als erstes wären da die Policies zu nennen, die beim Setup der CAs eingerichtet werden und die dazu dienen sollen, Zertifikate nur für Distinguished Names zu erstellen, die bestimmten Regeln folgen. Während der Erstellung werden zwei Policies exemplarisch in die Konfigurationen aufgenommen: Eine namens match_O_pol kommt zur Anwendung, um nur Zertifikate auszustellen, deren Distinguished Name den gleiche organizationName enthält, wie der Distinguished Name der CA selbst - darüber hinaus fordert diese Policy, dass die Felder countryName und commonName nicht leer sein dürfen:

countryName             = supplied
stateOrProvinceName     = optional
localityName            = optional
organizationName        = match
organizationalUnitName  = optional
commonName              = supplied

Die zweite Policy stellt minimale Anforderungen: sie heißt minimal_pol und fordert lediglich, dass das Feld commonName nicht leer sein darf:

domainComponent         = optional
countryName             = optional
stateOrProvinceName     = optional
localityName            = optional
organizationName        = optional
organizationalUnitName  = optional
commonName              = supplied
emailAddress            = optional

Man kann nach diesem Muster weitre Policies definieren, diese vorgefertigten ändern oder gänzlich löschen - wichtig ist nur, dass es mindestens eine Policy gibt und der Name in der Konfiguration mit _pol endet.

Weiterhin kann man die Anforderungen an den Distinguished Name für den Anwender genauer definieren. Beispiele finden sich in den etc/ Verzeichnissen der issuing CAs. In diesen Konfigurationen, die zur Erzeugung entsprechender Certificate Signing Requests benutzt werden können kann man Vorgaben für die einzelnen Komponenten des Distinguished Name machen, in dem der CSR erzeugt wird.

In der neuesten Version des Projektes werden entsprechende Kommentare in diese Konfigurationen geschrieben, die man entsprechend aktivieren und modifizieren kann, um zum Beispiel den Vorgabewert, die dem Nutzer angezeigte Unterstützung und die minimale und maximale Länge für jede einzelne Komponente des DN vorzugeben. Für S\Mime CSRs sieht ein Ausschnitt im entsprechenden Abschnitt der Konfiguration zum Beispiel so aus:

[ smime_dn ]
countryName             = "1. Country Name (2 letters) (eg, US)       "
countryName_default = "DE"
#countryName_min         = 1
countryName_max         = 2

Und schließlich noch die Name Constraints - auch wenn sie im praktischen Betrieb .link x509nameconstraints.txt=noch keine wirklich großen Auswirkungen zeitigen möchte man sie vielleicht doch definieren. Das geschieht, indem man die entsprechende Extension beim Signieren eines CA-Zertifikats definiert. Einige Beispiele dafür sind hier aufgelistet. <pre> nameConstraints=permitted;email:.somedomain.com nameConstraints=excluded;email:.com

Weitere Informationen zu diesem Thema findet man in den unten aufgeführten Links.

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


Vor 5 Jahren hier im Blog

  • Derangement - theoretische Betrachtungen

    23.12.2020

    Ich habe bereits über meine Implementierung eines Derangement berichtet - hier noch einige theoretische Nachbetrachtungen...

    Weiterlesen

Neueste Artikel

  • Asymmetrische Kryptographie

    Ich habe mich mit der Idee schon länger getragen: Nochmal einen Rundumschlag zu asymmetrischer Kryptographie zu machen. Dabei werde ich mich auf Demonstrationen der einzelnen Konzepte und Operationen mit Beispielcode konzentrieren und zu jedem der vorgestellten Konzepte mehr oder weniger ausführlich bezüglich der Einsatzszenarien und Vor- und Nachteile Stellung beziehen

    Weiterlesen
  • Eingereichter Vortag zum 39C3 - Gentlemen - check your architecture!

    Dieser Vortrag wurde zum 39C3 eingereicht und abgelehnt. Ich möchte einige Open-Source-Frameworks für verschiedene Programmiersprachen vorstellen, mit denen sich Architekturregeln pro Projekt oder Organisation festlegen und mithilfe gängiger Testinfrastrukturen durchsetzen lassen.

    Weiterlesen
  • Chatkontrolle vermeiden ist gleichzeitig unwichtig und nicht genug!

    Das ist ein Abstract eines Vortrages, den ich auf dem 39C3 halten wurde, der aber abgelehnt wurde

    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.