NGINX Web-Server / SSL-Absicherung / Self-Signed Certificates

Vertrauenssache – Interne SSL-Zertifikate (Self-Signed Certificates)

Im LAN werden oftmals SSL-Zertifikate zur Nutzung verschiedener Dienste benötigt. Oft bleibt hier nichts anderes übrig, als selbstsignierte Zertifikate zu verwenden. Diese Zertifikate erfüllen zwar aus technischer Sicht ihren Zweck, den Anwender bzw. Administrator stellen sie aber immer wieder vor lästige Probleme. Web-basierte Administrationsinterfaces von Geräten, Terminalsitzungen des RDP-Servers und vieles andere meldet dem Anwender mehr oder weniger regelmäßig, dass das selbst erzeugte Zertifikat nicht sicher wäre oder zumindest aus unsicherer Quelle stamme. Der User quittiert dies in der Regel einfach – vertrauensbildend ist dies jedoch nicht.

Durch den antrainierten Reflex, fragwürdige Zertifikate ohne Bedenken zu akzeptieren, können große Sicherheitsrisiken entstehen. Ein derart konditionierter User hinterfragt irgendwann auch im Internet nicht mehr die Gründe, weshalb ein Zertifikat als unsicher eingestuft wurde. Gerade dort ist es jedoch wichtig, auf sichere Vertrauensstellungen in den Verschlüsselungsketten zu achten.

Im LAN könnte man zum Ergebnis gelangen, dass eine verschlüsselte Übertragung vom User zum Server innerhalb der geschlossenen Infrastruktur vernachlässigt werden kann. Unter der Maßgabe, dass es sich um keine sehr komplexe Struktur handelt und auch der Anwenderkreis vertrauenswürdig ist, kann man dies unter Umständen bejahen. Allerdings fordern immer mehr Produkte eine Verschlüsselung ein. Atlassian Confluence, als Beispiel, gestattet beispielsweise die Nutzung bestimmter Features nur, wenn die Verbindungen verschlüsselt sind.

Zertifikatsketten

Ein SSL-Zertifikat (X.509) enthält in der Regel Informationen über den Namen des Inhabers, dessen öffentlichen Schlüssel, eine Gültigkeitsdauer sowie den Namen der Zertifizierungsstelle. Die Zertifizierungsstelle signiert diese Informationen mit ihrem privaten Schlüssel und bestätigt dadurch die Korrektheit der in dem Zertifikat enthaltenden Angaben. Das Zertifikat kann mit dem zugehörigen öffentlichen Schlüssel der Zertifizierungsstelle überprüft werden.

Damit ein SSL-Zertifikat als vertrauenswürdig eingestuft werden kann, sind bestimmte hierarchische Autoritäten notwendig. Zunächst baut das „Vertrauen“ innerhalb von SSL auf der Annahme auf, dass der Browser des Benutzers über Listen mit Zertifizierungsstellen (Root-CA) für SSL-Zertifikaten verfügen kann, deren ausgestellten Zertifikaten bedingungslos vertraut werden kann. Wird nun eine SSL-verschlüsselte Website aufgerufen, prüft der Browser das für die Verschlüsselung herangezogene Zertifikat auf Gültigkeit, zur Webadresse passende Referenz sowie den Herausgeber. Kann hierfür vom Zertifikat der entsprechende Öffentliche Schlüssel der entsprechenden Zertifizierungsstelle vorgewiesen werden (wurde es also von der Zertifizierungsstelle signiert) gilt das Host/“Webseiten“-Zertifikat als gültig – die Verschlüsselung ist intakt.

Präsentiert das Host-Zertifikat jedoch einen Herausgeber, den der PC bzw. Browser nicht kennt, meldet dieser zumindest einen Zertifikatsfehler. In der Regel kann der Anwender diesen Fehler jedoch übergehen und seine Aktivitäten auf der betroffenen Website fortsetzen. Es gibt jedoch Situationen, in denen dies nicht möglich ist – beispielsweise wenn Programme Zertifikate zur Authentifizierung nutzen.

