Im ersten Teil dieser Artikelserie bin ich zunächst auf die Grundlagen von Verschlüsselung und Authentifizierung via Transport Layer Security (TLS) eingegangen, bevor im zweiten Teil Certificate Signing Requests (CSR) erstellt und durch die eigene Certificate Authority (CA) in Zertifikate überführt wurden.

Im diesem, letzten Teil geht es um die Installation des Stammzertifikats der CA in diversen Clients, sowie die Verwendung der Server-Zertifikate unter Apache HTTPd, lighttpd und nginx.

Verwendung der Zertifikate

Die Absicherung eines Dienstes bedingt im Allgemeinen die Bereitstellung des Server- bzw. Dienst-Zertifikates, des zugehörigen privaten Schlüssels und des CA-Stammzertifikats. Kommt keine eigene CA zum Einsatz, sondern wurden die Dienste eines kommerziellen Anbieters genutzt, so müssen bei Bedarf deren Zertifikate bereitgestellt werden, sofern sie nicht Teil der Standard-Installation moderner Browser sind.

Ziel ist in jedem Fall, daß ein Client (der Browser) die Kette vom Server-Zertifikat bis zu einem vertrauenswürdigen Zertifikat einer Certificate Authority schliessen kann.

Installation eines Server-Zertifikats

In zweiten Teil wurden für einen fiktiven Beispiel-Server example.dahlen.org die folgenden Dateien erzeugt, welche jetzt zum Einsatz kommen:

• ca.crt: das Stammzertifikat der eigenen CA
• server.crt: das Zertifikat des Servers
• server.key: der private Schlüssel zum Zertifikat des Servers

Die tatsächliche Einbindung ist spezifisch für die jeweilige Server-Software. Dabei können einige Dienste (z.B. Apache HTTPd) die Dateien einzeln ansprechen, während andere (z.B. nginx) zusammengefasste Dateien (bundle) erwarten. Dabei ist teilweise sogar die Reihenfolge der Zertifikate im bundle von Bedeutung.

Ein Hinweis an dieser Stelle: Die beschriebenen Konfigurationen beschränken sich auf das Einbinden der Dateien, so daß die jeweilige Server-Software startet und verschlüsselte Kommunikation erlaubt. Für die optimale Absicherung sind weitere Aktionen notwendig, wie das Aktivieren empfohlener und das De-Aktivieren veralteter Protokolle.

Eine gute Anlaufstelle hierfür ist – neben der Dokumentation zur Software – die Webseite bettercrypto.org bzw. die dort angebotene Dokumentation Applied Crypto Hardening.

Apache

Der Apache HTTP Server kann obige Dateien getrennt ansprechen. Ihre Pfade werden in der Konfiguration des virtuellen Hosts eingetragen, der später über https ansprechbar sein soll. Vorher müssen die Dateien noch an die passende Stelle kopiert werden, z.B. /etc/apache2:


<VirtualHost *:443>
 ServerName example.dahlen.org
 DocumentRoot /var/www/html/
 SSLEngine on
 SSLCertificateFile /etc/apache2/server.crt
 SSLCertificateKeyFile /etc/apache2/server.key
 SSLCACertificateFile /etc/apache2/ca.crt
</VirtualHost>


Eine tiefergehende Einführung mit allen Optionen findet sich in der Dokumentation zum Apache HTTP Server. Nochmal der Hinweis: Der Common Name (CN) im Zertifikat muß der Domäne entsprechen, unter welcher die Website angeboten wird.

nginx

nginx benötigt das Server-Zertifikat und das Stammzertifikat der CA in einer Datei. Diese wird zunächst als bundle.crt angelegt:

cat server.crt ca.crt > bundle.crt

Anschließend werden das bundle und der private Schlüssel des Server-Zertifikats in der Konfiguration von nginx (z.B. als virtueller Host) angesprochen:

server {
 listen 443;
 server_name example.dahlen.org;
 ssl on;
 ssl_certificate bundle.crt;
 ssl_certificate_key server.key;
}


