Ein Howto vom 01. und 02.01.2018
Worum geht es?
Wer kennt die Situation nicht, man möchte gern ein Programm ausprobieren oder für eine Interessengruppe, einen kleinen Verein oder schlicht ein zentrales Speichermedium zur Verfügung stellen, ohne auf ein kommerzielles Angebot eines Providers zurückgreifen zu müssen. Die Sicherheit solcher Systeme wird immer besser und die Möglichkeiten der Absicherung sind auch mit einfachen Mitteln gegeben. Solche Systeme werden i.d.R. von einem Webserver ins Internet ausgeliefert, dessen Zugriffe mit SSL abgesichert sein sollten. Dafür sind normalerweise Zertifikate notwendig, die in den ausgelieferten Browsern der Betriebssysteme bereits bekannt sind und von beglaubigten Zertifizierungsstellen ausgegeben werden. Diese arbeiten allerdings nicht kostenlos und haben deshalb ihre Zertifikate, mit denen Sie die abgesicherten Seiten ihrer Kunden signiert haben, in den Browsern zur Verfügung gestellt. So ist es möglich diese Seiten anzusurfen und ohne Probleme eine abgesicherte Verbindung aufbauen zu können. Die Kunden haben ihr Zertifikat jeweils bei der Zertifizierungsstelle beglaubigen lassen und ermöglichen damit die Auslieferung eines ganzen Zertifikatspools mit jedem Browser. Die Referenzzertifikate gleichen beim Aufruf einer abgesicherten Seite die Beglaubigung ab und bestätigen damit, daß die Seite dem zertifizierten Benutzer gehört. Aber es ist nicht nur die Authentifizierung des Webseitenbetreibers erwünscht, sondern auch gleichzeitig eine Absicherung der Datenübertragung gegen “Abhören”. Ist eine solche Verbindung nicht SSL oder jetzt nach aktuellem Standard mit TLS abgesichert, lassen sich Eingaben auf einer Webseite “abhören” und mißbrauchen. Das betrifft insbesondere Paßwörtereingaben oder die Eingabe von Kreditkartennummern und ähnlich sensiblen Daten, die es zu schützen gilt.
Auf diese Weise können auch eMail-Server abgesichert und Datenpakete verschlüsselt werden, die einem unberechtigten Zugriff damit entzogen werden.
Kommerzielle Zertifikate kosten Geld. Für ein Unternehmen mag das als Betriebskosten nicht so ins Gewicht fallen. Für einen kleinen Verein oder eine Interessengruppe sind feste Kosten eine Belastung.
Es gibt drei Arten von Zertifikaten. Extendet Validation Zertifikate (EV), Corporate Zertifikate und kostenlose Zertifikate. Wobei die kostenlosen Zertifikate von einigen Zertifizierern mittlerweile angeboten werden und die meistens geringe Laufzeiten haben oder selbst generierte Zertifikate, die allerdings den Browsern nicht bekannt sind und daher eine Fehlermeldung produzieren. Die Corporate Zertifikate geben an, daß sie für eine bestimmte Webseite beglaubigt wurden und die EV Zertifikate bestätigen eine intensive Überprüfung des Antragstellers. Bei Firmen geht das bis zum Vergleich des Handelsregistereintrags und der Adreßüberprüfung des Standortes.
Für eine überschaubare Anzahl Benutzer ist es noch vertretbar im privaten Rahmen eigene Zertifikate zu erzeugen und zu verwenden. Die Fehlermeldung des Browsers läßt sich durch ein erzwungenes Importieren des Zertifikates abstellen, womit der Schutz der Übertragung gegeben ist und die Fehlermeldung durch den Import abgestellt wurde. Da bei solchen Zertifikaten der Ersteller i.d.R. bekannt ist und ihm vertraut wird, ist das die kostengünstigste Variante einen Webserver mit SSL oder TLS abzusichern.
Der Weg dahin soll hier beschrieben werden.
Was soll am Ende dieses Textes gewonnen sein?
Für eine Arbeitsgruppe in meinem Bekanntenkreis soll eine Plattform zur Zusammearbeit geschaffen werden, auf der Notizen, Kalender und Dateien verwaltet werden können. Da die Gruppenmitglieder über die gesamte Bundesrepublik verstreut sind, ist dies die praktikabelste Lösung. Erweiterungen des Funktionsumfanges der Software sind von Vorteil und die Kosten sollten im Rahmen bleiben.
Kommerzielle Collaboration-Software ist teuer und aufwendig zu installieren. Genannt werden kann hier Lotus Notes, Microsoft Exchange-Server und einige kleinere individuelle Softwarelösungen. Einige Cloud-Lösungen wie OwnCloud oder NextCloud sind hier oft ebenfalls genannt, obwohl die eher als externe über das Internet erreichbare “Festplatte” angesehen werden, weil lange Zeit nur passive Elemente vorhanden waren. Das ändert sich bei NextCloud gerade gewaltig, denn durch Pluigins werden die funktionalen Möglichkeiten erheblich erweitert. Im Vollausbau können Veränderungen an Dokumenten sogar auf der Plattform zusammen vorgenommen werden. Das sind Attribute einer vollständigen Collaboration Software.
GroupOffice der holländischen Firma Intermesh sticht mit solchen Angeboten auch aus dem Angebot heraus. Grundfunktionen sind kostenlos. Erst die komfortableren und aktiven Funktionen sind kostenpflichtig und werden ausschließlich über einen Lizenzschlüssel freigeschaltet.
Aus diesem Grund wurde sich für NextCloud entschieden, weil es kostenlos ausprobiert werden und bei Bedarf mit Plug-ins um wesentliche Funktionen erweitert werden kann.
Dafür soll ein LAMP-Server auf Basis Debian eingerichtet werden, der die NextCloud beheimatet. Der dafür bereitgestellt Rechner war eine ausgediente Workstation mit DualCore Prozessor und 4 GB Hauptspeicher. Der Rechner wird hinter einem Router im Heimnetz betrieben und muß den Zugriff vom Internet aus zulassen. Im Router ist somit eine Freigabe auf den Port 443 zu installieren. Die Zugriffe sollten durch SSL, also HTTPS abgesichert sein.
Technische Voraussetzungen
Gestartet wurde mit einer Debian 9.3 Installation mit einem Apache 2.4 Webserver, einer MariaDB 10.1.26, der Version PHP 7.0.19-1 und OpenSSL Version 1.1.0f.
Notiz: Die Kommandos hier sind logischerweise als root einzugeben. Kopieren und in eine Putty-Konsole einfügen funktioniert nicht. Ich mußte beim zweiten Versuch die Kommandos auch alle neuschreiben : – )
Wird der Webserver nicht bei der Debian Installation über tasksel schon gleich mit installiert, ist es erforderlich ihn mit
# apt-get install apache2
nachzuinstallieren. Gleiches gilt für die MariaDB,
# apt-get install mariadb-server mariadb-client
die als Substitution für die ehemals mysql Datenbank zum Einsatz kommt. I.d.R. wird eine veraltete PHP Version installiert, die nach einer gewissen Zeit nicht mehr unterstützt wird. Deshalb ist es empfehlenswert mit php –v zu überprüfen welche Version installiert ist, und sollte noch kein PHP installiert sein, gleich eine aktuelle Version dafür zu nehmen. Ist bereits eine Version installiert, ist hier eine Anleitung wie das Upgrade auf eine aktuelle PHP Version durchgeführt werden kann.
Damit wir überhaupt SSL Zertifikate erstellen können, müssen wir OpenSSL installieren:
# apt-get install openssl
Benötigte Ordner erstellen
Das Zertifikatsverzeichnis von Debian ist
# /etc/ssl/certs
in dem ein weiteres Verzeichnis angelegt wird, worin der zu erzeugende Schlüssel und das Zertifikat verwaltet wird. Das Verzeichnis ist später dem Webserver bekannt zu machen, damit er es berücksichtigen kann.
# cd /etc/ssl
# mkdir localcert
# cd localcert
Es ist zudem unser Arbeitsverzeichnis, wenn wir Zertifikate erstellen und signieren.
Erstellen eines Schlüssels zum Signieren
Der Schlüssel, mit dem zum Schluß das Zertifikat signiert werden muß, wird hier erst einmal erzeugt, denn er ist auch für die Erzeugung der Zertifikatsanfrage notwendig. Der Schlüssel kann mit einem Paßwort geschützt werden, was unter Sicherheitsgesichtspunkten sicherlich sinnvoll ist, aber für einen Schlüssel, der im Webserver nach einem Systemstart erst mit einem Paßwort geöffnet werden muß ist das zwar sicher aber unpraktikabel, weshalb es hier weggelassen wird. Der Schlüssel heißt in diesem Fall “nextcloud.key” und wird in Ihrer Installation sicherlich einen anderen Namen benötigen. Sie legen hier den Namen fest.
# openssl genpkey –algorithm RSA –pkeyopt rsa_keygen_bits:4096 –out nextcloud.key
Dieser Schlüssel ist sehr sorgfältig zu behandeln und zu sichern. Ohne diesen Schlüssel kann man keine Zertifikate signieren oder erneuern. Er sollte nur von root gelesen werden können. Würde der Schlüssel korrumpiert werden, müßten alle Zertifikate zurückgezogen werden und man müßte von vorne anfangen.
Output
# openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:4096 -out nextcloud.key
…………………………………++
………………………………………………………………………………………………………………………..++
Die Verzeichnisauflistung zeigt
# ls -al
insgesamt 4
drwxr-xr-x 1 root root 30 Jan 1 21:30 .
drwxr-xr-x 1 root root 18 Jan 1 21:29 ..
–rw– – – – – – – 1 root root 3268 Jan 1 21:30 nextcloud.key
zeigt die Editierbarkeit des Schlüssels, die entfernt wird mit
# chmod 400 nextcloud.key
wonach der Status so aussieht
–r– – – – – – – – 1 root root 3268 Jan 2 21:30 nextcloud.key
Erstellen der Zertifikat Request Datei
Die Zertifikat Request Datei oder auch csr Datei (Certificate Signing Request) ist die Datei, die nach der Erzeugung alle Informationen des Zertifikates beinhaltet und die anschließend mit dem privaten Schlüssel signiert wird und damit zum Zertifikat (crt) wird.
Der Kommandoaufruf dafür ist
# openssl req –new –sha256 –key nextcloud.key –out nextcloud.csr
Output
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]: Bremen
Locality Name (eg, city) []: Bremen
Organization Name (eg, company) []: itc-bremen
Organizational Unit Name (eg, section) []: ca
Common Name (e.g. server FQDN or YOUR name) []: nextcloud
Email Address []: ca@itc-bremen.com
Please enter the following ‘extra’ attributes to be sent with your certificate request
A challenge password []: .
An optional company name []: .
Nicht vergessen bei challenge password und optional company name einen Punkt zu setzen, damit die Felder im Zertifikat leer bleiben.
Die entstandene Datei ist
-rw – r – – r – – 1 root root 1744 Jan 1 21:40 nextcloud.csr
Die erzeugte Datei soll nur root zugänglich sein und wird deshalb sehr restriktiv berechtigt.
# chmod 644 /etc/ssl/localcert/nextcloud.csr
Erstellen der Zertifikats Datei
Nun wird die csr Datei mit dem Schlüssel signiert, um sie verwenden zu können.
# openssl x509 -req -days 730 -in nextcloud.csr -signkey nextcloud.key -sha256 -out nextcloud.pem
Output
Signature ok
subject=C = DE, ST = Bremen, L = Bremen, O = itc-bremen, OU = ca,
CN = nextcloud, emailAddress = ca@itc-bremen.com
Getting Private key
Mit 730 Tagen Laufzeit ist das Zertifikat 2 Jahre gültig bis es erneuert werden muß. Es sind aber auch längere Laufzeiten möglich.
Benötigte Zertifikats-Dateien und deren Überprüfung
Die im gültigen Zertifikatsverzeichnis liegenden Dateien sind
–r– – – – – – – – 1 root root 3268 Jan 2 21:30 nextcloud.key (private key)
-rw-r–r– 1 root root 1744 Jan 2 21:40 nextcloud.csr (Zertifikat unsig)
-rw-r–r– 1 root root 1744 Jan 2 21:40 nextcloud.pem (Zertifikat sig)
Anstatt der pem Datei kann es auch eine crt Datei sein. pem ist das Suffix für privacy enhanced mail, ein Protokoll, das sich nicht durchgesetzt hat. In beiden Dateien sind jedoch dieselben Informationen enthalten. Einige Browser erkennen wegen des Suffix crt die Datei sogar als Zertifikat an.
Eine Überprüfung der Eintragungen stellt dann die ordnungsgemäße Erstellung des selbst erzeugten und selbst signierten Zertifikates fest.
Private Key anzeigen:
# cat nextcloud.key
Der Privat Key sieht so aus:
Der Pivate Key sollte niemandem gezeigt werden, da auch aus der Textdatei ein Schlüssel erzeugt werden kann. Geschieht dies trotzdem, ist der Schlüssel korrumpiert und sollte nicht mehr eingesetzt, also erneutert werden.
Das Zertifikat anzeigen:
# cat nextcloud.crt oder nextcloud.pem
—–BEGIN CERTIFICATE—–
MIIDrTCCAxagAwIBAgIBADANBgkqhkiG9w0BAQQFADCBnDEbMBkGA1UEChMSVGhl
IFNhbXBsZSBDb21wYW55MRQwEgYDVQQLEwtDQSBEaXZpc2lvbjEcMBoGCSqGSIb3
DQEJARYNY2FAc2FtcGxlLmNvbTETMBEGA1UEBxMKTWV0cm9wb2xpczERMA8GA1UE
. . . [ große Teile entfernt ]
FS5G13pW2ZnAlSdTkSTKkE5wGZ1RYSfyiEKXb+uOKhDN9LnajDzaMPkNDU2NDXDz
SqHk9ZiE1boQaMzjNLu+KabTLpmL9uXvFA/i+gdenFHv
—–END CERTIFICATE—–
Um die Inhalte des Zertifikates auszulesen muß mit dem Kommando openssl der Inhalt in einen Text umgeleitet werden, um ihn im Klartext lesen zu können.
# openssl x509 -text -in nextcloud.crt
Output
Certificate:
Data:
Version: 1 (0x0)
Serial Number: c7:15:9e:10:bb:4f:a7:6f
Signature Algorithm: sha256WithRSAEncryption
Issuer: C = DE, ST = Bremen, L = Bremen, O = itc-bremen, OU = ca, CN = nextcloud, emailAddress = ca@itc-bremen.com
Validity
Not Before: Jan 2 20:40:06 2018 GMT
Not After : Jan 2 20:40:06 2020 GMT
Subject: C = DE, ST = Bremen, L = Bremen, O = itc-bremen, OU = ca, CN = nextcloud, emailAddress = ca@itc-bremen.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (4096 bit)
Modulus:
00:b0:4f:f6:7b:f5:46:26:78:c2:21:9b:66:dc:f7:
de:f0:d3:ed:fe:cd:f8:0b:03:49:7b:b2:82:a6:45:
. . . [ wesentliche Teile gelöscht ]
0e:1c:a5:aa:31:43:3e:85:9d:fd:00:3f:1c:b6:73:
95:88:89
Exponent: 65537 (0x10001)
Signature Algorithm: sha256WithRSAEncryption
27:3c:99:6a:55:de:1b:90:37:f3:43:07:fa:2d:10:a8:3e:4d:
61:e3:66:5d:f0:33:81:0d:25:67:19:a3:35:8e:dd:85:bc:f4:
. . . [ wesentliche Teile gelöscht ]
a1:d2:d4:d1:e8:77:c6:8f:d0:a1:e4:fc:6c:9e:2a:ee:dc:77:
6e:a7:dc:f9:c2:00:82:e7
Server Zertifikat und Key Installieren
Nun sind alle Dateien erzeugt, die notwendig sind. Sie müssen nun dem Webserver bekannt gemacht werden, damit er sie verwenden kann. Dies geschieht in den vorbereiteten Scripten des Apache 2.4, die im Verzeichnis
# /etc/apache2/sites-available
zu finden sind. Die beiden default Dateien
-rw-r–r– 1 root root 1332 Sep 19 20:56 000-default.conf
-rw-r–r– 1 root root 6338 Jan 2 02:49 default-ssl.conf
in denen in 000-default.conf die Zugriffe über den Standard-Port 80 geregelt werden und in default-ssl.conf die Einstellungen für die virtuellen Hosts in denen die verschlüsselten Verbindungen eingestellt und verwaltet werden. Die einfachste Lösung ist die default-ssl.conf zu sichern indem sie kopiert und umbenannt wird mit
cp default-ssl.conf default-ssl.conf_original
und die default Datei an die nun benötigten Einträge anzupassen. Einige Einträge müssen geändert und ergänzt werden, damit der Webserver seine Arbeit erledigen kann. Das sind im Wesentlichen die Einträge für die zu schützende Seite, die bekannt zu machen ist, sowie die Umleitung der Anfragen an den ungeschützten Port 80 auf den sicheren Port 443.
Der Kopf der Datei sieht dann so aus:
<IfModule mod_ssl.c>
<VirtualHost _default_:443>
ServerAdmin webmaster@localhost
ServerName 192.168.0.200
DocumentRoot /var/www/html
<IfModule mod_rewrite.c> (dies ist die Umleitung auf Port 443)
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
</IfModule>
# Available loglevels: trace8, …, trace1, debug, info, notice, warn,
# error, crit, alert, emerg.
# It is also possible to configure the loglevel for particular
. . .
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
SSLEngine on
SSLCertificateFile /etc/ssl/localcert/nextcloud.pem
SSLCertificateKeyFile /etc/ssl/localcert/nextcloud.key
SSLProtocol All -SSLv2 -SSLv3
. . .
</VirtualHost>
</IfModule>
Die letzte Konfigurationszeile gibt an, daß ALLE Verschlüsselungsprotokolle zu verarbeiten sind, jedoch die sicherheitsanfälligen Protokolle von SSLVersion2 und SSLVersion3 nicht. In einigen Fällen kann es sein, daß ein erforderlicher Restart des Apache2 dadurch verhindert wird. Dann sollte die Zeile auskommentiert werden.
Die fertige Konfigurationsdatei default-ssl.conf ist zweckmäßig umzubenennen (in diesem Fall ‘nextcloud’) und muß in das sites-enabled Verzeichnis kopiert werden, in der sie vom Webserver gefunden wird und verarbeitet werden kann. Um nicht verschiedene Dateien zu bekommen, die als Fehlerquelle inkonsistent sein können, wird ein symbolischer Link gelegt. Dazu wird in das Verzeichnis gewechselt
# cd /etc/apache2/sites-enabled
# ln -s /etc/apache2/sites-available nextcloud.conf
Das Ergebnis sieht dann so aus
# nextcloud –> /etc/apache2/sites-available/
Webserver die zu lauschenden Ports mitteilen
Dem Webserver muß noch vermittelt werden, auf welchen Ports er auf Anfragen warten soll. Im Verzeichnis
# /etc/apache2
liegt die Datei
# ports.conf
die angibt, daß wenn verschlüsselte Anfragen über das Modul SSL kommen oder das Modul TLS der Port 443 zu bedienen ist. Alle andere Anfragen werden an Port 80 weitergeleitet. Das Kommando cat listet die Datei auf.
# cat ports.conf
# If you just change the port or add more ports here,
# you will likely also have to change the VirtualHost
# statement in
# /etc/apache2/sites-enabled/000-default.conf
<IfModule ssl_module>
Listen 443
</IfModule>
<IfModule mod_gnutls.c>
Listen 443
</IfModule>
Listen 80
# vim: syntax=apache ts=4 sw=4 sts=4 sr noet
SSL auf dem Webserver einschalten
Das Modul mod_ssl ist bei Debian und Ubuntu von haus aus installiert und muß eingeschaltet werden, um ssl zu aktivieren. Konfigurationsänderungen sind dem Webserver durch Neustart mitzuteilen:
# a2enmod ssl
# service apache2 restart
Ob alles geklappt hat ist an der grünen Meldung des Apache2 zu sehen, die mittels
# systemctl status apache2
aufzurufen ist.
Die Webseite für den Webserver aktiv schalten
Da die Webseite in einer eigenen Konfigurationsdatei konfiguriert wurde, muß diese Datei aktiviert werden.
# a2ensite /etc/apache2/sites-enabled/nextcloud
# service apache2 restart
Das müßte soweit alles sein, das zum Betrieb der Seite auf dem Server erforderlich ist. Nun ist nur noch der Zugriff mittels Browser und das Übernehmen des eigenen Zertifikats notwendig, das hier beschrieben ist.