Bei selbstsignierten Zertifikaten ist genau dies regelmäßig der Fall. Der entsprechende Dienst oder Server signiert sich sein Zertifikat selbst und alle Clients, die diesen Dienst in Anspruch nehmen wollen, kennen keine Root-CA zu diesem Zertifikat.

Eigene Root-CA für interne Zertifikate

Um diese Probleme zu umgehen, kann man sich eine eigene Zertifizierungsstelle bauen. Diese Root-CA wird beispielsweise innerhalb der Domäne oder eben auf allen Rechnern, die künftig Zertifikaten dieser CA vertrauen sollen, in die Liste der vertrauenswürdigen Herausgeber aufgenommen (s.u.).

OpenSSL zur Zertifikats-Generierung

OpenSSL bringt umfassende Werkzeuge mit, um eine eigene, kleine Certificate Authority (CA) betreiben zu können. Die Nutzung einer eigenen CA ist besonders dann sinnvoll, wenn mehrere Dienste über SSL/TLS kostenlos abgesichert werden sollen. Neben dem Nachteil, dass die eigene CA vor Benutzung zuerst auf den Clientrechnern bekannt gemacht werden muss, gibt es aber auch einen Vorteil: Mit einer CA unter der eigenen Kontrolle ist man im Zweifel auf der sicheren Seite: In den letzten Jahren wurden immer wieder Fälle bekannt, in denen große Certificate Authorities falsche Zertifikate ausgestellt haben. Es gibt Grund genug, die Vertrauenswürdigkeit großer CAs anzuzweifeln.

Mit dieser Anleitung werdet ihr in der Lage sein, beliebig viele Zertifikate für eure Dienste ausstellen zu können, die in jedem Browser als gültig erkannt werden, sofern vorher das Root-Zertifikat eurer CA importiert wurde.

Erstellt werden die Zertifikate auf einer Linux-Maschine mit, sofern OpenSSL noch nicht installiert ist, erfolgt als erstes die Installatione mit folgendem Befehl:

apt-get install openssl ca-certificates

Benötigte Zertifikate

# nginx-termini
ssl_certificate /path/to/signed_cert_plus_intermediates;
ssl_certificate_key /path/to/private_key;
ssl_trusted_certificate /path/to/root_CA_cert_plus_intermediates;

# letsencrypt-termini
ssl_certificate /etc/letsencrypt/live/mail.conigliaro.org/fullchain.pem
ssl_certificate_key /etc/letsencrypt/live/mail.conigliaro.org/privkey.pem
ssl_trusted_certificate /etc/letsencrypt/live/mail.conigliaro.org/chain.pem

Ein Stammzertifikat (Root-Zertifikat) mit zugehörigem privaten Schlüssel (Private Key) bilden die Bestandteile der Root Certificate Authority (ROOT-CA).

(1) Vorläufiger Speicher-Ort der Zertifikate erstellen und aufsuchen

mkdir /home/adm_tjeckel/ca
cd /home/adm_tjeckel/ca

(2) Private Key erstellen

Mit folgendem Befehl wird ein geheimer Private Key erzeugt:

openssl genrsa -aes256 -out myRootCA-key-aw.pem 4096

Der Key trägt den Namen "myRootCA-key-aw.pem" und hat eine Länge von 2048 Bit. Wer es besonders sicher haben will, kann auch eine Schlüssellänge von 4096 Bit angeben. Die Option "-aes256" führt dazu, dass der Key mit einem Passwort geschützt wird. Die Key-Datei der CA muss besonders gut geschützt werden. Ein Angreifer, der den Key in die Hände bekommt, kann beliebig gefälsche Zertifikate ausstellen, denen die Clients trauen. Die Verschlüsselung dieses Keys mit einem Passwort gibt zusätzlichen Schutz. Das gewünschte Passwort wird bei der Generierung abgefragt.

(3) Root-Zertifikat erstellen erstellen

Einen geheimen Key für die CA gibt es nun also schon – fehlt noch das Root-CA-Zertifikat, das von den Clients später importiert werden muss, damit die von der CA ausgestellten Zertifikate im Browser als gültig erkannt werden. Das Root-CA-Zertifikat "myCA-root-aw.pem" wird mit folgendem Befehl erzeugt: (ggf. wird das Passwort für den vorher erstellen Key abgefragt!)