Weitere Details, inbesondere zu den Einstellungen unterstützer Protokolle finden sich in der Dokumentation von nginx.

lighttpd

Eine Anleitung für lighttpd habe ich bereits im 1. Teil des oben erwähnten Posts gegeben. Achtung: Für die Beispiele dort wurden ein anderer Hostname (owncloud.dahlen.org) und andere Dateien (in der Regel mit Dateiendung .pem statt .crt) verwendet.

Installation des CA-Zertifikats

Damit auch der Browser die neu geschaffene Certificate Authority bzw. die von ihr beglaubigten Zertifikate als vertrauenswürdig akzeptiert, ist noch die Installation des CA-Zertifikats im jeweiligen Zertifikat-Speicher notwendig. Dieser Schritt entfällt, wenn auf die Zertifizierung durch eine akkreditierte CA zurückgegriffen wurde.

Windows 7 & 8

Unter Windows 7 und 8(.1) reicht ein Doppelklick auf das CA-Zertifikat ca.crt. Im anschließenden Dialog wählt man Zertifikat installieren, um den entsprechenden Assistenten zu starten.

Wichtig ist der 2. Schritt des Assistenten, im welchem der Zertifikat-Speicher ausgewählt wird. Statt der Vorgabe der automatischen Auswahl ist der Speicher selbst auszuwählen. Er wird bei einem deutschen Windows als Vertrauenswürdige Stamm­zertifizierungs­stellen genannt (siehe Screenshot).

Mozilla Firefox / Thunderbird

Beide Programme verwalten ihre Zertifikate selbst. Die Installation des ca.crt geschieht über den Menüpfad Einstellungen > Erweitert > Zertifikate. Dort ist Zertifikate anzeigen auszuwählen und im daraus resultierenden Fenster der Reiter Zertifizierungsstellen. Der Button Importieren … schließlich öffnet einen Dialog, in welchem ca.crt ausgewählt werden kann.

iPhone / iOS

Die Installation auf einem iOS-Gerät (hier getestet iPhone 5 mit iOS 8.1.3) ist erstaunlich unkompliziert. Einfach die Datei ca.crt als E-Mail-Anhang versenden, auf dem Mobiltelefon auswählen und installieren.

Android

Android ist der Grund, warum ich noch auf die Dienste von Anbietern wie StartSSL zurückgreifen muß. Offenbar ist es auf einem Android-Gerät ohne root-Zugang (hier: Nexus 7 2012, Stock Android 5.0.2) nicht möglich ein CA-Zertifikat systemweit zu installieren.

Insofern liefern die Browser, aber auch diverse Apps, welche auf meine Server-Dienste zugreifen eine entsprechende Warnung. Schlimmer noch: Unmittelbar nach der (unwirksamen) Installation als Benutzer-Zertifikat erscheint in der Mitteilungszentrale Das Netzwerk wird möglicherweise überwacht.

Wer für dieses Problem eine Lösung anbieten kann, dem sei die Kommentarfunktion unterhalb dieses Artikels empfohlen.

Fazit

Am Ende dieser Artikelserie ergibt sich für mich ein zwiespältiges Bild: Die Einrichtung verschlüsselter Verbindungen für eigene Dienste ist in wenigen Minuten durchführbar. Eine eigene Certificate Authority reduziert Aufwand und Kosten und steht technisch gesehen einer externen, oftmals kommerziellen CA in nichts nach.

Dennoch hat der Einsatz nur in kontrollierten Umgebungen Sinn. Das Problem liegt weniger auf der Server-Seite, sondern an der Notwendigkeit die eigene CA allen Clients bekannt zu machen. Unbedarfte Besucher dürften bei einer oftmals plakativen Warnung des Browsers (Dieser Verbindung wird nicht vertraut) entweder kehrt machen oder die Warnung ignorieren. Beides ist sicherlich nicht im Sinne des Erfinders.

