Zertifikate und HTTPS

Nach der grundlegenden Installation ergänzt man HTTPS für die Testumgebung. Die Erstellung des Zertifikats, seine Prüfung und die passende Apache-Site bleiben als zusammenhängender Ablauf auf dieser Seite.

TLS-Zertifikat für die Testumgebung

Ein selbstsigniertes Zertifikat verschlüsselt die Verbindung, wird aber von Browsern nicht automatisch als vertrauenswürdig erkannt. In dieser Übung werden nc.home.arpa und beispielhaft die IP-Adresse 192.168.xx.xxx verwendet. Beide Werte durch den tatsächlichen Namen und die Adresse des Testservers ersetzen. Der Name muss auf den Geräten auflösbar sein, beispielsweise über einen passenden lokalen DNS- oder Hosts-Eintrag.

Zertifikat mit passenden Namenseinträgen erstellen

Die Subject Alternative Names (SAN) müssen zu den Adressen passen, über die Nextcloud aufgerufen wird. In einer Root-Shell erzeugt man Schlüssel und Zertifikat direkt an den vorgesehenen Orten:

openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 \
  -keyout /etc/ssl/private/nextcloud.key \
  -out /etc/ssl/certs/nextcloud.crt \
  -subj "/CN=nc.home.arpa" \
  -addext "subjectAltName=DNS:nc.home.arpa,IP:192.168.xxx.xxx"
chmod 600 /etc/ssl/private/nextcloud.key
openssl x509 -in /etc/ssl/certs/nextcloud.crt -noout -text

Kontrolle: Unter „Subject Alternative Name“ müssen der DNS-Name und gegebenenfalls die IP-Adresse erscheinen. Der private Schlüssel bleibt auf dem Server. Für einen neuen Namen oder eine geänderte IP-Adresse muss man die Zertifikatsabdeckung erneut prüfen.

Auf den Übungsclients nur dem selbst erstellten öffentlichen Zertifikat vertrauen, nach Prüfung seiner Herkunft und seines Fingerabdrucks. Die Einrichtung des Vertrauens hängt vom Betriebssystem, Browser und Client ab. Den SHA-256-Fingerabdruck zeigt man so an:

openssl x509 -in /etc/ssl/certs/nextcloud.crt -noout -fingerprint -sha256

Für öffentlich erreichbare Installationen verwendet man stattdessen ein zum Hostnamen passendes Zertifikat einer auf den Clients vertrauenswürdigen Zertifizierungsstelle.

HTTPS-VirtualHost einrichten

Verwendet wird durchgehend nextcloud-ssl.conf, unabhängig vom zunächst eingerichteten HTTP-VirtualHost in 000-default.conf. Die Quelldatei unter sites-available bearbeiten:

vim /etc/apache2/sites-available/nextcloud-ssl.conf

Die Datei erhält folgenden Inhalt; Namen und Zertifikatspfade bei Bedarf anpassen:

<VirtualHost *:443>
    ServerName nc.home.arpa
    ServerAdmin webmaster@localhost
    DocumentRoot /var/www/nextcloud

    SSLEngine on
    SSLCertificateFile /etc/ssl/certs/nextcloud.crt
    SSLCertificateKeyFile /etc/ssl/private/nextcloud.key

    <Directory /var/www/nextcloud>
        Require all granted
        AllowOverride All
        Options FollowSymLinks MultiViews
        <IfModule mod_dav.c>
            Dav off
        </IfModule>
    </Directory>

    ErrorLog ${APACHE_LOG_DIR}/nextcloud-ssl-error.log
    CustomLog ${APACHE_LOG_DIR}/nextcloud-ssl-access.log combined
</VirtualHost>

Module und genau diese Site aktivieren, anschließend die Syntax prüfen:

a2enmod ssl headers rewrite
a2ensite nextcloud-ssl.conf
apache2ctl configtest

Nur bei erfolgreicher Prüfung (Syntax OK) die Konfiguration neu laden:

systemctl reload apache2

Falls aus einem vorherigen Versuch bereits default-ssl.conf oder ein anderer HTTPS-VirtualHost für denselben Host aktiviert ist, die Zuordnung mit apache2ctl -S prüfen. Eine nicht mehr benötigte konkurrierende Test-Site gezielt deaktivieren, beispielsweise mit a2dissite default-ssl.conf, und Apache danach erneut prüfen und laden.

Kontrolle: https://nc.home.arpa/ im Browser öffnen. Der Name muss vom Zertifikat abgedeckt sein. Falls Nextcloud eine nicht vertrauenswürdige Domain meldet, den tatsächlichen Hostnamen in der bestehenden trusted_domains-Liste in config/config.php ergänzen; vorhandene Einträge bleiben erhalten. Diese Nextcloud-Liste ersetzt nicht das Zertifikatsvertrauen des Browsers.

Wenn HTTPS funktioniert, folgt HTTP-Weiterleitung und HSTS.