openssl req -x509 -new -nodes -extensions v3_ca -key myRootCA-key-aw.pem -days 3650 -out myRootCA-pub-aw.pem -sha512

In diesem Fall wird die CA 3650 Tage (= 10 Jahre) lang gültig bleiben. Während der Generierung werden das Passwort für die CA und einige Attribute abgefragt (hier ein Beispiel):

Country Name (2 letter code) [AU]: DE
State or Province Name (full name) [Some-State]: Sachsen-Anhalt
Locality Name (eg, city)[]: Lutherstadt Eisleben
Organization Name (eg, company) [Internet Widgits Pty Ltd]: KV MSH
Organizational Unit Name (eg, section) []: JA-PSYD-QM
Common Name (eg, YOUR name) []: archiv-werkzeuge.de
Email Address []: thorsten.jeckel.lkmsh.de

So – geschafft! Wir haben nun zwei Dateien erzeugt, die unsere Root CA definieren: Den Private Key (myCA-key-aw.pem) und unser Root Zertifikat (myCA-root-aw.pem). Übrigens: Es spielt keine Rolle, ob der Private Key auf .pem oder .key endet. Genauso macht es keinen Unterschied, ob das Root Zertifikat auf .pem oder .cert endet. Die Speicherung erfolgt unabhängig von der Datei-Endung im PEM-Format.

(4) Zertifikats-Erstellung überprüfen

Ob das Zertifikat richtig erstellt wurde, kann man mit Hilfe von openssl überprüfen. Mit dem Befehl

openssl x509 -in myRootCA-pub-aw.pem -text -noout

werden alle im Zertifikat enthaltenen Informationen ausgegeben. Besonders wichtig ist dabei dieser Wert:

X509v3 Basic Constraints: critical
                CA:TRUE

Damit ein Rechner die selbst ausgestellten Zertifikate akzeptiert, muss auf diesem Rechner das Root-CA-Zertifikat (Public Key der CA) importiert worden sein. Die Root-CA-Datei ist "myRootCA-pub-aw.pem". Auf diese Weise wird das Root-CA-Zertifikat allen Diensten (Clients) bekannt gemacht, so dass diese später die selbssignierten Server-Zertifikate als gültige SSL-Zertifikate anerkennen.

Microsoft Windows

Microsoft Windows hat eine zentrale Zertifikatsverwaltung, die aber nicht so ganz einfach zu finden ist. Um sie zu verwenden startet man die "Windows Management Console" (mmc.exe) und fügt das Snap-in "Zertifikate" hinzu.

Um das selbst erstellte Zertifikat zu importieren benötigt man diese Verwaltung allerdings nicht. Es reicht aus, die Datei mit dem Zertifikat (myRootCA-pub-aw.pem) mit der rechten Maustaste anzuklicken und im Kontextmenü den Menüpunkt Zertifikat installieren aufzurufen. Es wird dann der "Zertifikatimport-Assistent" gestartet.

Im Assistenten wählt man auf der Startseite unter Speicherort die Einstellung "Lokaler Computer" aus und klickt den Weiter-Knopf an. Hierzu sind Administratorrechte nötig.

Auf der Folgeseite muss dann der passende Speicher für das Zertifikat ausgewählt werden.

Das Zertifikat muss zwingend im Speicher für "Vertrauenswürdige Stammzertifizierungsstellen" abgelegt werden.

Linux (Debian, Ubuntu)

Auf Linux-System muss das Zertifikat ebenfalls in den entsprechenden Zertifikatsspeicher kopiert werden. Unter der Debian und Ubuntu geht dies wie folgt:

sudo mkdir /usr/local/share/ca-certificates/extra
sudo cp /home/adm_tjeckel/ca/myRootCA-pub-aw.pem /usr/local/share/ca-certificates/extra/myRootCA-pub-aw.crt
sudo update-ca-certificates

Bei anderen Linuxsystemen dürfte das Verfahren ähnlich sein.

Mozilla Firefox / Thunderbird

Der Firefox Browser hat eine eigene Verwaltung für Stammzertifikate. Um ein neues Zertifikat zu importieren ruft man die Einstellungen auf und wählt den Unterpunkt Datenschutz & Sicherheit aus.