Am Einsatz einer kommerziellen CA führt aktuell daher kaum ein Weg vorbei. Die wenigen kostenlosen oder günstigen Angebote (lt; 200 EUR) bestätigen dabei nicht mehr als die Verwendung einer gültigen E-Mail-Adresse und einen korrekten DNS-Eintrag. Sie sind allerdings für Privatpersonen oder kleinere Unternehmen ausreichend. Mit der Let’s Encrypt-Initiative der Internet Security Research Group (Mozilla und andere) soll Mitte 2015 eine interessante Alternative zu etablierten CAs den Markt betreteten.

Organisationen, welche auf hohe Glaubwürdigkeit angewiesen sind (z.B. beim Online-Banking) haben hingegen keine Wahl. Für EV-Zertifkate mit grüner Namenserwähnung in der Browser-Zeile sind üblicherweise über 1.000 EUR zu bezahlen – pro Jahr.

Der Beitrag Kostenlose TLS/SSL-Zertifikate durch eigene CA erstellen (Teil 3: Verwendung) erschien zuerst auf dahlen.org.

In diesem zweiten, technischen Teil beschreibe ich den Weg von der Erstellung eines privaten Schlüssels zum Server-Zertifikat für Apache, lighttpd und andere Server-Dienste. Dazu kommen die unter vielen Plattformen verfügbaren OpenSSL-Werkzeuge in Verbindung mit einer (eigenen) Certificate Authority (CA) zum Einsatz.

Erstellung und Installation

Für die Durchführung der folgenden Anleitung wird eine aktuelle Installation des OpenSSL-Paketes für das eigene Betriebssystem benötigt, die Version sollte dabei mindestens 1.0.1g (siehe Heartbleed Bug) sein. Für dieses Protokoll wurde Version 1.0.1k unter Cygwin64 für Windows verwendet.

Unter Debian-basierten Linux-Systemen sind die Pakete openssl und ca-certificates zu installieren:
sudo apt-get install openssl ca-certificates

Vorbereiten des Server-Zertifikats

Der Weg zum Server-Zertifikat für den Betrieb einer mit TLS/SSL abgesicherten Website beginnt stets mit der Erstellung eines privaten Schlüssels. Aus diesem wird später der öffentliche Schlüssel abgeleitet und mit weiteren Informationen, besonders dem Domänennamen (im Feld Common Name CN) in einem sog. Certificate Signing Request (CSR) gespeichert. Anschließend bestätigt eine Certificate Authority (CA) mit ihrer Signatur die Echtheit des öffentlichen Schlüssels und stellt darüber ein Zertifikat aus.

Privater Schlüssel

Der folgende Befehl erstellt einen privaten Schlüssel von 4096 Bytes Länge:

openssl genrsa -out server.key 4096

Zu den Parametern:

genrsa

Erstellung eines privaten Schlüssels nach RSA-Verfahren

-out server.key

Speichern des privaten Schlüssels in der Datei server.key

4096

die Schlüssellänge in Bytes. Werte unter 2048 sollten nicht mehr verwendet werden, 4096 ist auf absehbare Zeit nicht mit vertretbarem Aufwand zu knacken

Damit die später eingesetzte Server-Software (z.B. Apache HTTPd) den privaten Schlüssel ohne weiteres Zutun lesen kann, ist dieser nicht über eine zusätzliche, symmetrische Verschlüsselung gesichert. Er muß an einem sicheren Ort mit genau definierten Zugriffsrechten aufbewahrt werden.

Certificate Signing Request

Aus dem gerade generierten privaten Schlüssel server.key erzeugen wir nun einen CSR. Dieser wird später bei der (eigenen) CA zur Beglaubigung eingereicht:

openssl req -new -key server.key -out server.csr

Beschreibung der Parameter:

req

Erstellung eines Certificate Signing Request

-new

einen neuen CSR erstellen, daher Eigenschaften zum Schlüsselinhaber anfragen

-key server.key

