Bevor ihr diese Zeilen in eueren server Teil euerer nginx Konfiguration ergänzt, stellt sicher bereits ein SSL Zertifikat zu haben und den Pfad dorthin anzupassen. Darüber hinaus solltet ihr auch einen Diffie-Hellmann Key erzeugen und den Pfad dorthin ebenfalls anzupassen.

Einen Diffie-Hellmann Key wird mit folgendem Befehl erzeugt (kann sehr lange dauern):
> cd /etc/ssl/private

> openssl dhparam -out dhparams.pem 2048

> chmod 600 dhparams.pem

Habt ihr nun ein SSL Zertifikat und einen eigene DH Key, so stellt nochmals sicher die Pfade in folgendem Snippet anzupassen – dann könnt ihr es in euerer nginx Server Directive einsetzen:

listen 443 ssl http2;
ssl    on;
add_header Strict-Transport-Security "max-age=63072000; includeSubdomains; preload";
ssl_ciphers 'ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!CAMELLIA:!DES:!MD5:!PSK:!RC4';
ssl_prefer_server_ciphers on;
ssl_session_cache shared:SSL:10m;
ssl_dhparam /etc/ssl/certs/dhparam.pem;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_certificate    /etc/letsencrypt/live/hilfreiche-server.tips/fullchain.pem;
ssl_certificate_key    /etc/letsencrypt/live/hilfreiche-server.tips/privkey.pem;

Google sind jedoch auch niedrige Ladezeiten wichtig, leider ist es jedoch so das eine HTTPS Verbindung per se mehr Rechenleistung benötigt um die Verbindung zum Browser zu verschlüsseln. Besonders aufgefallen ist mir der langsame SSL Handshake. Also der Abschnitt des Verbindungsaufbaus in dem sich Server und Browser auf eine Technologie einigen. Das lag an den zahlreichen unterstützen SSL Algorithmen. Manchmal ist halt doch weniger mehr.

Daher bietet mein nginx Webserver nun nur noch die SSL Algorithmen an die von Cloudflare empfohlen werden und somit konnte ich auch die Ladezeiten wieder verbessern:

ssl_protocols               TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers                 EECDH+CHACHA20:EECDH+CHACHA20-draft:EECDH+AES128:RSA+AES128:EECDH+AES256:RSA+AES256:EECDH+3DES:RSA+3DES:!MD5;
ssl_prefer_server_ciphers   on;

Diese Weiterleitung kann in NGINX sehr leicht erreicht werden. Es genügt folgenden Einzeiler in die Konfiguration aufzunehmen:

error_page 497 https://$host$request_uri;

Da der Aufwand hierfür etwas höher ist und die Zertifikatsbeantragung nicht automatisch durchgeführt werden kann, habe ich mich gegen Let’s Encrypt entschieden und ein Zertifikat gekauft. Mit ca. 20 Euro pro Jahr halten sich die Kosten hierfür auch in Grenzen.

# CSR (Certificate Signing Request) erstellen

Um ein Zertifikat beantragen zu können brauchen wir ein CSR. Dieses kann man auf einem beliebigen Linux Rechner leicht erstellen, dafür benötigt man nur das **openssl** Package:

openssl req -nodes -newkey rsa:2048 -sha256 -keyout ‚example_com.key‘ -out ‚example_com.csr‘ -subj ‚/CN=example.com/C=DE‘

Die hier verwendete Domain „example.com“ muss natürlich gegen die tatsächliche Domain getauscht werden.

Nun wird eine .csr Datei erstellt sowie eine .key Datei. Letzteres ist der private Schlüssel und sollte nicht rausgegeben, geschweige denn veröffentlicht werden.

# Zertifikat beantragen und einspielen

Mit dem CSR kann man nun bei einem Dienstleister seiner Wahl ein SSL Zertifikat beantragen. Hat man das Zertifikat, öffnet man den Sophos Webadmin, navigiert über „Objects“, „Identity“ zu „Certificate“ und wählt „Add“.
Im folgenden Bildschirm wählt man nun das Zertifikat und je nachdem in welchem Format das Zertifikat vorliegt das entsprechende Format. Auch der bei CSR erstellte private Schlüssel muss angegeben werden.

Nun kann das ganze gespeichert werden.

Abschließend muss das gerade hochgeladene Zertifikat noch aktiviert werden.Dazu navigieren wir zu „System“, „Administration“, „Settings“. Dort kann das neue Zertifikat ausgewählt werden.

Ich nutze das Zertifikat auch zum absichern meiner virtuellen Webserver in der Web Application Firewall. Hierfür muss das Zertifikat jeweils bei jeder Konfiguration hinterlegt werden.