Ganz unten auf der Einstellungsseite befindet sich der Button Zertifikate anzeigen …. Klickt man diesen Button an erscheint ein Dialog mit mehreren Tabs. Dort wechselt man zunächst zum Tab Zertifizierungsstellen und klickt dann auf den Importieren Button. Es kann dann über einen Dateiauswahldialog das ROOT-CA-Zertifikat (myRootCA-pub-aw.pem) ausgewählt werden.

Im Bestätigungsdialog für das “Herunterladen des Zertifikats” muss noch die Option “Dieser CA vertrauen, um Websites zu identifizieren” selektiert und der Dialog mit OK verlassen werden.

Anschließend sollte sich das Zertifikat dann unter Zertifikatsstellen befinden.

Chromium / Google Chrome

"Einstellungen" ⇒ "Erweiterte Einstellungen anzeigen" (unten) ⇒ "HTTPS/SSL2 ⇒ "Zertifikate verwalten2 ⇒ "Zertifizierungsstellen" ⇒ "Importieren" ⇒ "myRootCA-pub-aw.pem" auswählen ⇒ "Diesem Zertifikat zur Identifizierung von Websites vertrauen"

iPhone / iOS

Die Installation auf einem iOS-Gerät (hier getestet iPhone 5 mit iOS 8.1.3) ist erstaunlich unkompliziert. Einfach die Datei "myRootCA-pub-aw.pem" als E-Mail-Anhang versenden, auf dem Mobiltelefon auswählen und installieren.

Android

Android ist der Grund, warum ich noch auf die Dienste von Anbietern wie StartSSL zurückgreifen muß. Offenbar ist es auf einem Android-Gerät ohne root-Zugang (hier: Nexus 7 2012, Stock Android 5.0.2) nicht möglich ein CA-Zertifikat systemweit zu installieren.

Insofern liefern die Browser, aber auch diverse Apps, welche auf meine Server-Dienste zugreifen eine entsprechende Warnung. Schlimmer noch: Unmittelbar nach der (unwirksamen) Installation als Benutzer-Zertifikat erscheint in der Mitteilungszentrale "Das Netzwerk wird möglicherweise überwacht".

Vorgehensweise

Nach der Erstellung und Verteilung des Stammzertifikats (ROOT-CA ⇒ Datei "myRootCA-pub-aw.pem") können jetzt beliebig viele Zertifikate für (Sub)Domains erstellt werden. Das Verfahren entspricht der allgemeinen Vorgehensweise für die Beantragung und Erstellung eines SSL-Zertifikats:

1. Zunächst werden ein privater Schlüssel erstellt
2. Im nächsten Schrit wird ein CSR (Certificate Signing Request) erstellt.
3. Aus dem CSR wird dann mit Hilfe des Stammzertifikats ein SLL-Zertifikat für die Domäne erstellt.
4. Dieses Zertifikat kann anschließend z.B. im Web Server konfiguriert werden.

Es gibt verschiedene Möglichkeiten den Schlüssel, den CSR und das Zertifikat zu erstellen. Dabei gibt es evtl. auch einfachere Varianten als das von mir getestete und beschriebene Verfahren. Die nach diesem Verfahren erstellten Zertifikate werden von allen getesteten Browsern (Chrome, Firefox, Edge) anstandslos akzeptiert. Insbesondere Chrome ist da sehr “sensibel”.

Schritt I - Privaten Schlüssel erzeugen

Grundlage ist immer ein privater Schlüssel. Wie auch bei der ROOT-CA wird ein Private Key erzeugt:

openssl genrsa -out archiv-werkzeuge-key.pem 4096

An dieser Stelle ein Passwort zu setzen ist in den meisten Fällen nicht besonders sinnvoll. Ein Webserver, der des Zertifikat verarbeitet, müsste bei jedem Start das Passwort abfragen. Das ist in der Praxis mehr lästig und hinderlich als nützlich. (⇒ Passwortfelder einfach leer lassen). Die Schlüssellänge wurde hier auf paranoide 4096 Bit gesetzt. 2048 sind auch okay ;)

Schritt II – Zertifikatsanforderungsskript (CSR – Certificate Signing Request) erzeugen