Pfad zur privaten Schlüsseldatei, aus welcher der öffentliche Schlüssel für diesen CSR abgeleitet werden soll

-out server.csr

Speichern des CSRs in der Datei server.csr

Der Aufruf des Befehls stösst einen Dialog an, in welchem Angaben zum Inhaber des privaten Schlüssels angefordert werden. Wichtig dabei: Auf die Frage nach dem Common Name (CN) muß der Fully Qualified Domain Name (FQDN) des Servers bzw. des Services (z.B. des Virtual Hosts) angegeben werden. Beispielhaft sei hier example.dahlen.org verwendet. Das angefragte Challenge Passwort wird nicht gesetzt, die entsprechende Rückfrage also einfach per Enter bestätigt:


You are about to be asked to enter information that will
be incorporated into your certificate request.
What you are about to enter is what is called a Distinguished
Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:DE
State or Province Name (full name) [Some-State]:Nordrhein-Westfalen
Locality Name (eg, city) []:
Organization Name (eg, company) [Internet Widgits Pty Ltd]:dahlen.org
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []:example.dahlen.org
Email Address []:
 
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:


Vorbereiten der Certificate Authority

Ein Certificate Signing Request für den Server oder Service liegt nun in der Datei server.csr vor. Er enthält neben dem öffentlichen Schlüssel (welcher aus dem privaten Schlüssel server.key abgeleitet wurde) Details zum Inhaber des Schlüsselpaares.

Um aus dem CSR nun ein Zertifikat zu erzeugen, ist die Beglaubigung durch eine Certificate Authority notwendig. Dies kann entweder ein kommerzieller Anbieter (wie StartSSL, optional mit kostenlosen Angeboten) oder eine eigene CA sei. Bzgl. der Verwendung von StartSSL sei erneut auf die Anleitung bei heise Security hingewiesen.

Eine eigene CA ist ein günstige Variante um beliebig viele Server oder Dienste mit Zertifikaten zu versehen. Clients, welche das Stammzertifikate der CA installiert haben und es als vertrauenswürdig betrachten, akzeptieren später Zertifikate, welche durch Unterschrift der eigenen CA erstellt wurden.

Privater Schlüssel

Auch eine eigene Certificate Authority benötigt zunächst einen privaten Schlüssel. Aus diesem wird später das selbst-signierte Stammzertifikat (CA ROOT) erzeugt. Der Befehlsaufruf ist nahezu identisch zur obigen Variante für das Server-Zertifikat:

openssl genrsa -aes256 -out ca.key 4096

Die Parameter sind weitestgehend bekannt, daher hier nur die Abweichung:

-aes256

der private Schlüssel wird beim Speichern mit einer symmetrischen Verschlüsselung nach AES versehen.

Früher gebräuchliche Verfahren wie DES oder 3DES sollten nicht mehr angewendet werden. Das für die Verschlüsselung notwendige Kennwort (oder besser – die Passphrase) wird im Rahmen des Befehlsablaufs angefragt:


Generating RSA private key, 4096 bit long modulus
.............++
.........++
e is 65537 (0x10001)
Enter pass phrase for ca.key:
Verifying - Enter pass phrase for ca.key:


Als Ergebnis liegt nun der private Schlüssel der CA in der Datei ca.key vor.

Stammzertifikat

Als nächstes wird ein temporärer Zertifikatsantrag (Certificate Signing Request, CSR) für die eigene CA erzeugt und durch Eigenbeglaubigung in Form eines X.509 Zertifikates im Dateisystem abgelegt:

openssl req -x509 -new -extensions v3_ca -key ca.key -days 1461 \
-out ca.crt -sha512

Auf hier sind viele Parameter schon im Bereich des Server-CSRs aufgeführt. Daher nur die Ergänzungen bzw. Abweichungen:

-x509

bewirkt, daß der erzeugte CSR unmittelbar in ein Zertifikat überführt wird, es wird also keine .csr-Datei angelegt

-extensions v3_ca

