Tipp: SSL-Zertifikate mit OpenSSL erzeugen
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.
NOTE: 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.