Ubuntu 16.04 Xenial Xerus
Ubuntu 14.04 Trusty Tahr
Ubuntu 12.04 Precise Pangolin
Diese Anleitung beschreibt die Aktivierung der SSL-Verschlüsselung für den Webserver Apache2 sowie die Erzeugung eines dazu nötigen SSL-Zertifikates samt zugehörigem privaten Schlüssel. Das Ziel ist es, Webseiten vom eigenen Webserver verschlüsselt über das Internet öffnen zu können.
Anfang April 2014 ist der Heartbleed-Bug (CVE-2014-0160) in OpenSSL bekannt geworden. Leider hat sich Canonical entschieden, bis einschließlich Ubuntu 14.04 nicht die aktualisierte Version 1.0.1g oder neuer zu nutzen, sondern nur die Pakete in den offiziellen Paketquellen zu patchen. Seit dem 7. April 2014 stehen diese als Update zur Verfügung. Man sollte sich daher nicht durch die scheinbar betroffene Versionsnummer des Pakets täuschen lassen.
Allerdings wird empfohlen, vor diesem Datum mit Ubuntu 12.04 oder neuer erstellte Zertifikat zu verwerfen und neue zu erstellen.
Zunächst gibt es 2 Wege, an ein Zertifikat zu kommen. Entweder kann es selbst erzeugt werden ("selbst-signiertes Zertifikat") oder man kann einer offiziellen Zertifizierungsstelle ("Certificate Authority", CA) einen entsprechenden Zertifikatsantrag zusenden und erhält ein offiziell gültiges Zertifikat zurück.
Der Unterschied liegt darin, dass ein von einer offiziellen CA unterschriebenes Zertifikat in der Regel von allen gängigen Programmen anstandslos als vertrauenswürdig akzeptiert wird. Für selbst-signierte Zertifikate lässt sich dementsprechend logischerweise nicht prüfen, ob dem Aussteller vertraut werden kann oder nicht und es werden entsprechende Warnungen bzw. Sicherheitsabfragen angezeigt. Für die Stärke bzw. Sicherheit der Verschlüsselung ist das gewählte Verfahren aber völlig irrelevant.
In jedem Fall benötigt man zunächst einen privaten Schlüssel. Dieser sollte immer auf eigens verwalteten Systemen erzeugt und gespeichert werden und niemals Dritten in die Hände gegeben werden - auch nicht der signierenden CA.
Es gibt CA's, welche komplette Zertifikate inklusive privaten Schlüsseln selbst erstellen und diese z.T. sogar noch in ungesicherten E-Mails zusammen an den Empfänger verschicken. Um solche Anbieter sollte ein großer Bogen gemacht werden: Niemand kann garantieren, dass der private Schlüssel wirklich keinem Dritten in die Hände fällt, womit das komplette Vertrauensmodell und auch die Sicherheit der Verschlüsselung ausgehebelt werden.
Der private Schlüssel soll als /etc/ssl/private/apache.key erzeugt werden. Da normale Benutzer auf diesen Ordner keinen Zugriff haben, sollte zunächst ein Pseudo-Root-Terminal [1] mittels
sudo -i
geöffnet werden.
Der private Schlüssel wird nun mit dem folgenden Kommando erzeugt:
openssl genrsa -out /etc/ssl/private/apache.key 2048
Die Angabe 2048
stellt die Stärke bzw. Länge des RSA-Schlüssels in bit ein; Schlüssel mit weniger als 2048 bit gelten aktuell als nicht mehr sicher. Ab Ubuntu 14.04 ist die Einstellung 2048
Standard und muss nicht explizit angegeben werden. Der private Schlüssel ist nicht durch eine Passphrase geschützt. Das ist notwendig, da Apache sonst bei jedem Neustart die manuelle Eingabe der Passphrase verlangen würde oder diese in der Konfiguration im Klartext hinterlegt werden müsste.
Kryptografie mit elliptischen Kurven
Ab Ubuntu 14.04 wird der Apache-Webserver in Version 2.4 ausgeliefert. Damit werden nun als Schlüsselformat neben herkömmlichen RSA-Schlüsseln sogenannte EC-Schlüssel (elliptic curve = Elliptische Kurve ) unterstützt, welche mit dem Kommando
openssl ecparam -out /etc/ssl/private/apache.key -name secp256k1 -genkey
erzeugt werden können. Mit -name secp224r1
wird der zu verwendende Algorithmus (die zu verwendende Kurve, analog zur Länge für einen RSA-Schlüssel) festgelegt. Welche Kurven genutzt werden können, lässt sich mit dem Befehl
openssl ecparam -list_curves
abfragen. Aktuell sollten vorwiegend die Kurven secp192r1
, secp256k1
, secp384r1
oder secp521r1
verwendet werden, da diese in den meisten Standards vertreten sind und somit am weitesten verbreitet sein dürften. Weitere Informationen dazu gibt es hier:
Not every elliptic curve is the same: trough on ECC security .
Da der private Schlüssel nun vorliegt, kann jetzt das eigentliche Zertifikat (/etc/ssl/certs/apache.crt) problemlos erzeugt werden. Dazu wird das folgende Kommando eingesetzt:
openssl req -new -x509 -key /etc/ssl/private/apache.key -days 365 -sha256 -out /etc/ssl/certs/apache.crt
Mit -days 365
wird das Zertifikat mit einer Gültigkeitsdauer von 365 Tagen erzeugt. Wird keine Dauer explizit angegeben, wird der Standardwert von 30 Tagen eingesetzt.
-sha256
bestimmt schließlich den Signaturalgorithmus für das Zertifikat (weitere Möglichkeiten sind u.a. -md5
oder -sha512
). Ab Ubuntu 14.04 wird -sha256
standardmäßig verwendet und muss nicht explizit angegeben werden.
Nach Bestätigen des Befehls mit der Eingabetaste werden noch einige Details zum Inhalt des Zertifikates abgefragt. Hier ist sicher der Common Name am wichtigsten, denn hier muss der Domainname stehen, für welchen das Zertifikat eingesetzt werden soll (beispielsweise "meine-seite.de").
Nun kann das Root-Terminal mit
exit
wieder geschlossen werden.
Um ein Zertifikat von einer CA anzufordern, muss zunächst ein "Certificate Signing Request" (CSR) erstellt werden. Das dazu genutzte Kommando ist demjenigen zum Erzeugen eines selbst-signierten Zertifikates sehr ähnlich. Da der CSR nicht von Apache selbst benutzt wird, kann er getrost im eigenen Heimatverzeichnis oder an einer beliebigen Stelle erstellt werden, an welcher man ihn später wieder findet.
openssl req -new -key /etc/ssl/private/apache.key -out ~/apache.csr
Nach Bestätigen des Befehls mit der Eingabetaste werden noch einige Details zum Inhalt des Zertifikates abgefragt. Hier ist sicher der Common Name am wichtigsten, denn hier muss der Domainname stehen, für welchen das Zertifikat eingesetzt werden soll (beispielsweise "meine-seite.de").
Wie mit dieser Datei zu verfahren ist, hängt von der jeweiligen CA ab und sollte auf deren Seiten erklärt sein. Die von der CA ausgestellte Zertifikatsdatei muss nun lediglich auf dem Server gespeichert werden (z.B. unter /etc/ssl/certs/apache.crt) und kann anschließend verwendet werden.
Um TLS/SSL verwenden zu können, muss der Apache auf TCP-Port 443
lauschen. Diese Einstellung wird in der Datei /etc/apache2/ports.conf vorgenommen. Wichtig ist dabei der Abschnitt
<IfModule mod_ssl.c> Listen 443 </IfModule>
In älteren Ubuntu- bzw. Apache-Versionen ist dieser Abschnitt u.U. auskommentiert und damit abgeschaltet. Zur Aktivierung müssen lediglich die Kommentarzeichen (vorangestellte #) entfernt werden.
Nach dieser Änderung muss die Konfiguration des Apache neu eingelesen werden:
sudo service apache2 reload
Nun muss das SSL-Modul des Apache aktiviert werden. Das geschieht mit den Kommandos
sudo a2enmod ssl sudo service apache2 force-reload
Abschließend muss nur noch ein Virtual Host für TLS/SSL eingerichtet werden. Für die Konfiguration wird die Datei /etc/apache2/sites-available/ssl (Apache 2.4: /etc/apache2/sites-available/ssl.conf) mit folgendem Inhalt erstellt:
<VirtualHost *:443> SSLEngine on SSLCertificateFile /etc/ssl/certs/apache.crt SSLCertificateKeyFile /etc/ssl/private/apache.key # Pfad zu den Webinhalten DocumentRoot /var/www/ </VirtualHost>
Ab Ubuntu 14.04 bzw. Apache 2.4 befinden sich die Webinhalte i.d.R. unter /var/www/html/, die Angabe DocumentRoot
muss also entsprechend angepasst werden.
Dieser VirtualHost wird nun mit
sudo a2ensite ssl.conf sudo service apache2 force-reload
bzw. vor Ubuntu 13.10
sudo a2ensite ssl sudo service apache2 force-reload
aktiviert.
Ältere Versionen des Apache-Webservers erlauben u.U. nur ein SSL-Zertifikat pro IP-Adresse. Das heißt, hier kann nur ein VirtualHost pro IP für den Port 443
angelegt werden. Damit wäre es z.B. nicht möglich, die Adressen https://seite1.de
und https://seite2.de
ohne Konfiguration einer zweiten IP-Adresse mit verschiedenen Zertifikaten ausliefern zu lassen.
In diesem Fall müssten entweder entsprechend zusätzliche IP-Adressen eingerichtet werden oder ein Zertifikat mit entsprechender Subject Alternative Name -Erweiterung verwendet werden.
Seit spätestens Ubuntu 12.04.2 besteht dieses Problem nicht mehr. Es können beliebig viele verschiedene SSL-VirtualHosts mit eigenen Zertifikaten für die gleiche IP-Adresse konfiguriert werden.
Selbstsignierte Zertifikate werden über entsprechende Warnhinweise prinzipiell als verdächtig bzw. unsicher eingestuft und der Client-Zugriff komplett blockiert. Daher müssen eigene Zertifikate erst heruntergeladen und über dauerhafte Ausnahmeregeln legimitiert werden. Falls Firefox dieses verweigert bzw. gar nicht erst anbietet, ruft man die Pseudo-Adresse about:config
auf und setzt den Wert des Schlüssels
browser.xul.error_pages.expert_bad_cert
auf true
. Inzwischen warnen auch andere Browser vor selbstsignierten Zertifikaten.
Erscheint beim Starten des Servers die Fehlermeldung
(98)Address already in use: make_sock: could not bind to address 0.0.0.0:443
no listening sockets available, shutting down
so sollten die Einträge in /etc/apache2/ports.conf überprüft werden. Dort darf der Eintrag
1 | Listen 443 |
nur einmal vorhanden sein. Auch in anderen Dateien der Apache-Konfiguration darf diese Direktive nicht nochmal vorkommen!
Erscheint beim Seitenaufruf im Browser die Fehlermeldung
ssl_error_rx_record_too_long
liegt das meist an fehlerhaft konfigurierten vHosts. Es sollten zwei NameServerHost-Einträge innerhalb der Dateien in /etc/apache2/sites-available/ vorhanden sein:
1 2 | NameVirtualHost *:80 NameVirtualHost *:443 |
Der Eintrag für Port 80
sollte im Abschnitt default
und der Eintrag für Port 443
im Abschnitt ssl
sein.
Oftmals wird gewünscht, dass gewisse Seiten nur über https://
erreicht werden können. Ein klassisches Beispiel sind Webmailer wie Squirrelmail oder RoundCube Webmail . Dies kann in vielen Fällen einfach mit der Apache Redirect-Directive oder mit dem Apache-Modul mod_rewrite erreicht werden.
Um die Sicherheit noch weiter zu erhöhen, kann das HTTP Strict Transport Security (HSTS)-Verfahren eingesetzt werden. Dadurch werden z. B. Man-in-the-middle-Angriffe erschwert. Um diese Funktion nutzen zu können, muss zuerst das Modul mod_headers
aktiviert werden:
sudo a2enmod headers
Anschließend muss in der vHost-Konfigurationsdatei (Port 443) folgende Zeile ergänzt werden:
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains;"
Mit der max-age
-Angabe wird dem Browser mitgeteilt, dass die entsprechende Website in den nächsten 365 Tagen (= 31536000 Sekunden) nur noch via HTTPS aufgerufen werden soll. Um die Änderungen wirksam zu machen, wird die Konfiguration neu geladen:
sudo /etc/init.d/apache2 reload
How to get free SSL certificates on Ubuntu with Let's Encrypt - Gratis SSL von Let's Encrypt
mod_ssl - Dokumentation bei apache.org
ssl-cert - selbstsignierte Zertifikate erstellen
CA - eigene Certification Authority betreiben
CAcert - Community, die kostenlose SSL-Zertifikate ausstellt
SSL Server Test - Online-Prüfung, Qualys SSL Labs
SSLyze - umfangreiche Testsuite für SSL-Server
Applied Crypto Hardening - möglichst sichere SSL-Konfiguration (PDF)
Diese Revision wurde am 17. November 2016 22:02 von LinkItUp erstellt.