Im nächsten Schritt muss das Zertifikatsanforderungsscript erzeugt werden. Dies wird so gemacht: Nun wird eine Zertifikatsanfrage erstellt, bei der wieder einige Attribute abgefragt werden. Besonderheit ist hier: Das Feld „Common Name“ muss den Hostnamen des Servers tragen, für den es gültig sein soll. Soll z.B. die Verbindung zum Rechner mit der IP-Adresse "192.168.2.2" mit dem Zertifikat abgesichert werden, muss die IP-Adresse hier angegeben werden. Soll das Zertifikat dagegen für die Domain "archiv-werkzeuge" gelten, muss das ebenso eingetragen werden. Es ist auch möglich, sog. Wildcard-Zertifikate zu erstellen. Wird z.B. "*.archiv-werkzeuge.de" als Common Name angegeben, gilt das Zertifikat für alle Domains von "archiv-werkzeuge.de", also "login.archiv-werkzeuge.de", "start.archiv-werkzeuge.de" usw. – nicht aber für "archiv-werkzeuge.de" selbst. Das Challenge Passwort wird nicht gesetzt (leer lassen).

openssl req -new -key archiv-werkzeuge-key.pem -out archiv-werkzeuge-csr.pem -sha512

Schritt III – Das eigentliche SSL-Zertifikat erzeugen

Sobald die Zertifikatsanfrage "archiv-werkzeuge-csr.pem" fertiggestellt ist, kann sie von der ROOT-CA verarbeitet werden. Dabei entsteht der öffentliche Schlüssel (Public Key) zum angefragten SSL-Zertifikat. Dieser wird zusammen mit dem Private Key des Zertifikats für die Verschlüsselung benötigt.

Mit folgendem Befehl wird ein Public Key "archiv-werkzeuge-pub.pem" ausgestellt, der 3650 Tage (=10 Jahre) lang gültig ist:

openssl x509 -req -in archiv-werkzeuge-csr.pem -CA myRootCA-pub-aw.pem -CAkey myRootCA-key-aw.pem -CAcreateserial -out archiv-werkzeuge-pub.pem -days 3650 -sha512

(Das Passwort für die CA wird erneut abgefragt.) Die Zertifizierungsanfrage archiv-werkzeuge-csr.pem (intermediate certificate) kann gelöscht werden – sie wird nicht mehr benötigt. Übrig bleiben und Public Key des neuen Zertifikats (archiv-werkzeuge-key.pem und archiv-werkzeuge-pub.pem) sowie Private- und Public Key der CA (myRootCA-key-aw.pem und myRootCA-pub-aw.pem).

PEM-Datei Reihenfolge

Seit APACHE 2.4.8 ist SSLCertificateChainFile als deprecated markiert. Das heißt, dass nun Zertifikat und Zwischenzertifikat in einer gemeinsamen Datei gespeichert werden müssen und über die Direktive SSLCertificateFile geladen werden. Auch NGINX benötigt spezielle Bündel (s.u.)

Dabei ist die Reihenfolge wichtig. Eine solche Datei wird folgendermaßen erstellt:

Zertifikat (SSL-Zertifikat-Datei) und Zwischenzertifikat (=Intermediate-Zertifikat) (CSR – Certificate Signing Request - Datei)

[NGINX ⇒ ssl_certificate /path/to/signed_cert_plus_intermediates;] [LetsEncrypt ⇒ 'fullchain.pem']

    cat archiv-werkzeuge-pub.pem archiv-werkzeuge-csr.pem > archiv-werkzeuge-fullchain.pem

Ganz selten wird auch das Root der SSL-CA benötigt, das hängt dann einfach ganz am Ende dran:

Zertifikat (SSL-Zertifikat-Datei) und Root-Zwischenzertifikat und Root-Zertifikat

    cat archiv-werkzeuge-pub.pem  myRootCA-csr-aw.pem myRootCA-pub-aw.pem > archiv-werkzeuge-bundle.crt

Für den NGINX-Webserver werden folgende Dateien erstellt und kopiert:

Public Key der CA an die Public Key Datei des Zertifikats anhängen