aktiviert Erweiterungen im erzeugten Zertifikat, die für den Betrieb einer CA notwendig sind

-days 1461

bestimmt die Gültigkeit des Zertifikats, 1461 sollten 4 Jahre (inkl. Schaltjahr sein)

-sha512

bestimmt das Verfahren, mit welchem die Signatur des Zertifikates gebildet wird.

Für die Signatur sollte mindestens SHA2 (-sha256) zum Einsatz kommen. SHA1 oder MD5 sind veraltet und gelten als unsicher. Viele Browser werden in absehbarer Zukunft vor so signierten Zertifikaten warnen (siehe Ankündigung von Google).

Im Rahmen der Befehlsausführung wird zunächst die oben definierte Passphrase des privaten CA-Schlüssels angefordert. Anschliessend sind einzelne Felder des Zertifikates mit Angaben zur eigenen CA zu füllen. Letztendlich kann man hier beliebige Werte eingeben, besser sind jedoch tatsächliche Angaben und eine gültige E-Mail-Adresse, damit Interessierte später mit Details zu eurer eigenen CA versorgt werden.


Enter pass phrase for ca.key:
You are about to be asked to enter information that will
be incorporated
into your certificate request.
What you are about to enter is what is called a
Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:DE
State or Province Name (full name) [Some-State]:Nordrhein-Westfalen
Locality Name (eg, city) []:
Organization Name (eg, company) [Internet Widgits Pty Ltd]:dahlen.org
Organizational Unit Name (eg, section) []:Certificate Authority
Common Name (e.g. server FQDN or YOUR name) []:
Email Address []: certificates@dahlen.org


Zertifizierung durch die CA

Als Ergebnis liegt das Zertifikat zum privaten CA-Schlüssel ca.key in der Datei ca.crt vor und die eigene Zertifizierungsstelle ist bereit. Sie wird – mit ihrer Unterschrift – den im ersten Schritt erzeugten CSR des Servers example.dahlen.org beglaubigen:

openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key \
  -CAcreateserial -out server.crt -days 365 -sha512

Wieder gibt es einige neue Parameter und Argumente:

x509

hier nicht als Argument sondern als Option aktiviert sie den Bereich Zertifikatsmanagement in OpenSSL

-req

definiert, daß ein CSR (und kein Zertifikat) als Eingabe erwartet wird

-in server.csr

Pfad zum eingereichten CSR

-CA ca.crt

Pfad zum (Stamm-) Zertifikat der CA

-CAkey ca.key

Pfad zum privaten Schlüssel der CA

-CAcreateserial

erzeugt eine Zertifikats-Seriennummer bei Bedarf und legt diese als Datei ca.srl ab

Zur Signatur werden zunächst Details aus dem CSR ausgegeben. Anschließend wird das Kennwort für die Schlüsseldatei ca.key angefordert:


Signature ok
subject=/C=DE/ST=Nordrhein-Westfalen/O=dahlen.org/CN=example.dahlen.org
Getting CA Private Key
Enter pass phrase for ca.key:


Damit ist der Prozeß der Zertifikat-Erzeugung abgeschlossen. Bei der Unterzeichnung durch die CA wurde auch die Laufzeit (-days 365) festgelegt. Der Inhalt des Zertifikats (server.crt) kann – in lesbarer Form – wie folgt ausgegeben werden:

openssl x509 -noout -text -in server.crt

Die Gültigkeit des Zertifikats im Hinblick auf die Zertifikatskette kann unter Angabe des öffentlichen CA-Zertifikats überprüft werden:

openssl verify -CAfile ca.crt server.crt

Im dritten Teil dieser Serie gehe ich auf die Verwendung der Server-Zertifikate und die Installation des CA Stammzertifikates für diverse Umgebungen ein.

Weiter zu Teil 3: Verwendung.

Der Beitrag Kostenlose TLS/SSL-Zertifikate durch eigene CA erstellen (Teil 2: Erzeugung) erschien zuerst auf dahlen.org.

