TinyCA als Zertifizierungsstelle für kleine Ansprüche

Kontrollstelle

Wer zur Authentifizierung von Benutzern oder Diensten Zertifikate verwenden will, braucht eine Zertifizierungsstelle. Eine solche Certification Authority (CA) lässt sich mit dem grafischen Tool TinyCA leicht einrichten.

Wenn die Ansprüche an die Infrastruktur für die Authentifizierung von Benutzern, Rechnern oder Diensten größer werden, stößt das übliche Benutzername/Password-Schema schnell an seine Grenzen. Die Standardlösung für dieses Problem heißt: Zertifikate. Dieser Artikel beschreibt den Aufbau einer eigenen Zertifizierungsstelle und stellt das Werkzeug TinyCA vor, das zumindest bescheidenen Ansprüchen genügt.

Wozu braucht man eine Zertifizierungsstelle?

Das das übliche Schema zur Authentifizierung durch Benutzername und Passwort skaliert nicht besonders gut. Sobald es etwas mehr Benutzer werden, hat der Administrator alle Hände voll zu tun, die Passwortdateien für alle Hosts und Dienste anzupassen. Die Alternative dazu ist, dass jeder Benutzer sich mit einem so genannten Zertifikat ausweist und jeder Rechner beziehungsweise Dienst diesem Ausweis vertraut.

Für einen solchen Ausweis benötigt der Benutzer (oder auch ein Rechner, der sich ausweisen will) ein Paar aus öffentlichem und privatem Schlüssel. Da nur der Benutzer den privaten Teil kennt, ist sichergestellt, dass nur er Zugang zum Server bekommt, die verschlüsselten Daten lesen kann und so fort.

Aus dem öffentlichen Schlüssel wird ein Zertifikat, zu ihm noch persönliche Informationen kommen, die ihn personalisieren, und eine zentrale Vertrauensinstanz ihn durch ihre Signatur bestätigt hat. Damit bestätigt sie, dass der Besitzer des Zertifikats tatsächlich der ist, für den er sich ausgibt. Deshalb ist es für die Zentralinstanz wichtig, die Authentizität des Benutzers vor der Ausgabe des Zertifikats zu überprüfen.

Glossar

Certificate Authority (CA): Zentrale Authentifizierungsinstanz. Request: Öffentlicher Teil des Benutzerschlüssels, nach Standard (X.509, …) kodiert Zertifikat: Öffentlicher Schlüssel eines Benutzers, signiert durch die CA, kodiert im Standardformat.

Da jedes Zertifikat, das von der CA signiert wurde, bis zu seinem Ablaufdatum gültig ist, muss es auch einen Mechanismus geben, Zertifikate zwischendurch zu widerrufen. Das kann der Fall sein, wenn das Zertifikat zum Beispiele verloren wurde. In diesem Fall markiert die CA das Zertifikat als ungültig und exportiert diese Liste in die so genannte Certificate Revocation List (CRL). Dem Administrator bleibt es vorbehalten, diese CRL auf alle Server zu verteilen, um so unerlaubten Zugang zu verhindern.

Benutzer können sich mit dem Zertifikat gegenüber einem Server ausweisen und dieser muss nur noch prüfen, ob das Zertifikat ordnungsgemäß von einer CA, der er vertraut, unterschrieben wurde. Dann erhält der Benutzer Zugang zu den angebotenen Diensten. Vorteil für den Administrator ist, dass der Server nur noch das Zertifikat der CA selbst kennen muss. Es müssen keine tausende von Benutzerkonten angelegt werden.

TinyCA

Der Standard für die Erstellung von Zertifikaten in der offenen Welt ist OpenSSL; ein Kommandozeilenwerkzeug, das zwar alles notwendige kann, aber für Anfänger nicht unbedingt leicht zu bedienen ist. Alternativ bringen Distributionen und Programme eigene Scriptsammlungen mit, die dem Administrator dabei helfen, Zertifikate zu erstellen. Diese Werkzeuge sind immer genau für den Zweck angepasst, erstellen zum Beispiel genau ein Zertifikat für einen Mail- oder Webserver. Universell sind sie meist nicht einsetzbar. Gute CAs bringen meist nur die Enterpriseversionen (RHEL, SLES, …) mit.

Für den Hausgebrauch bei nicht allzu großen Anforderungen hat sich daneben im Einsatz auch das Programm TinyCA2 (inzwischen in der Version …) bewährt. Es bietet eine Gtk-GUI, die es einem Administrator erlaubt, eine (oder mehrere) CA lokal auf seinem Rechner zu verwalten, Anforderungen selbst zu erstellen oder zu importieren und für beliebige Zwecke zu signieren, also Zertifikate zu erstellen. TinyCA2 ist sicher auch eine Alternative, wenn ein Administrator den Aufwand für eine komplette Installation von OpenCA scheut.

comments powered by Disqus

Artikel der Woche

Setup eines Kubernetes-Clusters mit Kops

Vor allem für Testinstallationen von Kubernetes gibt es einige Lösungen wie Kubeadm und Minikube. Für das Setup eines Kubernetes-Clusters in Cloud-Umgebungen hat sich Kops als Mittel der Wahl bewährt. Wir beschreiben seine Fähigkeiten und geben eine Anleitung für den praktischen Einsatz. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Container

Wie setzen Sie Container ein?

  • Gar nicht
  • Docker standalone
  • Docker mit Kubernetes
  • Docker mit Swarm
  • Docker mit anderem Management
  • LXC/LXD
  • Rocket
  • CRI-O auf Kubernetes
  • Container auf vSphere
  • Andere (siehe Kommentare auf der Ergebnisseite)

Google+

Ausgabe /2018

Microsite