[NGINX ⇒ ssl_certificate /path/to/signed_cert_plus_intermediates;] [LetsEncrypt ⇒ 'fullchain.pem']

    cat archiv-werkzeuge-pub.pem myRootCA-pub-aw.pem  > archiv-werkzeuge-fullchain.pem

chain.pem erstellen

[NGINX ⇒ ssl_trusted_certificate /path/to/root_CA_cert_plus_intermediates;] [LetsEncrypt ⇒ 'chain.pem']

    cp myRootCA-pub-aw.pem archiv-werkzeuge-chain.pem

alle benötigten Dateien in das "ssl"-Verzeichnis des NGINX-Servers kopieren

cp /home/adm_tjeckel/ca/archiv-werkzeuge-key.pem /etc/nginx/ssl/privkey.pem
cp /home/adm_tjeckel/ca/archiv-werkzeuge-fullchain.pem /etc/nginx/ssl/fullchain.pem
cp /home/adm_tjeckel/ca/archiv-werkzeuge-chain.pem /etc/nginx/ssl/chain.pem

Starten Sie den Webserver nginx und PHP neu:

service php7.4-fpm restart && service nginx restart

Für den Docker-Container "ONLYOFFICEDOCKER" sind die Dateien in folgendes Verzeichnis mit neuem Namen zu kopieren

mkdir -p /app/onlyoffice/DocumentServer/data/certs
cp /etc/nginx/ssl/privkey.pem /app/onlyoffice/DocumentServer/data/certs/onlyoffice.key
cp /etc/nginx/ssl/fullchain.pem /app/onlyoffice/DocumentServer/data/certs/onlyoffice.crt
cp /etc/ssl/certs/dhparam.pem /app/onlyoffice/DocumentServer/data/certs/dhparam.pem
chmod 400 /app/onlyoffice/DocumentServer/data/certs/onlyoffice.key

Diese Schritte müssen nach jeder Zertifikatserneuerung wiederholt werden.

Um das seit Nextcloud 18 integriert nutzbare Onlyoffice mit selbst signierten SSL-Zertifikaten betreiben zu können, müssen Sie nur das selbst signierte Zertifikat in Nextcloud importieren.

 sudo -u www-data php /var/www/10_NC_WERKSTATT/occ security:certificates:import /etc/nginx/ssl/chain.pem
sudo -u www-data php /var/www/10_NC_WERKSTATT/occ security:certificates:import /etc/nginx/ssl/fullchain.pem

Übersicht der Zertifizierungs-Dateien

Die Zertifikat-Dateien findet man anschließend im Verzeichnis /home/adm_tjeckel/ca:

Die Zertifikate nutzen

In der Webserver-Konfiguration müssen üblicherweise drei Zertifikatsdateien angegeben werden:

• Private Key des Zertifikats (zertifikat-key.pem)
• Public Key des Zertifikats (zertifikat-pub.pem)
• Public Key der CA (ca-root.pem)

Der Public Key der CA kann auch an die Public Key Datei des Zertifikats angehängt werden:

cat ca-root.pem >> zertifikat-pub.pem

Diese Integration ist immer dann nötig, wenn es keinen Parameter in der Konfiguration gibt, bei dem man das Rootzertifikat einer CA angeben kann – beim XMPP Server Prosody und beim Webserver Nginx ist das z.B. der Fall: Hier können nur Public- und Private Key des Zertifikats angegeben werden.

Falls notwendig werden die Zertifikate noch umbenannt, z.B.:

mv zertifikat-key.pem certificate-archiv-werkzeuge.key
mv zertifikat-pub.pem certificate-archiv-werkzeuge.crt
mv ca-root.pem ca-root-archiv-werkzeuge.pem

Und in das "ssl"-Verzeichnis des NGINX-Servers kopiert:

cp /home/tjeckel/ca/certificate-archiv-werkzeuge.key /etc/nginx/ssl/certificate-archiv-werkzeuge.key
cp /home/tjeckel/ca/certificate-archiv-werkzeuge.crt /etc/nginx/ssl/certificate-archiv-werkzeuge.crt
cp /home/tjeckel/ca/ca-root-archiv-werkzeuge.pem /etc/nginx/ssl/ca-root-archiv-werkzeuge.pem

