Teil 1: PKI und Zertifikate – ein paar Grundlagen
Teil 2: IP-Whitelist durch Client-Zertifikate ersetzen
Teil 3: Client Certificates Webapp

Eigentlich wollte ich ja einen anderen Artikel schreiben. Allerdings hielt ich es für angebracht, um Zuge dessen ein paar Grundlagen zum Thema Zertifikate und Public-Key-Infrastructure zu erläutern.
Also ich damit soweit durch war, musste ich allerdings feststellen, dass ich einen riesigen Textwust vor mir hatte, und das eigentliche Thema bislang kaum angerissen hatte.

Das verschreckt selbst den geduldigsten Leser!
Deswegen gibt es jetzt hier einen eigenen Beitrag.

Denn Zertifikate kennen die meisten nur daher, dass sie Webseiten mit https aufrufen, und mal gehört haben, dass da sowas zum Einsatz kommt.

Grundlagen – einfach erklärt (hoffentlich)

Definieren wir erst mal PKI (Public-Key-Infrastructure).
Im Detail kann man sich das natürlich auf Wikipedia durchlesen.

Aber grob gesagt, hat man dabei private und öffentliche Schlüssel (wie man das ggfs. schon von PGP her kennt) und die Zertifikate stellen die Integrität der Schlüssel sicher.
Der Rest ist dann „nur“ noch der „Infrastructure“-Teil – also wie man das verwaltet, verknüpft und verteilt. Aber dazu wird es noch einen eigenen Beitrag geben!
An dieser Stelle ist erst einmal das Zusammenspiel von Keys und Zertifikaten wichtig.

Fangen wir damit an, was ein Zertifikat an sich überhaupt ist. Wikipedia schreibt dazu sehr schön:

„Ein digitales Zertifikat ist ein digitaler Datensatz, […] der bestimmte Eigenschaften von Personen oder Objekten bestätigt und dessen Authentizität und Integrität durch kryptografische Verfahren geprüft werden kann.“

Damit sollte auch schon klar sein, dass ein Zertifikat zu mehr gut ist, als einem simplen Login.

Weiter steht dort:

„Die Ausstellung des Zertifikats erfolgt durch eine offizielle Zertifizierungsstelle, die Certification Authority (CA).“

Nun, ganz so „offiziell“ muss die CA nicht sein – aber dazu kommen wir gleich noch.
Der Punkt ist aber: das ganze ist keine einseitige Angelegenheit!

Der Benutzer kann nicht einfach hingehen, sich irgendwie ein Zertifikat zurecht zimmern, und dann sagen „Hier ist mein Zertifikat, ich will Zugriff!“
So funktioniert das nicht! Denn wir erinnern uns: „durch kryptografische Verfahren geprüft werden kann“.

Doch da wir ja – im Hinblick auf den anderen Artikel – so etwas selber aufsetzen wollen, immer der Reihe nach:

Certification Authority

Wir brauchen also erst mal eine CA. Dafür brauchen wir jetzt nicht zu irgendeiner der großen Firmen gehen und dort teuer Geld zu latzen. Das können wir auch einfach selber bauen!

Die Details beschreibe ich hier jetzt nicht, denn das haben andere schon getan: https://jamielinux.com/docs/openssl-certificate-authority/index.html

Grob ist die Vorgehensweise die folgende:

• Wir erzeugen einen AES-Key mit wenigstens 4096 Bit, der ein starkes Passwort bekommen sollte!
• Mit dem Key erzeugen wir ein Zertifikat vom Typ X509, mit einer langen Laufzeit (gängig sind so 20 Jahre)
• Dann erzeugen wir einen Key für das Intermediate-Zertifikat, der den selben Kriterien genügen sollte wie der Root-Key
• Damit erzeugen wir einen Certificate-Signing-Request (CSR) für ein Zertifikat mit geringerer Laufzeit (ca. 10 Jahre) – darauf kommen wir gleich noch zurück
• Mit dem Root-CA Zertifikat, signieren wir den Intermediate-CSR um ein Intermediate-Zertifikat zu erzeugen
• Mit dem Intermediate-Zertifikat können wir fortan die User-CSRs signieren.

OK, jetzt noch mal langsam!

Intermediate-Zertifikat? Wer? Wie? Wo? Was? Wann? …und manchmal auch: warum?

