PKI beziehungsweise CA selber bauen

11.09.2016

Mein Vorschlag zur einfacheren, effizienteren Arbeit mit PKI

Nachdem ich das Tutorial für eine Simple, Advanced und Expert PKI sehr wertschätze und dort auch immer wieder neue Anregungen finde, habe ich bereits vor geraumer Zeit begonnen, meine eigene CA nach dem Vorbild der Expert PKI aufzubauen.

In meiner angestellten Tätigkeit betreut unser Unternehmen einen Kunden mit einer historisch gewachsenen PKI, die auch nicht aus diesem Unternehmen stammte, sondern von uns vom vorhergehenden Dienstleister übergeben wurde. Diese PKI wies im Laufe der Jahre einige Schwachstellen auf, die wir immer nach Entdecken überspielen konnten. Manchmal lernten wir auch einfach damit zu leben.

Diese PKI basiert ebenfalls auf OpenSSL. In dieser PKI existieren Shell-Skripte für die verschiedenen UseCases. Diese Skripte, beziehungsweise deren Auswurf auf dem Bildschirm sind sehr unübersichtlich. Dazu kommt, dass in manchen UseCases Passwörter mehrfach eingegeben werden müssen. Es ist nicht immer klar ersichtlich, welches Passwort benötigt wird, da lediglich die Serial Numbers angezeigt werden.

All dies führte dazu, dass die Administration - diejenigen also, die damit täglich zu tun haben - anfragte, ob man dieses Setup nicht dahingehend ändern könnte, dass zum Betrieb weniger Expertenwissen notwendig wäre.

Ich überlegte mir dazu folgendes: Wenn man die Komplexität der Interaktion mit OpenSSL vor dem Anwender verbergen könnte und gleichzeitig die wichtigen Informationen visuell strukturiert und aufbereitet darbieten könnte, wäre bereits viel gewonnnen. Wir überlegten zwar auch, die PKI evtl mit verfügbaren klicki-bunti-Angeboten umzusetzen, jedoch würde sich dies schwierig gestalten: Das Layout der PKI entspricht der Advanced PKI aus dem Tutorial.

Nach reiflicher Überlegung kam die Idee, expect und dialog zu kombinieren: Dialog ist ein Paket, mit dem sich Dialoge/Formulare aus Skripten heraus formulieren lassen und expect kann benutzt werden, Terminal-Anwendungen eine interaktive Shell vorzugaukeln. Man kann also mittels eines dialog-Formulars alle wichtigen Daten einsammeln und diese dann per expect an die OpenSSL-Anwendung verfüttern.

Es wurde auch überlegt, über die OpenSSL_Bibliothek, bzw. ihre Language Bindings entsprechende Programme zu schreiben (Python, ...?), jedoch hat die Lösung mittels dialog einen entscheidenen Vorteil (Meinung des Autors): Man kann detektieren, ob das Skript in einem tty oder einem pty unter X-Windows läuft und im zweiten Fall einfach statt dialog xdialog benutzen - damit erhält man statt der curses-Oberfläche (dialog) echte graphische Dialoge und muss die Skripts nicht anpassen.

Ein weiteres Argument wäre der Verzicht auf die Installation des entsprechenden Sprachinterpreters oder der benötigten Laufzeitumgebung - leder kann man aber dieses Argument nicht aufrechterhalten - expect benötigt TCL...

Artikel, die hierher verlinken

Expect-Dialog-CA OpenSource

15.07.2017

Nachdem ich bereits Ideen zur Umsetung einer zugänglicheren GUI für eine PKI bzw. CA in einer Terminalumgebung formuliert habe, habe ich diese Ideen jetzt umgesetzt und sie in ein Github-Repository zur Veröffentlichung hochgeladen. Der Code ist ausdrücklich nicht production-ready. Der aktuelle Stand demonstriert, welcher Komfort bei der Verwaltung einer CA mit vergleichsweise einfachen Mitteln in einer Terminalumgebung möglich ist.

Name Constraints in X509 Zertifikaten

17.10.2016

Ich wollte im Zuge der Untersuchungen zur Einrichtung einer CA/PKI die Auswirkungen von Name Constraints untersuchen - Hier die Ergebnisse:

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


Vor 5 Jahren hier im Blog

  • Fährnisse des Buildprozesses unter Windows

    17.07.2019

    Nachdem ich begonnen hatte, mich mit der Beschleunigung der Berechnung des Mandelbrot-Fraktals unter Zuhilfenahme der Shadereinheiten in Graphikkarten zu beschäftigen und erste Erfolge feiern konnte, wollte ich das mal auf einer richtigen Graphikkarte ausprobieren...

    Weiterlesen...

Neueste Artikel

  • Datenvalidierung UTF8 mit BiDi-Steuerzeichen (TrojanSource 2.0)

    Ich bin heute nochmal inspiriert worden, weiter über die Trojan Source Vulnerability nachzudenken. Meiner Meinung nach bestehen hier noch Probleme - speziell bei Nutzereingaben oder Daten, die über externe Schnittstellen ampfangen werden.

    Weiterlesen...
  • OpenStreetMap Navi als Docker-Container

    Ich habe die auf OpenStreetMap basierende OpenSource Navigationslösung Graphhopper in einen Docker-Container gepackt und als neuestes Mitglied in meinem Docker-Zoo willkommen geheißen.

    Weiterlesen...
  • SQL-Aggregatfunktionen in SQLite als BeanShell-Scripts

    Ich habe neulich über eine Möglichkeit berichtet, SQLite mittels der sQLshell und Beanshell-Skripten um SQL-Funktionen zu erweitern. In diesem Artikel versprach ich auch, über eine solche Möglichkeit für Aggregatfunktionen zu berichten.

    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 - meine öffentlichen GitLab-Repositories finden sich dagegen hier.