Für den Docker-Container "ONLYOFFICEDOCKER" sind die Dateien in folgendes Verzeichnis mit neuem Namen zu kopieren:

cp /home/tjeckel/ca/certificate-archiv-werkzeuge.key /app/onlyoffice/DocumentServer/data/certs/onlyoffice.key
cp /home/tjeckel/ca/certificate-archiv-werkzeuge.crt /app/onlyoffice/DocumentServer/data/certs/onlyoffice.crt
cp /home/tjeckel/ca/ca-root-archiv-werkzeuge.pem /app/onlyoffice/DocumentServer/data/certs/ca-root-archiv-werkzeuge.pem

Diffie-Hellman-Parameter

Das soeben erzeugte SSL-Zertifikat ist der wichtigste Schritt, damit später sämtliche Verbindungen zur eigenen Cloud verschlüsselt ablaufen. Die Sicherheit dabei kann aber durch den Einsatz sog. Diffie-Hellman-Parameter weiter erhöht werden. Das Thema ist etwas komplexer, aber einfach ausgedrückt geht es hierbei um einen sicheren Schlüsselaustausch bei Verbindungsaufbau. Die Generierung der Parameter ist recht einfach.

Achtung: Auf schwächerer Hardware kann die Generierung hier einige Stunden dauern. Wer nicht so lange warten möchte, der kann auch einen Schlüssel mit „nur“ 2048 Bit errechnen lassen (die Zahl des zweiten Befehls gibt hierbei die Länge des Schlüssels in Bit an).

cd /etc/nginx/ssl
openssl dhparam -out /etc/nginx/ssl/dhparams.pem 4096

Zugriffsberechtigungen für Zertifikat-Dateien setzen

Die Zertifikat-Dateien sind natürlich schützenswert, daher sollten die Dateiberechtigungen angepasst werden, so dass nur noch der Besitzer der Dateien Lese- bzw. Schreibrechte hat:

chmod 600 /etc/nginx/ssl/dhparams.pem
chmod 600 /etc/nginx/ssl/certificate-archiv-werkzeuge.key
chmod 600 /etc/nginx/ssl/certificate-archiv-werkzeuge.crt
chmod 600 /etc/nginx/ssl/ca-root-archiv-werkzeuge.pem

Web-Server NGINX-Konfiguration anpassen

# Certificates used
ssl_certificate /etc/nginx/ssl/certificate-archiv-werkzeuge.key;
ssl_certificate_key /etc/nginx/ssl/certificate-archiv-werkzeuge.key;
  
# Not using TLSv1 will break:
#	Android <= 4.4.40
#	IE <= 10
#	IE mobile <=10
# Removing TLSv1.1 breaks nothing else!
# TLSv1.3 is not supported by most clients, but it should be enabled.
ssl_protocols TLSv1.2 TLSv1.3;
	
# Cipher suite from https://cipherli.st/
# Max. security, but lower compatibility 
ssl_ciphers 'ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384';
 
# Cipher suite from https://wiki.mozilla.org/Security/Server_Side_TLS
#ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256';
 
# (Modern) cipher suite from https://mozilla.github.io/server-side-tls/ssl-config-generator/
#ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256';
 
# Diffie-Hellman parameter for DHE ciphersuites, recommended 4096 bits
ssl_dhparam /etc/nginx/ssl/dhparams.pem;
  
# Use multiple curves.
# secp521r1: Not supported by Chrome
# secp384r1: Not supported by Android (DAVdroid)
ssl_ecdh_curve secp521r1:secp384r1:prime256v1;
 
# Server should determine the ciphers, not the client
ssl_prefer_server_ciphers on;
  
# OCSP Stapling
# fetch OCSP records from URL in ssl_certificate and cache them
ssl_stapling on;
ssl_stapling_verify on;
	
# This should be chain.pem
# See here: https://certbot.eff.org/docs/using.html
ssl_trusted_certificate /etc/nginx/ssl/ca-root-archiv-werkzeuge.pem;
	
resolver 192.168.178.1;
  
# SSL session handling
ssl_session_timeout 24h;
ssl_session_cache shared:SSL:50m;
ssl_session_tickets off;