In dieser Anleitung beschreibe ich wie nextCloud (der moderne nachfolger von Owncloud) auf einem frischen Debian Stretch (Debian 9) oder auch Debian Jessie (Debian 8) installiert wird. Dazu verwende ich nginx als Webserver, MySQL und php7. Warum nginx und php7? Dies Software Pakete sind auf hohe Performance ausgelegt und werden auch aktiv von den Entwicklern gepflegt. Dazu sichern wir unseren Webserver noch mit einem kostenlosen SSL Zertifikat von Lets Encrypt ab und konfigurieren nginx so dass es nur aktuelle Sicherheitseinstellungen verwendet und aktivieren zusätzlich HTTP/2. Damit haben wir ein modernes, sicheres und schnelles Setup das perfekt für nextCloud geeignet ist.

Diese Anleitung kann auch für einen Raspberry Pi verwendet werden.

Voraussetzungen
Als Basis gehe ich von einem frisch installiertem Debian 8 Jessie aus, auf das auch bereits die Domain die du verwenden möchtest zeigt.

Grundarbeiten
Bei neuen Servern kümmere ich mich zu aller erst immer um eine hübsche Prompt, da macht das arbeiten gleich mehr Spass. Das habe ich hier bereits beschrieben. Wer das nicht möchte kann diesen Schritt auch einfach überspringen.

Als nächstes kümmere ich mich darum dass das System auf den aktuellsten Stand ist

apt-get update && apt-get upgrade && apt-get dist-upgrade

Je nachdem mit welchem Texteditor man arbeiten möchte muss dieser nun installiert werden, in meinem Fall ist das vim:

apt-get install vim-nox

Nun richten wir die Paketquellen ein. Unter Debian bietet sich die Nutzung von dotdeb.org an, da dort alle benötigten Pakete in einer aktuellen Fassung vorliegen. Die Einbindung davon wird hier beschrieben, lässt sich aber auch ganz kurz so zusammenfassen:

Folgende zwei Zeilen müssen in die /etc/apt/sources.list Datei hinzugefügt werden:

deb http://packages.dotdeb.org jessie all
deb-src http://packages.dotdeb.org jessie all

Danach muss noch der Schlüssel der neuen Paketquelle in unser System eingespielt werden. Laden können wir den Schlüssel mit

wget https://www.dotdeb.org/dotdeb.gpg

Und einspielen mit

apt-key add dotdeb.gpg

Lets Encrypt
Nun kümmern wir uns um das kostenlose SSL Zertifikat. Das lässt sich am einfachsten mit dem **certbot** beantragen, jedoch müssen wir dazu die Backports in unseren Paketquellen aktivieren. Hierzu müssen wir noch einmal die /etc/apt/sources.list Datei um folgende Zeile erweitern:

deb http://ftp.debian.org/debian jessie-backports main

Jetzt müssen wir die Paketquellen neu auslesen

apt-get update

Und dann kann certbot installiert werden

apt-get install certbot -t jessie-backports

Für den nächsten Schritt ist es zwingend nötig das bereits eine Domain auf den Server zeigt. Denn nun beantragen wir das SSL Zertifikat von Let’s Encrypt:

certbot certonly

Dieser Befehl leitet durch die Zertifikatsbeantragung. Es muss eine Mailadresse und die entsprechende Domain eingetragen werden. Hat alles funktioniert, beendet sich certbot mit einer Erfolgsmeldung.

PHP7

PHP7 kann recht schnell installiert werden. Dazu führen wir einfach folgenden Befehl aus:

apt-get install php7.0-fpm php7.0-gd php7.0-mysql php7.0-curl php7.0-xml php7.0-zip php7.0-intl php7.0-mcrypt php7.0-mbstring php7.0-bz2

Dadurch wird php7 mit allen erforderlichen Erweiterungen installiert.

NGINX

Die Installation von nginx wird mit folgendem Befehl angestoßen:

apt-get install nginx

Als nächstes müssen wir nginx konfigurieren. Wir legen Wert darauf dass unser Webserver nur aktuelle Sicherheitsalgorythmen verwendet, daher müssen wir vorher noch kurz einen Diffie-Hellman Schlüssel erzeugen:

mkdir -p /etc/ssl/private
chmod 710 /etc/ssl/private
cd /etc/ssl/private
openssl dhparam -out dhparams.pem 2048
chmod 600 dhparams.pem

Nun zur eigentlichen Konfiguration des nginx. Dazu öffnen wir folgende Datei und ersetzen den Inhalt komplett: /etc/nginx/sites-enabled/default
Der neue Dateiinhalt: Link (dabei muss „deine.cloud“ durch deine Domain ersetzt werden)

Hat man die Datei entsprechend angepasst, kann nginx neu gestartet werden:

/etc/init.d/nginx restart