Vor einiger Zeit habe ich eine Artikelserie über die Installation von ownCloud auf einem Raspberry PI veröffentlicht. Die für die Absicherung via Transport Layer Security (TLS, vormals SSL) verwendeten Schlüssel wurden damals durch die israelische Firma StartSSL zertifiziert und damit beglaubigt.

Nun sind diese Zertifikate abgelaufen und es ist Zeit für eine Erneuerung. Ein willkommener Anlaß etwas ausführlicher auf die Funktion von Schlüsseln, deren Beglaubigung durch (eigene) Certificate Authorities (CA) und die Installation auf Server und Client einzugehen.

Verschlüsselung und Authentifizierung

Über Sinn und Unsinn von Verschlüsselung muß meines Erachstens nicht diskutiert werden. Das Ziel ist es, Informationen vertraulich aufzubewahren und/oder abhörsicher zu übertragen, so daß sie nur dem Sender und den Empfängern zugänglich sind.

Art und Inhalt der Information sind dabei ohne Belang. Was privat und damit schützenswert und was öffentlich und potentiell einsehbar ist – darüber darf und sollte jeder Bürger eines freien Landes selbst entscheiden. Und wie die jüngsten Skandale rund um NSA, GCHQ, sowie die wiederkehrenden Rufe nach einer Vorratsdatenspeicherung demonstrieren, scheint kein Detail unseres Lebens trivial genug, als daß sich nicht jemand dafür interessieren würde — selbstverständlich nur zu unserer eigenen Sicherheit.

Verschlüsselung

Verschlüsselung macht aus einer Information (einer Datei, einer E-Mail oder dem Inhalt einer Verbindung) ein Geheimnis. Die angewandten, kryptographischen Verfahren lassen sich grob in zwei Kategorien unterteilen:

1. symmetrische Verschlüsselung (DES, AES, usw.) setzt auf einen einzelnen, dem Sender und den Empfängern bekannten Schlüssel (shared secret bzw. pre-shared-key).
2. asymmetrische Verschlüsselung (PGP, GnuPG, etc.) verwendet Schlüsselpaare, deren privater Teil (private key) vertraulich bleibt, während der öffentliche Teil (public key) verteilt wird.

Während bei symmetrischer Verschlüsselung der Schlüssel über ein anderes, sicheres Verfahren zwischen Sender und Empfänger ausgetauscht werden muß, benötigt man bei der asymmetrischen Verschlüsselung nur den öffentlichen Schlüsselteil des jeweils anderen Kommunikationspartners. Dieser kann im Vorfeld per E-Mail geschickt, zum Download angeboten oder über eine Public Key Infrastructure (PKI) öffentlich gemacht werden. Für die Verschlüsselung bzw. Entschlüsselung werden der öffentliche Schlüssel und der eigene private Schlüssel kombiniert.

Da die symmetrische Verschlüsselung einfacher und ressourcenschonend ist, kommen beide Verfahren oft in Kombination zur Anwendung:

• für den initialen Aufbau der Verbindung werden die öffentlichen Schlüssel von Server und Client ausgetauscht
• über die so mögliche asymmetrische Verschlüsselung wird anschliessend ein gemeinsamer Schlüssel ausgehandelt und auf symmetrische Verschlüsselung umgestellt

Diese Beschreibung ist bewußt einfach gehalten, Interessierten sei an dieser Stelle der entsprechende Eintrag bei Wikipedia oder ein Beratungsgespräch bei meinem Arbeitgeber Cassini Consulting GmbH empfohlen.

Authentifizierung

Die oben beschriebenen Methoden sind bereits ausreichend, um eine verschlüsselte Kommunikation zwischen zwei Endpunkten aufzubauen. Sie sagen aber nichts über die Identität der Schlüsselinhaber aus. Über eine sog. Man-in-the-middle Attacke kann ein Angreifer sich zum Zeitpunkt des Verbindungsaufbaus in den Kommunikationsweg einschalten, die ausgetauschten Schlüssel abfangen und durch eigene ersetzen. Er kann dann den gesamten Datenstrom entschlüsseln und mitzulesen, ohne das dies den eigentlichen Kommunikationspartnern auffällt.

