Dieser Artikel beschreibt die Erstellung und Installation eines SSL-Zertifikats für den Apache 2.x Webserver, sowohl für Linux als auch für Windows.
Erstellen des „private key“
Zunächst ist ein „Private Key“ zu generieren. Das SSL-Zertifikat ist nur zusammen mit genau diesem Key gültig. Verliert man den private key, funktioniert auch das Zertifikat nicht mehr. Der private key kann auch nicht aus dem Zertifikat generiert oder sonstwie wiederhergestellt werden. Man sollte also an sicherer Stelle ein Backup des private keys aufbewahren.
Man kann den Key auch noch zusätzlich mit einem Passwort schützen, was aber dazu führt, dass man den Webserver nicht ohne Eingabe dieses Passwortes im SSL-Modus starten kann.
Falls man ein offizielles SSL-Zertifikat hat, der private key nicht mit einem Passwort verschlüsselt und der Server gehackt wird, muss man das Zertifikat bei der Zertifizierungsstelle zurückziehen (revoke). Andernfalls könnte der Hacker das SSL-Zertifikat für eigene Zwecke missbrauchen.
Die Schlüssellänge sollte 2048 Bit betragen (früher waren nur 1024 Bit empfohlen).
Ist der Apache Webserver auf einem Windows System installiert, dann müssen alle folgenden Befehle von der Windows-Eingabeaufforderung (cmd) ausgeführt werden. Das openssl-Executable befindet sich i.d.R. im Apache-Verzeichnis. Ggf. muss man den absoluten Pfadnamen angeben.
server:/chroot/web/opt/apache/conf# openssl genrsa -out server.key 2048
Generating RSA private key, 2048 bit long modulus
........................................................+++
..+++
e is 65537 (0x10001)
server:/chroot/web/opt/apache/conf#
Alternativ hier der Befehl für Verschlüsselung des private keys mit einem Passwort:
server:/chroot/web/opt/apache/conf# openssl genrsa -des3 -out server.key 2048
Generating RSA private key, 1024 bit long modulus
..............................................................................++++++
................................................++++++
e is 65537 (0x10001)
Enter pass phrase for server.key: ********
Verifying - Enter pass phrase for server.key: ********
server:/chroot/web/opt/apache/conf#
Certificate Signing Request (CSR) anlegen
Der CSR enthält die Firmeninformationen, Domainname, Email-Adresse usw. Diese Datei sendet man dann an die Zertifizierungsstelle und erhält das Zertifikat zurück. Alternativ kann man sich aus dem CSR auch ein self-signed certificate erstellen.
Er wird wie folgt erstellt (die Angabe des Bundesstaates – hier NRW – ist für die Erstellung eines offiziellen Zertifikats meistens erforderlich; nicht benötigte Felder kann man durch Eingabe eines Punktes „.“ überspringen):
server:/chroot/web/opt/apache/conf# openssl req -new -key server.key -out server.csr
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]:NRW
Locality Name (eg, city) []:Stadt
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Mein Name
Organizational Unit Name (eg, section) []:.
Common Name (eg, YOUR name) []:www.meinname.de
Email Address []:info@meinname.de
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:.
An optional company name []:.
server:/chroot/web/opt/apache/conf#
Hinweis: Unter Windows kann es erforderlich sein, die Konfigurationsdatei explizit mit -config <Pfad-auf-openssl.cnf> anzugeben.
CSR überprüfen
Mit folgendem Befehl stellt man fest, ob alle Angaben im CSR korrekt sind:
server:/chroot/web/opt/apache/conf# openssl req -noout -text -in server.csr
Certificate Request:
Data:
Version: 0 (0x0)
Subject: C=DE, ST=TH, L=Stadt, O=Mein Name, CN=www.meinname.de/emailAddress=info@meinname.de
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
Modulus (1024 bit):
00:c5:92:cf:97:27:cd:f5:53:47:94:b8:21:81:40:
4a:f0:bd:be:18:65:e2:f4:44:7e:64:69:73:5c:dd:
da:45:68:a5:bb:60:0c:f5:b3:32:96:57:2d:5d:eb:
37:3a:a4:8f:67:e0:44:ca:26:3d:7f:ab:b4:e3:28:
f5:c2:4a:4c:da:02:85:88:be:a0:28:61:77:bc:7e:
f3:c7:31:41:b5:c2:e9:22:43:c5:2f:13:4e:c9:c2:
2c:9e:b0:a9:a6:54:49:6a:5b:14:2c:b9:77:c3:1a:
0f:e9:82:c5:bf:ba:87:d7:29:1b:ec:f5:a3:28:a0:
05:39:d7:8a:03:e7:19:52:c9
Exponent: 65537 (0x10001)
Attributes:
a0:00
Signature Algorithm: md5WithRSAEncryption
5f:d0:31:d5:e4:fe:6d:25:d8:b3:a6:87:06:58:eb:f9:b2:78:
88:6f:2e:70:82:38:e3:82:92:6a:b8:bc:28:90:71:44:f7:ec:
6d:b0:d8:d8:e0:3c:69:87:16:a5:68:3e:8b:63:6a:d5:97:a1:
c1:9f:7c:e3:3c:fa:85:7a:84:eb:e7:aa:4e:59:72:c4:a4:03:
e3:bf:a5:aa:75:8e:10:2e:81:4a:28:69:fa:be:68:c6:22:47:
53:db:15:88:3e:51:39:c1:ce:86:e1:be:d4:e0:e2:9f:bf:bf:
c2:94:d5:0f:3c:bd:a5:2e:ff:be:e8:1b:76:95:a4:d2:49:9e:
78:64
server:/chroot/web/opt/apache/conf#
Alternativ kann man den CSR auch z.B. online überprüfen lassen. Einfach die CSR Datei ausgeben und mit Copy & Paste in das Formular übertragen.
server:/chroot/web/opt/apache/conf# cat server.csr
-----BEGIN CERTIFICATE REQUEST-----
MIIByzCCATQCAQAwgYoxCzAJBgNVBAYTAkRFMQwwCgYDVQQIEwNOUlcxETAPBgNV
BAcTCEJydWVnZ2VuMRkwFwYDVQQKExBBcm5lIFNjaGlybWFjaGVyMRswGQYDVQQD
ExJ3d3cuc2NoaXJtYWNoZXIuZGUxIjAgBgkqhkiG9w0BCQEWE2FybmVAc2NoaXJt
YWNoZXIuZGUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMWSz5cnzfVTR5S4
IYFASvC9vhhl4vREfmRpc1zd2kVopbtgDPWzMpZXLV3rNzqkj2fgRMomPX+rtOMo
-----END CERTIFICATE REQUEST-----
Self-signed Certificate erstellen
Für Testzwecke kann man sich auch das SSL-Zertifikat selber erstellen. Der einzige Unterschied zu einem offiziellen Zertifikat ist, dass der Webbrowser feststellt, dass es nicht von einer offiziellen Zertifizierungsstelle erstellt wurde. Alle Webbrowser zeigen eine Warnung an, wenn ein solches selbsterstelltes Zertifikat verwendet wird. Die eigentliche Verschlüsselung hingegen ist voll funktionsfähig, d.h. die Zugriffe auf eine mit einem selbsterstellten Zertifikat geschützte Website können ebensowenig entschlüsselt werden wie die Zugriffe auf eine Website mit einem offiziellen SSL-Zertifikat.
Solche selbsterstellten Zertifikate sollten jedoch keinesfalls für öffentlich zugängliche Webserver verwendet werden, und zwar aus folgendem Grund: Wenn viele SSL-Webseiten selbsterstellte Zertifikate verwenden, dann wird der durchschnittliche Internet-Nutzer der Webbrowser-Warnung keine Bedeutung mehr beimessen, und es tritt ein Gewöhnungseffekt ein.
<DIV mce_style=“clear:both“ style=“clear: both;“></DIV>
Mit folgendem Befehl wird ein self-signed certificate erstellt, das für 365 Tage gültig ist:
server:/chroot/web/opt/apache/conf# openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt
Signature ok
subject=/C=DE/ST=NRW/L=Stadt/O=Mein Name/CN=www.meinname.de/emailAddress=info@meinname.de
Getting Private key
server:/chroot/web/opt/apache/conf#
Offizielles SSL-Zertifikat (CRT) bestellen
Um ein „offizielles“ SSL-Zertifikat zu erhalten, muss der CSR an die Zertifizierungsstelle übermittelt werden, z.B. durch Ausfüllen eines Online-Bestellformulars. Man erhält dann im allgemeinen einen Downloadlink (mit Passwort) und eine Rechnung. Nach Prüfung aller Unterlagen ist das Zertifikat erstellt und kann installiert werden.
Bei der Bestellung von SSL Zertifikaten muss man beachten, dass nicht alle Zertifikate gleich sind. Die billigen Zertifikate besagen im Grunde nicht mehr, als dass der Aussteller des Zertifikats das Zertifikat per email an den Inhaber der Domain sendet (admin@domainname.com, hostmaster@domainname.com usw.), wer auch immer das ist. Bei den teureren Zertifikaten wird schon ernsthafter geprüft (Handelsregisterauszug, Personalausweis, telefonischer Rückruf usw.), ob der Inhaber tatsächlich derjenige ist, der er vorgibt zu sein.
Ein weiterer Gesichtspunkt ist die Kompatibilität zu verschiedenen Browsern. Ein „alter“ Browser erkennt die Zertifikate eines „neuen“ Ausstellers nicht, was für den Endanwender im Grunde dasselbe ist wie ein selbsterstelltes oder gar kein Zertifikat. Dies ist ein Problem mit vielen Billiganbietern. Es handelt sich hierbei zwar um offizielle Zertifikate, die aber nicht mit allen Browsern ohne Fehlermeldung funktionieren. Da die alten Browser jedoch praktisch ausgestorben sind, ist dies im Grunde nicht mehr relevant
Zuletzt sollte man noch darauf achten, ob das Zertifikat ohne weiteres im Webserver zu installieren ist oder ob es ein Zwischenzertifikat erfordert. Falls ja, hat man beim Installieren etwas mehr Aufwand.
Ein billiger und guter Anbieter ist https://www.psw.net/, der zahlreiche Zertifikate verschiedener Hersteller liefert. Sollte es mal Probleme geben, bekommt man auch umgehend kompetente Beratung – ein wichtiger Pluspunkt, wenn man ein Zertifikat für den kommerziellen Einsatz benötigt.
Ich verwende für eigene Webseiten das „LimitBreaker“ Zertifikat für € 39,- pro Jahr. Es ist auch mit wirklich uralten Browsern kompatibel, beispielsweise mit dem Microsoft Internet Explorer 3.0, Opera 3.0 und Netscape 2.0. Außerdem benötigt es kein Zwischenzertifikat auf dem Webserver.
Das „LimitBreaker“ Zertifikat wird bestätigt, indem die Autorisierungsstelle eine Email an eine bestimmte Email-Adresse sendet. Falls man das Zertifikat für einen Kunden bestellt, kann das ein Problem werden, wenn es sich um eine größere Organisation handelt. Alternativ kann man dann das etwas teurere „Comodo Silber“ Zertifikat bestellen, dieses kann auch der Auftraggeber bestätigen, muss sich aber vertraglich gegenüber der Autorisierungsstelle verpflichten, seinerseits für den korrekten Einsatz des Zertifikats zu sorgen.
Einige Anbieter stellen auch kostenlose Zertifikate aus, die sind allerdings nur 30 Tage gültig. Ideal für Testzwecke.
CRT anzeigen
Den Inhalt eines CRT lässt sich mit folgendem Befehl anzeigen:
openssl asn1parse -inform PEM -in server.crt
0:d=0 hl=4 l= 824 cons: SEQUENCE
4:d=1 hl=4 l= 673 cons: SEQUENCE
8:d=2 hl=2 l= 3 cons: cont [ 0 ]
10:d=3 hl=2 l= 1 prim: INTEGER :02
13:d=2 hl=2 l= 3 prim: INTEGER :0BED68
18:d=2 hl=2 l= 13 cons: SEQUENCE
20:d=3 hl=2 l= 9 prim: OBJECT :sha1WithRSAEncryption
...
Installation des SSL-Zertifikats
Das SSL-Zertifikat wird installiert, indem dem Webserver der Pfad auf das Zertifikat sowie auf den privaten Key mitgeteilt wird. Beim Apache 2.x Webserver ist die SSL-Konfiguration in eine separate Datei ausgelagert, die zunächst einmal in die Konfigurationsdatei conf/httpd.conf inkludiert werden muss (ist im Grundzustand auskommentiert):
# Secure (SSL/TLS) connections
Include conf/extra/httpd-ssl.conf
Sodann kann man in der httpd-ssl.conf Datei den gewünschten Eintrag für den virtuellen Host sowie die Pfade auf die Dateien anlegen:
VirtualHost _default_:443>
Directory /home/meinname.de/www>
Options FollowSymLinks Indexes ExecCGI
Order allow,deny
Allow from all
AllowOverride All
Directory
# General setup for the virtual host
DocumentRoot "/home/meinname.de/www"
ServerName www.meinname.de:443
ServerAdmin info@meinname.de
ErrorLog "|/opt/apache/bin/rotatelogs -l /home/meinname.de/log/ssl_error_log.%Y-%m-%d-%H_%M_%S 86400"
TransferLog "|/opt/apache/bin/rotatelogs -l /home/meinname.de/log/ssl_access_log.%Y-%m-%d-%H_%M_%S 86400"
# SSL Engine Switch:
# Enable/Disable SSL for this virtual host.
SSLEngine on
...
SSLCertificateFile /opt/apache/conf/server.crt
SSLCertificateKeyFile /opt/apache/conf/server.key
...
VirtualHost
Mehrere SSL-Domains pro Server
Mit dem Apache Webserver kann man zahlreiche unterschiedliche Websites auf ein und demselben Server betreiben. Die Domains haben dann alle dieselbe IP-Adresse und erst der Apache Webserver entscheided anhand des Domainnamens, der im GET Request mitgesendet wird, welche konkrete Domain angezeigt werden soll.
Bei der SSL-Verschlüsselung stellt sich nun das Problem, dass die Verschlüsselung initialisiert werden muss, bevor überhaupt Daten übertragen werden können. Der Domainname im GET-Request ist zu diesem Zeitpunkt noch gar nicht beim Server und folglich weiß der Apache Webserver nicht, welche Zertifikat zu dem Zugriff gehört. Das ist der Grund, weswegen man (normalerweise) nur eine einzige SSL-Verschlüsselung pro Server hinbekommt.
Es gibt folgende Lösungsmöglichkeiten:
SSL-enabled Name-based Apache Virtual Hosts
Mit der „Server Name Indication (SNI)“ SSL Erweiterung kann man den Apache so konfigurieren, dass jeder Virtual Host sein eigenes Zertifikat nutzt:
http://www.g-loaded.eu/2007/08/10/ssl-enabled-name-based-apache-virtual-hosts-with-mod_gnutls/
Multi-Domain Certificates
Dies sind Zertifikate, die mehr als eine Domain unterstützen. Weitere Domains lassen sich jederzeit nachrüsten.
Nachteil: jede zusätzliche Domain muss extra bezahlt werden
Wildcard Domain Certificates
Dies sind Zertifikate, die z.B. www.mydomain.de, shop.mydomain.de usw. verschlüsseln.
Nachteil: Wildcard Domain Certificates sind wesentlich teurer als normale Zertifikate. Evtl. muss man auch einen Reverse Proxy im Apache konfigurieren.
Zusätzliche IP-Adressen
Falls der Server mehrere IP-Adressen hat, kann man Apache so konfigurieren, dass jede SSL-Website eine andere IP-Adresse erhält. Dann kann man mehrere <VirtualHost>-Direktiven erstellen, die jeweils das gewünschte Zertifikat referenzieren.
Nachteil: Zusätzliche IP-Adressen sind nicht bei jedem Root-Server möglich und kosten meistens extra.
Zusätzliche Ports
Man kann auch anstelle zusätzlicher IP-Adressen andere Ports in den <VirtualHost>-Direktiven konfigurieren.
Nachteil: Man hat dann unschöne und wenig vertrauenerweckende URLs mit https://domainname:Nummer/