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

  • Certstream, InfluxDB, Grafana und Netflix

    16.04.2019

    Nachdem ich vor kurzem über mein erstes Spielen mit dem certstream berichtete, habe ich weitere Experimente gemacht und die Daten zur besseren Auswertung in eine InfluxDB gepackt, um sie mit Grafana untersuchen zu können.

    Weiterlesen...

Neueste Artikel

  • Die sQLshell ist nun cloudnative!

    Die sQLshell hat eine weitere Integration erfahren - obwohl ich eigentlich selber nicht viel dazu tun musste: Es existiert ein Projekt/Produkt namens steampipe, dessen Slogan ist select * from cloud; - Im Prinzip eine Wrapperschicht um diverse (laut Eigenwerbung mehr als 140) (cloud) data sources.

    Weiterlesen...
  • LinkCollections 2024 III

    Nach der letzten losen Zusammenstellung (für mich) interessanter Links aus den Tiefen des Internet von 2024 folgt hier gleich die nächste:

    Weiterlesen...
  • Funktionen mit mehreren Rückgabewerten in Java

    Da ich seit nunmehr einem Jahr bei meinem neeun Arbeitgeber beschäftigt und damit seit ungefähr derselben Zeit für Geld mit Python arbeite, haben sich gewisse Antipathien gegenüber Python vertieft (ich kann mit typlosen Sprachen einfach nicht umgehen) - aber auch einige meiner Gründe, Python zu lieben sind ebenso stärker geworden. Einer davon ist der Fakt, dass eine Methode in Python mehr als einen Wert zurückgeben kann.

    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.