Kostenlose TLS/SSL-Zertifikate durch eigene CA erstellen (Teil 2: Erzeugung)

Im ersten Teil dieser Artikelserie habe ich Grundsätzliches zu Verschlüsselung und Authentifizierung, besonders im Umfeld der für https gebräuchlichen Transport Layer Security (TLS, vormals SSL) beschrieben.

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.

Kommentar hinterlassen