Tipp: SSL-Zertifikate mit openssl erstellen

Mit dem letzen Artikel  dieser Reihe haben wir
das Thema OpenSSL begonnen und uns Möglichkeiten angesehen,
bestehende Zertifikate von Webseiten auf der Konsole zu
überprüfen.

Um Webseiten mit einer SSL-Verschlüsselung versehen zu können,
muss hierfür neben dem Schlüssel des Servers (Key) ein
Zertifikat (Cert) erzeugt werden, das die Validität des
Schlüssels bestätigt.

Selbstsigniertes Zertifikat

Die einfachste Art, ein solches Zertifikat zu erzeugen, ist,
openssl die ganze Arbeit in einem Schritt erledigen zu
lassen. Der folgende Aufruf erzeugt den Schlüssel und das
Zertifikat in einem Arbeitsschritt. Der Schlüssel ist
2048 Bit lang, und das Zertifikat hat eine Gültigkeit von 365 Tagen.

user@linux ~ $ openssl req \
  -x509 -nodes -days 365 \
  -newkey rsa:2048 -keyout server.key -out server.crt
Generating a 2048 bit RSA private key
....+++
........................................+++
writing new private key to 'server.key'

Mit dem Erzeugen des Schlüssels in die Datei server.key ist
dieser Befehl noch nicht abgeschlossen. Der Befehl openssl
fragt direkt die Informationen für das Zertifikat ab. Die
Vorgabewerte können in der Datei /etc/ssl/openssl.conf
angepasst werden.

Country Name (2 letter code) [AU]:DE
State or Province Name (full name) [Some-State]:NRW
Locality Name (eg, city) []:Oberhausen
Organization Name (eg, company) [Internet Widgits Pty Ltd]:LUGOR
e. V.
Organizational Unit Name (eg, section) []:Webserver
Common Name (e.g. server FQDN or YOUR name) []:lugor.de
Email Address []:info@lugor.de

Der Parameter Common Name ist hier der
wichtigste Parameter. Er bestimmt den Namen, unter dem der Server
angesprochen werden kann. Stimmt dieser Name bei einer späteren
Prüfung nicht mit dem aufgerufenen Namen überein, gibt es eine
Warnmeldung seitens des Webbrowsers.

Wer nun diese beiden Dateien (server.key und server.crt) in
seinem Webserver ausprobiert, wird feststellen, dass es keine gute
Idee ist, selbstzertifizierte Zertifikate zu benutzen. Jeder
Teilnehmer, der auf den Server zugreift, bekommt beim ersten
Zugriff den Hinweis, dass es sich um ein selbstzertifiziertes
Zertifikat handelt und um fortzufahren das Zertifikat dem lokalen
Zertifikatsspeicher hinzugefügt werden muss.

Der Grund liegt darin, dass dem Zertifikat ein Herausgeber
(Issuer) fehlt, dem der Webbrowser vertraut und über den er die Validität
des Zertifikats prüfen kann.

Nachvollziehen lässt sich dies in der Textausgabe des
Zertifikats.

user@linux ~ $ openssl x509 -in server.crt -text -noout
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 15004674538806466012 (0xd03b4ffeafe855dc)
    Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=DE, ST=NRW, L=Oberhausen, O=LUGOR e. V.,
OU=Webserver,
                     CN=lugor.de/emailAddress=info@lugor.de
        Validity
            Not Before: Jul  9 19:02:36 2013 GMT
            Not After : Jul  9 19:02:36 2014 GMT
        Subject: C=DE, ST=NRW, L=Oberhausen, O=LUGOR e. V.,
OU=Webserver,
                       CN=lugor.de/emailAddress=info@lugor.de
[...]

Gut zu sehen ist die Übereinstimmung von Issuer und Subject.

Einsatz von Zertifizierern

Um für den Webserver ein Zertifikat erzeugen zu können, das im
Webbrowser gültig, ist muss ein hinterlegter Zertifizierer
(Trustcenter) damit betraut werden, den von uns erzeugten
Schlüssel zu zertifizieren.

Dafür erzeugen wir zunächst den Schlüssel und lassen ihn in die
Datei server.key schreiben.

user@linux ~ $ openssl genrsa -out server.key  2048
Generating RSA private key, 2048 bit long modulus
....................+++
.....+++
e is 65537 (0x10001)

Dieser Schlüssel ist 2048 Bit lang und nicht verschlüsselt.

Anmerkung
Viele Anleitungen enthalten zusätzliche Parameter wie
-aes256 oder -des3. Damit wird der Schlüssel durch die
angegebene Verschüsselung abgesichert und muss für den Einsatz
vorher wieder entschlüsselt werden.

Im Gegensatz zum ersten Beispiel lassen wir nun nicht das
Zertifikat erzeugen, sondern generieren eine Zertifikatsanfrage
(Certificate Sign Request oder CSR), die wir nach der
Erzeugung an den Zertifizierer weiterleiten können.

Die Angaben entsprechen denen, die wir auch beim
selbstzertifizierten Zertifikat angegeben haben.

user@linux ~ $ openssl req -new -key server.key -out server.csr
[...]
Country Name (2 letter code) [AU]:DE
State or Province Name (full name) [Some-State]:NRW
Locality Name (eg, city) []:Oberhausen
Organization Name (eg, company) [Internet Widgits Pty Ltd]:LUGOR
e. V.
Organizational Unit Name (eg, section) []:Webserver
Common Name (e.g. server FQDN or YOUR name) []:lugor.de
Email Address []:info@lugor.de
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

Die resultierende Datei server.csr enthält alle Informationen,
um dem Zertifizierer seine Arbeit zu ermöglichen.

Natürlich können wir uns auch wieder den Inhalt in für uns lesbarer
Form ansehen.

user@linux ~ $ openssl req -in server.csr -text -noout
Certificate Request:
    Data:
        Version: 0 (0x0)
        Subject: C=DE, ST=NRW, L=Oberhausen, O=LUGOR e. V.,
                        OU=Webserver,
CN=lugor.de/emailAddress=info@lugor.de
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
[...]

Der nächste Schritt ist nun, die Zertifikatsanfrage an den
Zertifizierer zu übergeben und von ihm dann das Zertifikat zu
erhalten.

Es ist auch möglich, selbst zum Zertifizierer zu werden und damit
die Zertifikate selbst zu unterschreiben. Dies ist für
größere Infrastrukturen eine gute Möglichkeit, vollständig auf
selbstzertifizierte Zertifikate verzichten zu können, ohne jedes Zertifikat direkt
vom Zertifizierer bestätigen zu lassen.

Wenn man dies mit einer eigenen Instanz vornimmt, muss diese
in alle Webbrowser integriert werden, damit sie wie die bereits
etablierten Zertifizierer hinterlegt ist und die genutzten
Zertifikate ohne Nachfrage angenommen werden.

So weit zur Erzeugung von Zertifikaten mit openssl. Im nächsten
Artikel dieser Reihe bauen wir Schlüssel und Zertifikat in die
Webserver Apache HTTP und nginx ein.