Certificate Authority

Die Bestätigung von Schlüsseln durch Dritte ist daher wesentlicher Bestandteil der Verschlüsselungstopologie. Die Beglaubigung durch eine oder viele, als vertrauenswürdig geltende Instanzen soll einen öffentlichen Schlüssel validieren und seinen Inhaber identifizieren. Die Zertifizierung durch andere, akkreditierte Personen oder Organisationen soll somit die eigene Glaubwürdigkeit bestätigen. Auf diese Art und Weise bildet sich ein Netz aus Vertrauen, das sog. Web of Trust.

Während im Bereich PGP und GnuPG die Authentizität des Kommunikationspartners vornehmlich durch gegenseitige Bestätigung (z.B. auf Crypto-Parties) erreicht wird, übernehmen diese Aufgabe im World Wide Web und bei E-Mail-Verschlüsselung via S/MIME Certificate Authorities (CA).

Kommerzielle CAs

Rund um Zertifikate und Signaturen hat sich darum ein großer, lukrativer Markt entwickelt. Große CAs wie Verisign oder Global Sign versprechen Sicherheit durch gewissenhafte Prüfung und regelmässige Audits — zu entsprechenen Preisen. Günstigere oder gar kostenlose Angebote (wie das von StartSSL) bieten in der Regel lediglich eine Validierung der E-Mail-Adresse und des Domain Records.

Anbieter, deren Stammzertifikate Teil einer Browser- oder System-Installation sind, kommen dabei besonders gut weg, da ihre Kunden keinerlei Warnungen durch den Browser erwarten müssen. Faktisch kein Unternehmen, welches für Glaubwürdigkeit und Sicherheit steht, kann es sich erlauben ohne das Zertifikat einer solchen Root-CA zu arbeiten. Dabei zeigen z.B. der Fall DigiNotar oder die Gewißheit, daß eine Regierung bzw. deren Geheimdienste Unternehmen zur Preisgabe vertraulicher Informationen zwingen kann, daß absolute Sicherheit auch in diesem Bereich nicht existiert.

Die eigene CA

Die Hürde für die Einrichtung einer eigenen Certificate Authority ist äußerst niedrig. Technisch kann die eigene CA Schlüssel signieren und somit Zertifikate erzeugen, welche bzgl. Sicherheit in keinster Weise kommerziellen Varianten nachstehen. Im Gegenteil, sie kann sogar schneller aktuelle Entwicklungen im Bereich Verschlüsselung aufgreifen und anbieten, als es einem kommerziellen Anbieter mit definierten SLAs möglich ist. Außerdem löst die eigene CA die Abhängigkeit von (ausländischen) Unternehmen und deren Rechtsumfeld und spart natürlich Kosten.

Fachlich jedoch wird die eigene Certificate Authority einem akkreditierten Anbieter auf absehbare Zeit nicht das Wasser reichen können. Solange das Stammzertifikat (also der selbst-signierte öffentliche Schlüssel der CA) nicht in allen Clients, wie Computern, Mobiltelefonen, Programmen und Apps installiert ist, werden diese unweigerlich mehr oder weniger dramatische Warnungen beim Verbindungsaufbau aussprechen – oder den Aufbau ganz verweigern.

Aus diesem Grund richtet sich die Anleitung im zweiten Teil der Artikelserie primär an erfahrene Administratoren, welche ausgewählte Dienste in einem kontrollierten Umfeld, für ein definiertes Publikum mit einer sicheren, kostengünstigen Transport-Verschlüsselung anbieten wollen.

Weiter zu Teil 2: Erstellung.

Der Beitrag Kostenlose TLS/SSL-Zertifikate durch eigene CA erstellen (Teil 1: Grundlagen) erschien zuerst auf dahlen.org.