Unter deiner Domain sollte nextcloud nun bereits erreichbar sein. Jedoch müssen wir erst noch MySQL installieren, da wir für nextcloud eine Datenbank benötigen.

MYSQL

Installiert wird MySQL mit folgendem Befehl. Während der Installation wird man nach dem root Passwort gefragt welches man sich unbedingt merken/notieren sollte!

apt-get install mysql-server mysql-client

Als nächstes sichern wir die MySQL Installation ab

mysql_secure_installation

Nun brauchen wir noch einen eigenen Datenbank Benutzer und Datenbank für unsere Nextcloud Installation

Dazu loggen wir uns als root mit dem bei der Installation vergebenem Passwort ein:

mysql -u root -p

Zum Erstellen einer eigenen Datenbank namens „nextclouddb“ nutzen wir folgenden Befehl

create database nextclouddb;

Dann erstellen wir einen Benutzer den wir „nextclouduser“ nennen. Wichtig! „password“ müssen wir durch ein neues Passwort ersetzen.

create user 'nextclouduser'@'localhost' identified by 'password';

Zu letzt braucht der gerade erstellte Benutzer noch Berechtigungen auf die gerade erstellte Datenbank. Auch hier müssen wir das Passwort ersetzen.

grant all on nextclouddb.* to 'nextclouduser' identified by 'password';

Nun haben wir die Datenbank eingerichtet und können den MySQL Client schließen.

exit

Jetzt die eigentliche Nextcloud Installation

Wir sind fast fertig. Es muss nur noch nextcloud installiert werden, dazu laden wir uns die aktuelle Version von Nextcloud in unser Webserververzeichnis.

wget https://download.nextcloud.com/server/releases/nextcloud-13.0.0.zip

unzip nextcloud-13.0.0-zip

Die Dateien noch ins Webverzeichnis kopieren und wir können die Installation im Webbrowser starten.

Wer es noch nicht getan hat, kann über diese Seite Gitlab installieren. Vorraussetzung für die weiteren Schritte ist dass Gitlab isntalliert wurde und über Port 80 erreichbar ist.

Als nächstes installieren wir git, da wir das benötigen um den Lets Encrypt Client zu nutzen

cd /root  
git clone https://github.com/letsencrypt/letsencrypt

Bevor wir das Zertifikat beantragen können, wird noch eine Lets Encrypt Konfiguration erstellt in der wir alle wichtigen Daten definieren.

mkdir letsencrypt-config  
vi letsencrypt-config/gitlab.ini

Der Inhalt der Datei:

# Lets Encrypt Config für gitlab

# wir wollen den webroot Authenticator nutzen. 
authenticator = webroot
webroot-path = /var/www/letsencrypt

# die Domain unter der Gitlab aufrufbar ist
domains = gitlab.yourdomain.de

# die eigene Mailadresse mit der das Zertifikat beantragt wird
email = your@email.de

# wir wollen einen 4096 bit RSA key anstatt eines 2048 keys
rsa-key-size = 4096

Nun müssen wir noch das Verzeichnis anlegen dass für die webroot Authentifizierung verwendet wird

mkdir -p /var/www/letsencrypt

Als nächstes passen wir die gitlab Konfiguration an, damit diese unsere neuen Zertifikate nutzt. Dazu öffnen wir die Datei **/etc/gitlab/gitlab.rb** und ändern folgende Werte. Dabei muss auch darauf geachtet werden dass die entsprechenden Zeilen nicht auskommentiert sind.

nginx['enable'] = true
nginx['redirect_http_to_https'] = true
nginx['ssl_certificate']= "/etc/letsencrypt/live/gitlab.yourdomain.de/fullchain.pem"
nginx['ssl_certificate_key'] = "/etc/letsencrypt/live/gitlab.yourdomain.de/privkey.pem"

Folgende Zeile muss neu eingefügt werden

nginx['custom_gitlab_server_config']="location ^~ /.well-known {\n alias /var/www/letsencrypt/.well-known;\n}\n"

Damit die SSL Beantragung funktioniert muss Gitlab nun erstmal rekonfiguriert werden.

gitlab-ctl reconfigure

Als nächstes nutzen wir die vorhin angelegte Lets Encrypt Konfiguration um das SSL Zertfikat zu erstellen

/root/letsencrypt/letsencrypt-auto certonly -c /root/letsencrypt-config/gitlab.ini

Beim ersten Aufruf werden vor der eigentlichen SSL Beantragung noch evtl. fehlende Abhänigkeiten installiert.

Nun können wir wieder die gitlab Konfiguration unter /etc/gitlab/gitlab.rb öffnen und die URL auf https ändern.

external_url 'https://gitlab.yourdomain.de'

Das war es auch schon. Gitlab muss abschließen noch rekonfiguriert werden:

gitlab-ctl reconfigure