Das Root-Zertifikat der Certification Authority hat eine sehr lange Laufzeit. Und es gilt, in jedem Fall zu vermeiden, dass das kompromitiert wird!
Also wäre es am sinnvollsten, den Key und das Passwort dafür in einem Tresor weg zu sperren und niemals auf einem im Netz zugänglichen Rechner zu lagern!

Das Problem dabei ist: dann kann man ja keine Zertifikate mehr ausstellen! Doof.
Deswegen behelfen wir uns damit, dass wir ein Zwischen- bzw. Stellvertreter-Zertifikat erstellen, mit dem wir weitere Zertifikate ausstellen können.
Wenn das kompromitiert wird, können wir es immer noch zurück rufen, da es nicht das Ende der Hierarchie darstellt.

Und bevor sich jemand fragt „Kann ich dann mit meinem Zertifikat auch wiederum Sub-Zertifikate erstellen?“ – Nein, weil dein Zertifikat nicht die nötige Extension hat. (Siehe: verlinkter Guide)

…und zum Thema „Wie geht zurück rufen?“ kommen wir auch noch.

Und was war das mit diesem CSR?

Um das besser zu verstehen, rufen wir uns noch mal die Zitate von Wikipedia ins Gedächtnis:

„bestimmte Eigenschaften von Personen […] bestätigt“ sowie „Die Ausstellung des Zertifikats erfolgt durch eine […] Certification Authority“

Das persönliche Zertifikat eines Users, sollte ja ein paar Details über ihn enthalten (darum gehts ja!). Nur: woher soll die CA diese kennen?
Naja – tut sie nicht!
Also muss der User diese der CA mitteilen, und sagen „Hier! Mach mal ein Zertifikat daraus!“
Und damit haben wie die Funktion eines CSR eigentlich schon geklärt.

Das einzige, was es dann noch zu beachten gilt, ist, dass die Zertifikate ja nicht im luftleeren Raum existieren sondern die Integrität von Schlüsseln sichern sollen.
So einen Key braucht natürlich auch der User, damit nicht jeder Hinz und Kunz sein Zertifikat nutzen kann.

Vereinfacht gesagt muss der CSR also mit dem User-Key „signiert“ sein, damit das Zertifikat, dass die CA erstellt, an den Key gebunden ist, ohne dass die CA den Key kennen muss.

Rückrufaktion

Was machen wir jetzt, wenn ein Benutzer sein Zertifikat versehentlich auf github veröffentlicht hat, weil er die .gitignore nicht richtig angepasst hat?
Nun, dafür gibt es eine sogenannte „Certificate Revocation List“, kurz CRL.
Diese ist auch signiert und hat eine kurze Laufzeit/Gültigkeitsdauer von maximal 30 Tagen. Das hängt damit zusammen, weil diese Liste von einer öffentlichen URL abgerufen werden muss. Aber niemand schreibt dem Client oder Server, der die Zertifikate benutzt vor, wann oder wie oft er das machen muss.
Durch die kurze Laufzeit zwingt man die beteiligten Stellen dazu, wenigstens alle 30 Tage mal eine aktuelle Liste zu ziehen. Eine gewisse Verzögerung beim Rückruf ist damit natürlich unvermeidlich.

Und weil das von der CA signiert sein muss, kann der Benutzer selbst sein Zertifikat erst mal nicht zurück rufen. Sondern er muss das der CA mitteilen und machen lassen.
Je nach PKI kann es aber auch Mittel und Werkzeuge geben, mit denen sich das Semi-Automatieren lässt, sodass der Benutzer dass dann doch wieder selber anstoßen kann.

Aber die CRL funktioniert in beide Richtungen! Nicht nur kann der Server das Zertifikat des Client checken, umgekehrt geht das auch. Wenn bspw. – wie oben erwähnt – das Intermediate-Zertifikat kompromitiert wurde, kann man es mit dem Root-CA Zertifikat ebenfalls revoken.
Deswegen soll die CRL auch öffentlich abrufbar sein, damit der Client davon auch Gebraucht machen kann!

Im Prinzip ist das erst mal so das wichtigste was es zu wissen gibt. Auf die ganzen Details bin ich jetzt hier nicht eingegangen. Aber für Leute die mit dem Thema noch nie was zu tun hatten, ist das vermutlich auch erst mal genug für den Einstieg 😉