In den nächsten Tagen werde ich eine kleine Artikelserie starten, in der es um das Erstellen von Schlüsseln und Zertifikaten mit einer 2-stufigen Zertifizierungsstelle (Certification Authority, CA) mittels OpenSSL geht.
Heute schon einmal kurz vorweg: Warum macht man so etwas selbst? Kann man da nicht auch was kaufen? Es gibt doch auch Let's encrypt - das ist doch auch kostenlos.
Wo macht es wenig Sinn?
Bei öffentlichen Web-Servern macht man "HTTPS", zum einen um den Netzwerkverkehr verschlüsseln, und zum anderen, um sich glaubwürdig auszuweisen. So kann der Benutzer einer Webseite darauf vertrauen, dass der Webserver auch wirklich derjenige ist, der er behauptet zu sein.
Dafür braucht man dann ein Zertifikat von einer Zertifizierungsstelle (CA), die in den Browsern dieser Welt schon hinterlegt sind. Der Browser vertraut der CA - sozusagen dem Passamt - und wenn der Server dem Browser ein Zertifikat vorlegt, dass einen Stempel von so einem vertrauenswürdigen Passamt vorweisen kann, glaubt der Browser auch dem Server. Um diesen "Stempel", also das Zertifikat von der CA zu bekommen, muss man irgendwie nachweisen, wer man ist und dass man dazu berechtigt ist, für diesen Server ein Zertifikat zu bekommen. Es gibt dafür verschiedene Stufen und Nachweismethoden.
In diesem Fall ergibt es wenig Sinn, sich das Zertifikat selbst auszustellen - genauso wenig wie mit einem selbstgemachten Ausweis bei der Flughafenkontrolle...
Hier kann man entweder ein Zertifikat von einer etablierten CA kaufen oder sich mit Let's encrypt beschäftigen und damit die Zertifikate erstellen und verlängern.
Wann und wo macht es Sinn?
Innerhalb eines Unternehmens ist das aber vielleicht schon wieder anders: Zum einen geht es in vielen Fällen nur um die Verschlüsselung, damit z. B. Passworte nicht im Klartext über das interne Netzwerk geschickt werden. Zum anderen kann man in einer kontrollierten Umgebung auch eine selbsterstellte CA so installieren oder hinterlegen, dass innerhalb des Unternehmens die Browser den Zertifikaten vertrauen. - so wie bei Firmenausweisen bei der Zutrittskontrolle beim Pförtner. Außerhalb der Firma hat dieser Firmenausweis nicht viel Beweiskraft, aber innerhalb dient er zur Authentifizierung.
Wir werden in den nächsten Artikeln genauso einen Firmenausweis erstellen, nur rein elektronisch, basierend auf starker Kryptografie.
Let's encrypt funktioniert hier nicht (so einfach), weil von außen auf den jeweiligen Server zugegriffen werden können muss. Das geht wunderbar mit öffentlichen Web-Servern, aber nicht mehr so gut mit internen, und gar nicht mehr, wenn es nicht um andere Protokolle als HTTPS geht.
Mehrstufig?!
Um die Zertifikatserstellung delegieren zu können und genauer festzulegen, wer welche Art von Zertifikaten für welche Aufgaben oder Unternehmensteile erzeugen darf, hat sich eine (mindestens) zweistufige Architektur bewährt.
So hat man eine gemeinsame Basis, die Wurzel, aus der alles heraus entsteht. Im Umfeld von Zertifikaten spricht man dementsprechend auch von der "Root-CA". Davon gibt es im Unternehmen typischerweise nur genau eine.
Dann erstellt man für die Organisationseinheiten oder Einsatzzwecke weitere Zertifikate, die mit der Root-CA "gestempelt" werden, von ihr zertifiziert werden. Man spricht hier von Intermediate-CAs. Einsatzzwecke könnten z. B. Web-, SMTP-. LDAP-, POP3, IMAP-, VPN-Server-, Client- oder S/MIME-Zertifikate sein. Organisationseinheiten wären dann Landesgesellschaften, Standorte o.ä.
Wenn man nicht alles mit einer CA macht, sondern mit mehreren "Spezialisten", kann man die Intermediate-CAs an unterschiedliche Teams bzw. Verantwortliche geben, die dann eben nur Zertifikate für ihren Bereich erstellen können. Weil es so sicherer ist.
Und jetzt praktisch...
Ich werde nicht nur zeigen, wie man die CAs, Schlüssel und Zertifikate erstellt, sondern auch wie man sie in den Browsern installiert, wie man einem Domino-Server so ein Zertifikat schmackhaft macht, wie man sie in Java Keystores importiert, in den Sametime Proxy Server, in VMware ESXi-Server, in eine pfSense-Appliance, ...
