Let’s Encrypt stellt kostenfreie SSL Zertifikate aus, welche von den gängigen Betriebssystemen und Browsern akzeptiert werden. Diese sind jeweils nur 90 Tage gültig und müssen daher regelmäßig erneuert werden. Damit dies nicht immer manuell geschehen muss gibt es Tools welche diesen Vorgang automatisieren. Das offizielle Tool dafür istcertbot. In diesem Beitrag beschreibe ich wie unter Raspbian Jessie Lite mit nginx, certbot und dem webroot Plugin Zertifikate für Webseiten angefragt und automatisch erneuert werden können.
Installation
In den offiziellen Paketquellen von Raspbian Jessie Lite ist keine Version von certbot verfügbar. Allerdings enthält das Backports Repository von Debian Jessie, auf welchem Raspbian Jessie Lite basiert, eine recht aktuelle Version von certbot. Damit diese Installiert werden kann muss allerdings zuerst das Backports Repository aktiviert werden. Wie dies funktioniert habe ich im Beitrag Debian Backports in Raspbian Jessie Lite aktivieren und verwenden beschrieben.
Nachdem das Backports Repository aktiviert wurde kann nach dem Aktualisieren der Paketlisten certbot installiert werden.
In diesem Beitrag beschreibe ich wie nginx mit einer sicheren SSL Konfiguration und PHP auf Raspbian Jessie installiert und konfiguriert werden kann.
nginx & PHP installieren
Zuerst müssen nginx und PHP mit nachfolgendem Befehl installiert werden.
$ sudo apt-get install nginx php5-fpm
PHP testen
Nun sollte überprüft werden das PHP auch tatsächlich funktioniert. Dazu muss die Konfiguration der nginx Standardseite (/etc/nginx/sites-available/default) angepasst werden. Es müssen vor folgenden Zeilen die Kommentarzeichen entfernt werden.
location ~ \.php$ {
include snippets/fastcgi-php.conf;
fastcgi_pass unix:/var/run/php5-fpm.sock;
}
Anschließend muss noch die nginxKonfigurationneugeladen werden, damit die Änderungen wirksam werten. Vorher sollte getestet werden, dass die Konfiguration keine Fehler enthält.
Nun kann einfach eine Datei phpinfo.php mit nachfolgendem Inhalt im Verzeichnis der Standardwebsite (/var/www/html/) angelegt werden.
<?php phpinfo(); ?>
Abschließend kann die Datei einfach über den Webbrowser aufgerufen werden (z.B. über http://example.com/phpinfo.php). Die Ausgabe sollte folgendermaßen aussehen.
nginx Konfigurieren
Nach der Installation muss nginx noch konfiguriert werden. Dies ist etwas aufwendiger als für PHP. Die Hauptkonfigurationsdatei ist /etc/nginx/nginx.conf. Die Konfiguration der einzelnen Seiten befindet sich im Verzeichnis /etc/nginx/sites-available/ und die Konfiguration der aktuell aktivierten Seiten im Verzeichnis /etc/nginx/sites-enabled/.
/etc/nginx/nginx.conf
Schauen wir uns zuerst die Hauptkonfigurationsdatei genauer an.
Zu Beginn werden generelle Parameter festgelegt.
user definiert den Linux Benutzer unter dem nginx laufen soll. www-data ist der Standardnutzer unter dem Webserver unter Debian/Ubuntu laufen.
worker_processes ist die Anzahl der nginx Prozesse. auto versucht den besten Wert automatisch zu finden.
pid ist zur Kommunikation mit dem Betriebssystem und sollte auch bei dem Standardwert (\run\nginx.pid) belassen werden.
woker_connections innerhalb von events definiert die maximale Anzahl von Verbindungen pro nginx Prozess (768 ist der Standardwert).
Der nächste Block (http) definiert die Parameter für die eigentlichen Verbindungen.
Basiseinstellungen
sendfile, tcp_nopush und tcp_nodelay erhöhen die Performance von nginx
keepalive_timeout definiert die Zeit in Sekunden zu welcher eine Verbindung vom Webserver geschlossen wird. Danach muss eine neue TCP und TLS Verbindung aufgebaut werden.
ssl_protocols erlaubt nur TLS in Version 1.0, 1.1 oder 1.2.
ssl_ciphers erlaubt nur Algorithmen mit Perfect Forward Security. Das bedeutet, dass auch wenn später der Private Key kompromittiert wurde die alten Verbindungen nicht entschlüsselt werden können.
ssl_prefer_server_ciphers sagt das die Algorithmenpreferenz des Servers und nicht des Clients verwendet werden soll.
ssl_session_cache definiert, dass es einen 10 MB Cache gibt in welchem Verbindungsinformationen zwischengespeichert werden. Dies erlaubt es bei Wiederaufnahme einer Verbindung einige Schritte im Verbindungsaufbau zu sparen.
ssl_dhparam verweist auf selbst generierte EECDH/EDH Parameter welche verwendet werden sollen. Sie sind länger als die Standardmäßig verwendeten Parameter. Wie diese generiert werden beschreibe ich weiter unten.
ssl_stapling und ssl_stapling_verify sagt das der Server Informationen über die Gültigkeit des Zertifikates überprüfen und beim Verbindungsaufbau an den Client schicken soll.
ssl_ecdh_curve spezifiziert die Kurve welche für ECDHE verwendet werden soll. Die hier angegebene Kurve verwendet längere Schlüssel als die standardmäßig verwendete.
ssl_session_tickets deaktiviert Session Tickets, da diese Forward Security aushebeln können.
Header
add_header X-Content-Type-Options verbietet mime-sniff in Chrome und Internet Explorer
add_header X-Frame-Options verbietet es die Website auf einer anderen Domain in einem frame oder iframe zu laden.
Logging
access_log legt fest in welcher Datei alle Zugriffe geloggt werden sollen
error_log legt fest in welcher Datei alle Fehlermeldungen geloggt werden sollen
Gzip
gzip setzt ob gzip aktiviert werden soll oder nicht. Da all meine Webseiten nur per TLS erreichbar sind und gzip mit TLS ein Sicherheitsrisiko darstellt habe ich es deaktiviert.
Vitual Host Konfigurationen
Lädt zusätzliche Konfigurationsdateien aus dem Unterordner conf.d sowie die aktiven Seiten im Unterordner sites-enabled.
Da ich längere Parameter verwenden möchte als die Standardkonfiguration müssen die dhparam selber generiert werden. Dies kann wie nachfolgend beschrieben im Terminal erledigt werden – es kann einige Stunden dauern bis der Befehl zum Generieren erfolgreich ausgeführt wurde.
$ cd /etc/ssl/certs
$ sudo openssl dhparam -out dhparam.pem 4096
Generating DH parameters, 4096 bit long safe prime, generator 2
This is going to take a long time
........................................................................................................................................................................................................................................................................................................................+......................................................................................................................................................................................................+.............................................................................+..........................................................................................................................................................................................................................................................+...............................................................................................................+......................+..........................................+......................................................................................................................................+......................................+................................+........................................+........................................................................................+...............................................+..............................................................................................................................+..........................................................................+.................................................................................+........+......................................................+...................................................................................................................................................................................................+................+................................................+.............................................................+....................................................................................................................+...............................................+...................................................................................................................................................................................................................................................+......................
[...]
Konfiguration für eine neue Seite erstellen
Die Konfigurationsdateien der einzelnen Seiten befinden sich im Verzeichnis /etc/nginx/sites-available/. Ich verwende immer nachfolgendes Template als Basis für meine PHP-Seiten. Die Konfiguration leitet HTTP Verbindungen automatisch auf verschlüsselte HTTPS Verbindungen um. Parameter wie der Domainname, Pfad zum SSL-Zertifikat und das Verzeichnis müssen natürlich für jede Website angepasst werden.
Die Konfiguration besteht aus zwei server Blöcken. Einer für Port 80 (HTTP) und einer für Port 443 (HTTPS).
Die Konfiguration des ersten server Blocks (HTTP)
listen gibt an auf welchen IP-Adressen und Ports die Website reagieren soll. 80 sagt aus, dass über alle verfügbaren IPv4 Adressen Verbindungen auf Port 80 akzeptiert werden sollen. [xxx:xxx:xxx::42]:80 sagt aus, dass die Website via IPv6 nur über die IP-Adresse xxx:xxx:xxx::42 und Port 80 erreichbar ist. Falls die Konfiguration als Standard verwendet werden soll, falls keine andere zur Anfrage passt, muss jeweils hinter der 80 noch default_server ergänzt werden.
server_name gibt die Domain an, für welche die Konfiguration gilt.
return leitet auf eine andere Website weiter. In diesem Fall mittels 301 (Dauerhaft Verschoben) auf die verschlüsselte Verbindung (HTTPS).
listen ist identisch wie für den ersten Block außer das der Block auf Port 443 hört und nicht 80.
server_name gibt wie beim ersten Block die Domain an, für welche die Konfiguration gilt.
ssl_certificate gibt den Pfad zum SSL Zertifikat der Website an.
ssl_certificate_key gibt den Pfad zum Privaten Schlüssel des SSL Zertifikats der Website an.
add_header Strict-Transport-Security sagt dem Client, dass er die Website nur über HTTPS aufrufen soll und dies auch für alle Subdomains gilt. An dieser Stelle muss man vorsichtig sein und prüfen ob dies auch wirklich für alle Subdomains gilt. Außerdem sagt max-age für wie lange diese Einstellung gilt. Innerhalb dieser Zeit leitet der Browser den Besucher automatisch auf HTTPS weiter. Das heißt es ist nicht einfach möglich HTTPS abzuschalten, sondern benötigt eine Vorlaufzeit. Der Wert 63072000 entspricht 2 Jahren. Zum Testen sollte ein niedriger Wert wie z.B. 300 (5 Minuten) verwendet werden, welcher langsam erhöht wird. Es kann auch beantragt werden diese Einstellung fest in die gängigsten Browser aufzunehmen. Details dazu gibt es auf der Website der HTST Preload List.
root gibt das Verzeichnis an, in dem die Website liegt.
index gibt den Dateinamen der Datei an, welche angezeigt werden soll, falls ein Verzeichnis als URL angegeben wurde. Damit dies geschieht muss eine Datei mit diesem Namen in dem angefragten Verzeichnis vorhanden sein.
location \ sagt, dass zuerst nach einer Datei mit dem angefragten Namen gesucht werden soll, anschließend ob ein Verzeichnis mit dem Namen existiert. Falls beides nicht existiert wird ein 404 Fehler zurückgegeben.
location ~ \.php$ leitet PHP-Dateien an den Interpreter weiter.
server {
listen 80;
listen [xxx:xxx:xxx::42]:80;
server_name example.com;
return 301 https://$server_name$request_uri;
}
server {
listen 443 ssl;
listen [xxx:xxx:xxx::42]:443 ssl;
server_name example.com;
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
add_header Strict-Transport-Security "max-age=63072000; includeSubdomains;";
root /var/www/com.example;
index index.php;
location / {
# First attempt to serve request as file, then
# as directory, then fall back to displaying a 404.
try_files $uri $uri/ =404;
}
# pass the PHP scripts to FastCGI server
location ~ \.php$ {
include snippets/fastcgi-php.conf;
fastcgi_pass unix:/var/run/php5-fpm.sock;
}
# snippet for updating letsencrypt certificates
include snippets/certbot-webroot.conf;
}
Nun muss noch das Verzeichnis für die Webseitendaten erstellt werden.
$ sudo mkdir -p /var/www/com.example
Neue Seite aktivieren
Um die Konfiguration einer Seite im Verzeichnis /etc/nginx/sites-available/ zu aktivieren muss ein Symmetrischer Link zu dieser Datei im Verzeichnis /etc/nginx/sites-enabled angelegt werden.
Nachdem die Konfiguration wie oben beschrieben geändert wurde muss sie nur noch von nginx neu geladen werden. Bevor sie geladen wird sollte allerdings noch geprüft werden, ob sie Fehler enthält.
$ sudo nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
$ sudo /etc/init.d/nginx reload
[ ok ] Restarting nginx (via systemctl): nginx.service.
Nun kann noch die Seite des Qually Labs SSL Tests aufgerufen werden, welches die verwendete Sicherheitsverfahren und Algorithmen von Webservern prüft und bewertet. Wenn alles wie oben beschrieben konfiguriert wurde sollte die Bewertung A+ sein, was der Best möglichen Bewertung entspricht.
WordPress ist ein Content Management System (CMS), welches es erlaubt relativ einfach den Inhalt einer statischen Webseiteoder eines Blogs zu pflegen. Es basiert auf PHP und benötigt einen Webserver sowie eine Datenbank zur Ausführung. Ich beschreibe in diesem Beitrag wie WordPress unter Ubuntu Linux 16.04 mit nginx als Webserver, SSL Zertifikate von Let’s Encrypt sowie MariaDB bzw. MySQL als Datenbank installiert werden kann. Wie diese Dinge Konfiguriert werden können habe ich bereits in folgenden Beiträgen beschrieben
Zuerst sollte wie in den oben verlinkten Beiträgen eine nginx Konfigurationsdatei erstellt sowie ein Let’s Encrypt SSL Zertifikat beantragt werden.
Falls für das Beantragen der SSL Zertifikate ein dummy-Verzeichnis verwendet wurde muss zuerst ein Verzeichnis für die WordPress Dateien angelegt werden.
$ sudo mkdir -p /var/www/com.example.blog
Damit es später möglich ist WordPress über die Webseite zu aktualisieren sollten die Rechte an diesem Ordner dem Benutzer und der Gruppe www-data zugewiesen werden.
Danach muss die nginx Konfiguration unter /etc/nginx/sites/available/com.example.blog durch nachfolgende ersetzt werden – natürlich mit den eigenen Angaben für IP-Adressen, Domains, Pfade etc.
server {
listen 80;
listen [xxx:xxx:xxx::42]:80;
server_name blog.example.com;
return 301 https://$server_name$request_uri;
}
server {
listen 443 ssl;
listen [xxx:xxx:xxx::42]:443 ssl;
server_name blog.example.com;
ssl_certificate /etc/letsencrypt/live/blog.example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/blog.example.com/privkey.pem;
add_header Strict-Transport-Security "max-age=63072000; includeSubdomains;";
root /var/www/com.example.blog;
index index.php;
location = /robots.txt {
try_files $uri $uri/ /index.php?$args;
}
location / {
# First attempt to serve request as file, then
# as directory, then fall back to displaying a 404.
try_files $uri $uri/ /index.php?$args;
}
# pass the PHP scripts to FastCGI server
location ~ \.php$ {
include snippets/fastcgi-php.conf;
fastcgi_pass unix:/run/php/php7.0-fpm.sock;
}
# snippet for updating letsencrypt certificates
include snippets/certbot-webroot.conf;
}
Nun muss die Konfiguration ggf. noch aktiviert werden.
Damit ist nginx fertig konfiguriert und die WordPress Dateien können heruntergeladen, entpackt und ihre Rechte gesetzt werden. Falls die englische Version von WordPress installiert werden soll muss die Datei https://wordpress.org/latest.zip heruntergeladen werden.
Bevor die Installation gestartet wird muss noch eine Datenbank für WordPress angelegtwerden. Wie eine Datenbank mit zugehörigem Benutzer angelegt werden kann habe ich im Beitrag MySQL oder MariaDB Datenbank über das Terminal erstellen beschrieben.
Installation
Nun, da nginx, Let’s Encrypt und MariaDB bzw. MySQL konfiguriert wurde kann die Installation gestartet werden. Dazu muss einfach die in nginx konfigurierte Domain aufgerufen werden, hier im Beispiel also https://blog.example.com. Auf der nun angezeigten Webseite kann einfach auf „Los geht’s!“ geklickt werden.
Im zweiten Schritt müssen die Verbindungsinformationen zur Datenbank eingegeben werden. Anschließend können diese mit einem Klick auf „Senden“ gespeichert werden.
Der dritte Schritt erlaubt es mit einem Klick auf „Installation ausführen“ die eigentliche Installation von WordPress zu starten.
Im vierten Schritt werden Angaben wie der Titel der Webseite sowie Benutzername und Passwort verlangt. Nachdem dies ausgefüllt wurde kann einfach auf „WordPress Installieren“ geklickt werden.
Der fünfte Schritt besteht lediglich aus einer Bestätigung, dass WordPress erfolgreich installiert wurde. Mit einem Klick auf „Anmelden“ wird der Browser auf die Anmeldeseite von WordPress weitergeleitet.
WordPress wurde damit erfolgreich installiert und kann genutzt werden.
Let’s Encrypt stellt kostenfreie SSL Zertifikate bereit, welche über den offiziellen Client certbot abgefragt werden können. Wie Let’s Encrypt SSL Zertifikate unter Ubuntu Linux 16.04 Server für Webseiten bzw. andere Dienste angefragt werden können habe ich in den Beiträgen Let’s Encrypt SSL Zertifikate unter Ubuntu Linux 16.04 Server mittels nginx und webroot Plugin beziehen bzw. Let’s Encrypt SSL Zertifikate für Dienste ohne Website wie postfix oder dovecot unter Ubuntu Linux 16.04 Server mittels nginx und webroot Plugin beziehen beschrieben. Die Zertifikate sind nur 90 Tage lang gültig und müssen spätestens danach erneuert werden. Dies wird durch einen bei der Installation von certbot automatisch angelegten timer erledigt. Dieser prüft alle 12 Stunden, ob ein Zertifikat in den nächsten 30 Tagen abläuft. Ist dies der Fall wird das Zertifikat erneuert. Der Befehl zum Überprüfen wird allerdings als root ausgeführt. In diesem Beitrag beschreibe ich wie die Zertifikate als nicht root Benutzer automatisch erneuert werden können.
Im Beitrag Let’s Encrypt SSL Zertifikate unter Ubuntu Linux 16.04 Server mittels nginx und webroot Plugin beziehen habe ich beschrieben, wie es mithilfe des certbot Tools möglich ist SSL Zertifikate von Let’s Encrypt über nginx und das webroot Plugin zu beziehen. Dieser Mechanismus funktioniert aber nur für Webseiten. Für Dienste, welche keine Webseite über nginx bereitstellen ist dieses Verfahren nicht geeignet. Mit einer leichten Modifikation können aber auch SSL Zertifikate für Dienste ohne Webseiten wie postfix oder dovecot bezogen werden. In diesem Beitrag beschreibe ich die notwendigen Anpassungen dafür.
In diesem Beitrag beschreibe ich wie unter Ubuntu Linux 16.04 Server ein nginx Webserver mit sicherer SSL Konfiguration, PHP und MariaDB oder MySQL Unterstützung installiert und konfiguriert werden kann.
Installation
nginx
nginx ist in den offiziellen Paketquellen von Ubuntu 16.04 vorhanden und kann somit einfach über apt-get installiert werden.
$ sudo apt-get install nginx
PHP
PHP kann auch einfach über die offiziellen Paketquellen installiert werden.
$ sudo apt-get install php-fpm
MariaDB / MySQL
Wie ein MariaDB bzw. MySQL Server installiert und konfiguriert werden kann habe ich im Beitrag MySQL oder MariaDB unter Ubuntu Linux 16.04 installieren und konfigurieren beschrieben. Hier geht es darum PHP eine Verbindung zur Datenbank zu ermöglichen. Dazu kann einfach das entsprechende Paket aus den offiziellen Paketquellen installiert werden.
$ sudo apt-get install php-mysql
Konfiguration
PHP & MariaDB bzw. MySQL
PHP und MariaDB bzw. MySQL kann einfach zusammen konfiguriert werden. Für PHP muss die Datei /etc/php/7.0/fpm/php.ini angepasst werden. Dabei sollte folgende Zeile auskommentiert und der Wert auf 0 gesetzt werden.
[...]
cgi.fix_pathinfo=0
[...]
Anschließend muss php-fpm noch neu geladen werden – dies aktiviert auch die MySQL Unterstützung.
Damit sollte PHP mit MariaDB bzw. MySQL Unterstützung funktionieren.
PHP testen
Nun sollte kurz getestet werden das PHP auch tatsächlich funktioniert. Dazu muss zunächst die Konfiguration der nginx Standardseite (/etc/nginx/sites-available/default) angepasst werden. Es müssen vor folgenden Zeilen die Kommentarzeichen entfernt werden.
location ~ \.php$ {
include snippets/fastcgi-php.conf;
fastcgi_pass unix:/run/php/php7.0-fpm.sock;
}
Anschließend muss noch die nginx Konfiguration neu geladen werden, damit die Änderungen wirksam werten. Vorher sollte getestet werden, dass die Konfiguration keine Fehler enthält.
$ sudo nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
$ sudo /etc/init.d/nginx reload
[ ok ] Reloading nginx configuration (via systemctl): nginx.service.
Nun kann einfach eine Datei phpinfo.php mit nachfolgendem Inhalt im Verzeichnis der Standardwebsite (/var/www/html/) angelegt werden.
&lt;?php phpinfo(); ?&gt;
Abschließend kann die Datei einfach über den Webbrowser aufgerufen werden (z.B. über http://example.com/phpinfo.php). Die Ausgabe sollte folgendermaßen aussehen.
nginx
Nach der Installation muss nginx noch konfiguriert werden. Dies ist etwas aufwendiger als für PHP oder MySQL. Die Hauptkonfigurationsdatei ist /etc/nginx/nginx.conf. Die Konfiguration der einzelnen Seiten befindet sich im Verzeichnis /etc/nginx/sites-available/ und die Konfiguration der aktuell aktivierten Seiten im Verzeichnis /etc/nginx/sites-enabled/.
/etc/nginx/nginx.conf
Schauen wir uns zuerst die Hauptkonfigurationsdatei genauer an.
Zu Beginn werden generelle Parameter festgelegt.
user definiert den Linux Benutzer unter dem nginx laufen soll. www-data ist der Standardnutzer unter dem Webserver unter Debian/Ubuntu laufen.
worker_processes ist die Anzahl der nginx Prozesse. auto versucht den besten Wert automatisch zu finden.
pid ist zur Kommunikation mit dem Betriebssystem und sollte auch bei dem Standardwert (\run\nginx.pid) belassen werden.
woker_connections innerhalb von events definiert die maximale Anzahl von Verbindungen pro nginx Prozess (768 ist der Standardwert).
Der nächste Block (http) definiert die Parameter für die eigentlichen Verbindungen.
Basiseinstellungen
sendfile, tcp_nopush und tcp_nodelay erhöhen die Performance von nginx
keepalive_timeout definiert die Zeit in Sekunden zu welcher eine Verbindung vom Webserver geschlossen wird. Danach muss eine neue TCP und TLS Verbindung aufgebaut werden.
ssl_protocols erlaubt nur TLS in Version 1.0, 1.1 oder 1.2.
ssl_ciphers erlaubt nur Algorithmen mit Perfect Forward Security. Das bedeutet, dass auch wenn später der Private Key kompromittiert wurde die alten Verbindungen nicht entschlüsselt werden können.
ssl_prefer_server_ciphers sagt das die Algorithmenpreferenz des Servers und nicht des Clients verwendet werden soll.
ssl_session_cache definiert, dass es einen 10 MB Cache gibt in welchem Verbindungsinformationen zwischengespeichert werden. Dies erlaubt es bei Wiederaufnahme einer Verbindung einige Schritte im Verbindungsaufbau zu sparen.
ssl_dhparam verweist auf selbst generierte EECDH/EDH Parameter welche verwendet werden sollen. Sie sind länger als die Standardmäßig verwendeten Parameter. Wie diese generiert werden beschreibe ich weiter unten.
ssl_stapling und ssl_stapling_verify sagt das der Server Informationen über die Gültigkeit des Zertifikates überprüfen und beim Verbindungsaufbau an den Client schicken soll.
ssl_ecdh_curve spezifiziert die Kurve welche für ECDHE verwendet werden soll. Die hier angegebene Kurve verwendet längere Schlüssel als die standardmäßig verwendete.
ssl_session_tickets deaktiviert Session Tickets, da diese Forward Security aushebeln können.
Header
add_header X-Content-Type-Options verbietet mime-sniff in Chrome und Internet Explorer
add_header X-Frame-Options verbietet es die Website auf einer anderen Domain in einem frame oder iframe zu laden.
Logging
access_log legt fest in welcher Datei alle Zugriffe geloggt werden sollen
error_log legt fest in welcher Datei alle Fehlermeldungen geloggt werden sollen
Gzip
gzip setzt ob gzip aktiviert werden soll oder nicht. Da all meine Webseiten nur per TLS erreichbar sind und gzip mit TLS ein Sicherheitsrisiko darstellt habe ich es deaktiviert.
Vitual Host Konfigurationen
Lädt zusätzliche Konfigurationsdateien aus dem Unterordner conf.d sowie die aktiven Seiten im Unterordner sites-enabled.
Da ich längere Parameter verwenden möchte als die Standardkonfiguration müssen die dhparam selber generiert werden. Dies kann wie nachfolgend beschrieben im Terminal erledigt werden – es kann einige Minuten dauern bis der Befehl zum Generieren erfolgreich ausgeführt wurde.
$ cd /etc/ssl/certs
$ sudo openssl dhparam -out dhparam.pem 4096
Generating DH parameters, 4096 bit long safe prime, generator 2
This is going to take a long time
......................................................................+.................................................................................................................................................................................................................................................................................................................+.......................................................................................+........................+............................................................................................+........................+........................................................................................................................................................................................................................................................................................................................+...................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................+.........................................................................................................................................+..............................................................+....................................................................................................................................................+................................................................................................................................................................................................................................................................................................................................................................................................................................................................+...............................................................................................................................................+....
[...]
Konfiguration für eine neue Seite erstellen
Die Konfigurationsdateien der einzelnen Seiten befinden sich im Verzeichnis /etc/nginx/sites-available/. Ich verwende immer nachfolgendes Template als Basis für meine PHP-Seiten. Die Konfiguration leitet HTTP Verbindungen automatisch auf verschlüsselte HTTPS Verbindungen um. Parameter wie der Domainname, Pfad zum SSL-Zertifikat und das Verzeichnis müssen natürlich für jede Website angepasst werden.
Die Konfiguration besteht aus zwei server Blöcken. Einer für Port 80 (HTTP) und einer für Port 443 (HTTPS).
Die Konfiguration des ersten server Blocks (HTTP)
listen gibt an auf welchen IP-Adressen und Ports die Website reagieren soll. 80 sagt aus, dass über alle verfügbaren IPv4 Adressen Verbindungen auf Port 80 akzeptiert werden sollen. [xxx:xxx:xxx::42]:80 sagt aus, dass die Website via IPv6 nur über die IP-Adresse xxx:xxx:xxx::42 und Port 80 erreichbar ist. Falls die Konfiguration als Standard verwendet werden soll, falls keine andere zur Anfrage passt, muss jeweils hinter der 80 noch default_server ergänzt werden.
server_name gibt die Domain an, für welche die Konfiguration gilt.
return leitet auf eine andere Website weiter. In diesem Fall mittels 301 (Dauerhaft Verschoben) auf die verschlüsselte Verbindung (HTTPS).
listen ist identisch wie für den ersten Block außer das der Block auf Port 443 hört und nicht 80.
server_name gibt wie beim ersten Block die Domain an, für welche die Konfiguration gilt.
ssl_certificate gibt den Pfad zum SSL Zertifikat der Website an.
ssl_certificate_key gibt den Pfad zum Privaten Schlüssel des SSL Zertifikats der Website an.
add_header Strict-Transport-Security sagt dem Client, dass er die Website nur über HTTPS aufrufen soll und dies auch für alle Subdomains gilt. An dieser Stelle muss man vorsichtig sein und prüfen ob dies auch wirklich für alle Subdomains gilt. Außerdem sagt max-age für wie lange diese Einstellung gilt. Innerhalb dieser Zeit leitet der Browser den Besucher automatisch auf HTTPS weiter. Das heißt es ist nicht einfach möglich HTTPS abzuschalten, sondern benötigt eine Vorlaufzeit. Der Wert 63072000 entspricht 2 Jahren. Zum Testen sollte ein niedriger Wert wie z.B. 300 (5 Minuten) verwendet werden, welcher langsam erhöht wird. Es kann auch beantragt werden diese Einstellung fest in die gängigsten Browser aufzunehmen. Details dazu gibt es auf der Website der HTST Preload List.
root gibt das Verzeichnis an, in dem die Website liegt.
index gibt den Dateinamen der Datei an, welche angezeigt werden soll, falls ein Verzeichnis als URL angegeben wurde. Damit dies geschieht muss eine Datei mit diesem Namen in dem angefragten Verzeichnis vorhanden sein.
location \ sagt, dass zuerst nach einer Datei mit dem angefragten Namen gesucht werden soll, anschließend ob ein Verzeichnis mit dem Namen existiert. Falls beides nicht existiert wird ein 404 Fehler zurückgegeben.
location ~ \.php$ leitet PHP-Dateien an den Interpreter weiter.
server {
listen 80;
listen [xxx:xxx:xxx::42]:80;
server_name example.com;
return 301 https://$server_name$request_uri;
}
server {
listen 443 ssl;
listen [xxx:xxx:xxx::42]:443 ssl;
server_name example.com;
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
add_header Strict-Transport-Security "max-age=63072000; includeSubdomains;";
root /var/www/com.example;
index index.php;
location / {
# First attempt to serve request as file, then
# as directory, then fall back to displaying a 404.
try_files $uri $uri/ =404;
}
# pass the PHP scripts to FastCGI server
location ~ \.php$ {
include snippets/fastcgi-php.conf;
fastcgi_pass unix:/run/php/php7.0-fpm.sock;
}
# snippet for updating letsencrypt certificates
include snippets/certbot-webroot.conf;
}
Nun muss noch das Verzeichnis für die Webseitendaten erstellt werden.
$ sudo mkdir -p /var/www/com.example
Neue Seite aktivieren
Um die Konfiguration einer Seite im Verzeichnis /etc/nginx/sites-available/ zu aktivieren muss ein Symmetrischer Link zu dieser Datei im Verzeichnis /etc/nginx/sites-enabled angelegt werden.
Nachdem die Konfiguration wie oben beschrieben geändert wurde muss sie nur noch von nginx neu geladen werden. Bevor sie geladen wird sollte allerdings noch geprüft werden, ob sie Fehler enthält.
$ sudo nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
$ sudo /etc/init.d/nginx reload
[ ok ] Restarting nginx (via systemctl): nginx.service.
Nun kann noch die Seite des Qually Labs SSL Tests aufgerufen werden, welches die verwendete Sicherheitsverfahren und Algorithmen von Webservern prüft und bewertet. Wenn alles wie oben beschrieben konfiguriert wurde sollte die Bewertung A+ sein, was der Best möglichen Bewertung entspricht.
Let’s Encrypt stellt kostenfreie SSL Zertifikate aus, welche von den gängigen Betriebssystemen und Browsern akzeptiert werden. Diese sind jeweils nur 90 Tage gültig und müssen daher regelmäßig erneuert werden. Damit dies nicht immer manuell geschehen muss gibt es Tools welche diesen Vorgang automatisieren. Das offizielle Tool dafür istcertbot. In diesem Beitrag beschreibe ich wie unter Ubuntu Linux 16.04 Server mit nginx, certbot und dem webroot Plugin Zertifikate für Webseiten angefragt und automatisch erneuert werden können.