Ab nun ist die Gitlab Installation unter https erreichbar.

Lets Encrypt Zertifikate sind immer nur 90 Tage gültig. Damit das Zertifikat jeden Monat automatisch erneuert wird, richten wir einen Cronjob ein der sich darum kümmert:

0 0 1 * * /root/.local/share/letsencrypt/bin/letsencrypt certonly -c /root/letsencrypt-config/gitlab.ini --renew-by-default

Vorraussetzung ist ein vom Internet erreichbarer Port 80 eueres Webservers sowie ein installiertes git. Letzteres kann per „**apt-get install git**“ einfach nachinstalliert werden.

Ist das erledigt wechseln wir in das root Verzeichnis

cd /root/

und clonen das acme Repository

git clone https://github.com/Neilpang/acme.sh.git acme-master

nun erstellen wir das Verzeichnis in dem die Konfiguration abgelegt wird und wechseln in das gerade geclonte Verzeichnis

mkdir /etc/pve/.le
cd /root/acme-master

Mit folgendem Befehl legen wir unsere Konfiguration an. Hierbei müssen wir unsere E-Mail Adresse angeben über die wir zukünftig benachrichtigt werden wenn das Zertifikat abläuft

./acme.sh --install --accountconf /etc/pve/.le/account.conf --accountkey /etc/pve/.le/account.key --accountemail "meine@email.com"

Nun können wir testweise versuchen das Zertifikat zu beantragen. Da es ein wöchentliches Limit gibt wie häufig ein Zertifikat beantragt werden darf, empiehlt es sich zuerst nur einen Testantrag zu machen. Hier muss die von dir verwendete Domain eingesetzt werden:

./acme.sh --issue --standalone --keypath /etc/pve/local/pveproxy-ssl.key --fullchainpath /etc/pve/local/pveproxy-ssl.pem --reloadcmd "systemctl restart pveproxy" -d $DOMAIN --test

Sollte das funktioniert haben können wir den gleichen Befehl nochmal abschicken, diesmal aber statt mit dem –test Flag mit einem –force Flag. So wird sichergestellt dass das gerade testweise Zertifikat durch das neue richtige Zertifikat ersetzt wird, obowhl es noch nicht abgelaufen ist:

./acme.sh --issue --standalone --keypath /etc/pve/local/pveproxy-ssl.key --fullchainpath /etc/pve/local/pveproxy-ssl.pem --reloadcmd "systemctl restart pveproxy" -d $DOMAIN --force

Das war es auch schon. Die Weboberfläche von Proxmox ist nun mit einem gültigem Zertifikat abgesichert. Außerdem wurde ein Cronjob angelegt der das Zertifikat zukünftig automatisch erneuert:

0 0 * * * "/root/.acme.sh"/acme.sh --cron --home "/root/.acme.sh" > /dev/null

Folgende Konfiguration wird in **/etc/postfix/main.cf** am Ende der Datei eingefügt:

# Aktiviert TLS
smtp_use_tls                 = yes
# Aktiviert das Logging
smtp_tls_loglevel            = 1
# Unverschluesselte Verbindung erlauben (may = entscheidet der Client)
smtp_tls_security_level      = may
# Pfade zu den Keys
smtp_tls_cert_file           = /etc/ssl/certfile.crt
smtp_tls_key_file            = /etc/ssl/keyfile.key
smtp_tls_CAfile              = /etc/ssl/cabundle.pem
smtp_tls_note_starttls_offer = yes
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtp_tls_note_starttls_offer = yes
smtp_tls_CApath = /etc/ssl/certs
smtp_tls_exclude_ciphers = RC4, aNULL

smtp_tls_ciphers = high
smtp_tls_exclude_ciphers = aNULL, eNULL, EXPORT, DES, RC4, MD5, PSK, aECDH, EDH-DSS-DES-CBC3-SHA, EDH-RSA-DES-CDB3-SHA, KRB5-DES, CBC3-SHA
smtp_tls_loglevel = 1
smtp_tls_note_starttls_offer = yes
smtp_tls_protocols = !SSLv2, !SSLv3

smtpd_tls_ciphers = high
smtpd_tls_eecdh_grade = strong
smtpd_tls_exclude_ciphers = aNULL, eNULL, EXPORT, DES, RC4, MD5, PSK, aECDH, EDH-DSS-DES-CBC3-SHA, EDH-RSA-DES-CDB3-SHA, KRB5-DES, CBC3-SHA
smtpd_tls_mandatory_ciphers= high
smtpd_tls_mandatory_protocols = !SSLv2,!SSLv3
smtpd_tls_protocols = !SSLv2,!SSLv3

Danach noch den Mailserver neustarten:
> /etc/init.d/postfix restart

Testen kann man die neue Konfiguration z.b. mit dieser Webseite: