Matrix Synapse auf Ubuntu Server 20.04 LTS mit nginx, PostgreSQL und Let’s Encrypt

Matrix ist ein offener Standard für dezentrale Echtzeitkommunikation. Im Gegensatz zu den bekannten Messenger-Diensten wie Threema, Signal oder auch WhatsApp gibt es hier nicht den einen Hersteller, der ein zentralisiertes System bereit stellt, sondern Matrix verfolgt den dezentralen Ansatz („Federation“): Dabei vernetzen sich eine Vielzahl an Servern zu einem großen Netzwerk. Ein Benutzer kann sich hier bei einem beliebigen Server registrieren, ist dann aber in der Kommunikation nicht auf diesen Server beschränkt, d.h. es kann auch mit Benutzern anderer Matrix-Server kommuniziert werden.

Der folgende Artikel zeigt die Installation und Konfiguration eines Matrix Synapse Servers auf Ubuntu Server 20.04 mit nginx, PostgreSQL und Let’s Encrypt.

Voraussetzungen/Ziele

Matrix selbst besteht aus mehreren Komponenten, daher sollten hier zunächst einmal ein paar Begriffe geklärt werden.

• Matrix ist zunächst nur einmal ein offener Standard eines Kommunikationsprotokolls. Daher gibt es auch nicht „die eine“ Server-/Client-Implementierung.
• Matrix Synapse ist eine Server-Implementierung des Matrix-Protokolls. Synapse ist dabei mehr oder weniger die Referenz-Implementierung. Daneben gibt es aber bereits auch weitere Implementierungen eines Servers (z.B. Dendrite). In diesem Artikel konzentrieren wir uns allerdings nur auf Synapse.
• Element ist eine Client-Implementierung für Matrix. Dieses Programm ist auf allen mobilen und Desktop-Plattformen erhältlich. Ebenso gibt es eine Web-Implementierung. Mit jeder Instanz von Element/Web bekommt man Zugriff auf das Matrix-Netzwerk.
  Auch wenn Element vermutlich der populärste Client ist, gibt es bereits eine ganze Menge anderer Clients.

Matrix Synapse nutzt „out of the Box“ eine SQLite-Datenbank. Diese ist allerdings nicht sehr performant, daher sollte hier auf ein „echtes“ Datenbank-System gesetzt werden. Daher installieren und konfigurieren wir im Rahmen des Artikels auch gleich PostgreSQL als Datenbank für Matrix Synapse.

Folgende Programme kommen hier zum Einsatz:

• Ubuntu Server 20.04 LTS („Focal Fossa“)
• Matrix Synapse 1.26.0
• nginx 1.19.6 (aus dem offiziellen nginx-Repository)
• PostgreSQL 12.5
• acme.sh (für TLS-Zertifikate)

Im Rahmen des Artikels nutze ich folgende beispielhafte Domain für Matrix Synapse: matrix.meinedomain.de

Vorbereitungen

Als erstes bringen wir das Betriebssystem auf den neusten Stand:

apt update && apt upgrade -V && apt dist-upgrade && apt autoremove 
reboot

Nach dem Reboot verschaffen wir uns erst einmal Root-Rechte für diese Session:

sudo -s

Als nächstes richten wir gleich noch die Firewall ufw ein. Diese ist auf einem Ubuntu-System standardmäßig bereits installiert. Sollte dies nicht der Fall sein, kann man dies nun nachholen:

apt update && apt install ufw

Die Firewall sollte sämtlichen eingehenden Traffic blockieren, mit folgenden Ausnahmen:

• SSH (Port 22): Hier darf die Firewall die SSH-Verbindung natürlich nicht blocken, sonst sperren wir uns hier aus dem System aus.
• HTTP/HTTPS (Port 80/443): Diese Ports werden für die Erstellung der TLS-Zertifikate (80) und die Kommunikation mit Matrix Synapse (443) benötigt.

Mit folgenden Befehlen wird die Firewall entsprechend konfiguriert:

ufw default deny
ufw allow 22
ufw allow 80
ufw allow 443
ufw enable

Nach dem Setzen der Regeln und Aktivierung der Firewall kann der Status nochmals überprüft werden:

ufw status

Hinweis: Wenn auf dem Server weitere Anwendungen installiert sind, die über andere Ports laufen, sind diese natürlich auch an der Firewall zu berücksichtigen.

Installation Matrix Synapse

Nach diesen Vorarbeiten kann Matrix Synapse auch schon installiert werden. Hier installieren wir die Voraussetzungen für den Server und fügen die Matrix-Paketquellen und den dazu gehörenden Repository-Key hinzu. Am Ende wird Matrix Synapse selbst installiert:

apt install -y lsb-release wget apt-transport-https
wget -qO /usr/share/keyrings/matrix-org-archive-keyring.gpg https://packages.matrix.org/debian/matrix-org-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/matrix-org-archive-keyring.gpg] https://packages.matrix.org/debian/ $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/matrix-org.list
apt update && apt install matrix-synapse-py3

Nach der Installation wird der Dienst konfiguriert, so dass dieser beim Systemstart automatisch gestartet wird:

systemctl start matrix-synapse
systemctl enable matrix-synapse

Konfiguration Matrix Synapse

Nun geht es daran, Matrix zu konfigurieren.
Dazu erzeugen wir uns erst einmal ein „Registrierungs-Secret“:

cat /dev/urandom | tr -dc 'a-zA-Z0-9' | fold -w 32 | head -n 1

Anschließend wird die Konfigurations-Datei von Matrix Synapse geöffnet:

nano /etc/matrix-synapse/homeserver.yaml

Diese Datei ist sehr umfangreich, da hier viele Einstellungen konfiguriert werden können. Alle Optionen und Möglichkeiten sind hier aber sehr gut dokumentiert, so dass man sich durchaus die Zeit nehmen sollte, die Datei einmal komplett durch zugehen und die entsprechenden Einstellungen vorzunehmen.
Die wichtigsten Punkte sollten hier allerdings folgenden sein (am besten mit STRG+W nach den Variablen-Namen suchen):

public_baseurl: https://matrix.meinedomain.de/

Dies definiert den Namen des Matrix Synapse-Servers und ist einfach die URL unter der der Server aufgerufen wird.

max_upload_size: 50M

Maximale Dateigröße für Uploads (dies muss später dann auch in nginx konfiguriert werden).

url_preview_enabled: true

Dies sorgt dafür, dass in einem Chat gepostete URLs als Vorschau angezeigt werden, wie man es aus anderen Messengern kennt. Wenn diese Option aktiviert wird, muss noch eine andere Variable gesetzt werden:

url_preview_ip_range_blacklist:
  - '127.0.0.0/8'
  - '10.0.0.0/8'
  - '172.16.0.0/12'
  - '192.168.0.0/16'
  - '100.64.0.0/10'
  - '169.254.0.0/16'
  - '::1/128'
  - 'fe80::/64'
  - 'fc00::/7'
  - '192.168.178.0/24'

Dies sind IP-Adress-Bereiche, die von den URL-Reviews ausgeschlossen werden. Neben den Default-Werten sollten hier auch alle lokalen IP-Adressen ausgeschlossen werden (hier 192.168.178.0/24), da dies sonst ein Sicherheitsrisiko darstellen kann.

enable_registration: false

Wird diese Option auf false gesetzt, können sich keine neuen User selbstständig registrieren. Wer den Matrix Synapse-Server allerdings als öffentliche Instanz (d.h. dass sich neue Benutzer selbstständig registrieren können) betreiben will, sollte diese Option auf true setzen.

registration_shared_secret: SECRET

Zur Registrierung des ersten (Admin-)Accounts muss dieses Registration Secret (welches wir weiter oben erzeugt hatten) angegeben werden. Dies ist besonders wichtig, wenn die allgemeine Registrierung abgeschaltet wurde (siehe vorherige Option).

enable_metrics: false
report_stats: false

Diese beiden Optionen sorgen dafür, dass keine Metriken gesammelt werden und auch nicht übermittelt werden.

email:
  smtp_host: smtp.meinedomain.de
  
  smtp_port: 587
  
  smtp_user: "user"
  smtp_pass: "password"

  require_transport_security: true

  notif_from: "Your Friendly %(app)s homeserver <noreply@meinedomain.de>"

Diese Optionen sind nur erforderlich, wenn der Matrix-Server E-Mails versenden können soll. Dies ist v.a. dann hilfreich, wenn ein Benutzer sein Passwort vergessen haben sollte, denn für die Wiederherstellung wird eine Bestätigung per E-Mail versendet. Wenn der Matrix-Server keine E-Mail senden kann, kann ein User daher sein Passwort nicht mehr wiederherstellen.
Die Daten, die hier anzugeben sind, müssen natürlich einem echten STMP-Server entsprechen.

push:
  include_content: false

Hier geht es in erster Linie um Datenschutz. Wenn include_content auf true gesetzt wird, wird der Inhalt von Nachrichten über die Google-/Apple-Push-Services geleitet. Wer dies nicht möchte, stellt diese Option auf false: Push-Benachrichtigungen funktionieren dann immer noch, allerdings werden hier dann keine Inhalte von Nachrichten mehr an Google/Apple übermittelt.

Dies sind bei weitem noch nicht alle Konfigurations-Optionen, sollte aber einen guten Startpunkt bieten.

Damit die Änderungen übernommen werden, muss Matrix einmal neu gestartet werden:

service matrix-synapse restart

PostgreSQL für Matrix Synapse konfigurieren

Matrix Synapse nutzt direkt nach der Installation SQLite als Datenbank. Dieses Datenbanksystem ist allerdings mehr für Demo-Zwecke geeignet, da die Performance hier eher schlecht ist. Für einen produktiven Betrieb sollte auf jeden Fall ein „richtiges“ Datenbanksystem zum Einsatz kommen. Neben SQLite unterstützt Matrix Synapse hier auch PostgreSQL, welches nun im Folgenden eingerichtet wird.

Dies sollte auf jeden Fall vor dem Anlegen des ersten Users geschehen, damit man sich die Migration von SQLite auf PostgreSQL sparen kann.

Die Installation gestaltet sich zunächst einmal sehr einfach:

apt update && apt install postgresql python3-psycopg2

Nun wird ein entsprechender User und eine Datenbank für Matrix Synapse angelegt. Dazu wechseln wir zunächst einmal auf den PostgreSQL-User:

su - postgres

Nun wird noch die PostgreSQL-Kommandozeile aufgerufen:

psql

Nun wird zunächst der Datenbank-Benutzer angelegt (das Passwort muss an dieser Stelle natürlich abgeändert werden):

CREATE USER "synapse_db_user" WITH PASSWORD 'MeInPassSw0rT';

Danach folgt die Anlage der Datenbank selbst:

CREATE DATABASE synapse_db
 ENCODING 'UTF8'
 LC_COLLATE='C'
 LC_CTYPE='C'
 template=template0
 OWNER synapse_db_user;

Danach kann die PostgreSQL-Kommandozeile verlassen werden:

\q

Am Schluss erfolgt die Abmeldung des PostgreSQL-Users:

exit

Damit Synapse nun auch PostgreSQL nutzt, muss hier noch die Konfiguration angepasst werden:

nano /etc/matrix-synapse/homeserver.yaml

Hier wird zunächst einmal die Konfiguration für SQLite auskommentiert und direkt dahinter die Anweisungen für PostgreSQL hinzugefügt (das Passwort ist natürlich wieder mit dem Passwort des Synapse-DB-Benutzers zu ersetzen):

#database:
#  name: sqlite3
#  args:
#    database: /path/to/homeserver.db
#
#
# Example Postgres configuration:
#
database:
  name: psycopg2
  args:
    user: synapse_db_user
    password: MeInPassSw0rT
    database: synapse_db
    host: localhost
    cp_min: 5
    cp_max: 10

Nach einem Neustart des Dienstes wird ab nun PostgreSQL als Datenbank für Matrix Synapse genutzt:

service matrix-synapse restart

Optional: Optimieren der PostgreSQL-Umgebung

PostgreSQL kann nun noch auf das jeweilige System „zugeschnitten“ werden. Einen guten Startpunkt hierfür liefert die Seite PGTune: Hier muss man einfach nur die jeweiligen Werte des Systems eintragen und erhält Anweisungen, wie PostgreSQL auf das System optimiert werden kann.

Die Einstellungen sind hier in der Datei /etc/postgresql/12/main/postgresql.conf durchzuführen.

Damit die Änderungen übernommen werden, wird das Datenbank-System einmal neu gestartet:

service postgresql restart

Optional: Nutzung von coturn für STUN/TURN

Matrix unterstützt ebenfalls Audio- und Videoanrufe. Damit dies auch netzwerkübergreifend funktioniert, wird in den meisten Fällen ein STUN/TURN-Server benötigt. STUN (Session Traversal Utilities for NAT) sorgt einfach ausgedrückt dafür, dass ein Client aus dem LAN seine öffentliche IP-Adresse ermitteln kann. TURN (Traversal Using Relays around NAT) sorgt wiederum dafür, dass Clients ohne eine direkte Verbindung Daten austauschen können. Ein TURN-Server wirkt hier dann als Relay Server.

Wie schon bei anderen Server-Programmen für Audio-/Videokonferenzen, kann hier coturn als STUN/TURN-Server genutzt werden. Zur Installation und Konfiguration von coturn gab es hier im Blog bereits einen umfangreichen Artikel: Nextcloud Talk mit eigenem TURN-Server (coturn)
Dieser zeigt die Einrichtung zwar für Nextcloud Talk, aber die Einstellungen unterscheiden sich nicht für Matrix Synapse.

Um einen eigenen coturn-Server aufzusetzen, kann daher der oben genannte Artikel genutzt werden. Auf der Seite von Matriyx Synapse muss dann der coturn-Server lediglich in den Einstellungen hinterlegt werden:

nano /etc/matrix-synapse/homeserver.yaml

Hier sind dann folgende zwei Einstellungen vorzunehmen:

turn_uris: ["turn:turn.meinedomain.de:5349?transport=udp", "turn:turn.meinedomain.de:5349?transport=tcp"]
turn_shared_secret: "4bc5bef7e62e795bab2b14a53519fe90235bf5f5045264567c5c1e90f501ecb2"

Hier gehe ich davon aus, dass coturn über die Domain turn.meinedomain.de auf Port 5349 (TCP und UDP) erreichbar ist. Das turn_shared_secret ist dabei das „Secret“, welches in der Konfiguration von coturn angegeben wird (hier heißt die Variable static-auth-secret) und muss hier wie schon die Domain individuell angepasst werden.

Am Ende fehlt nur noch der Neustat von Matrix Synapse:

service matrix-synapse restart

nginx als Webserver für Matrix Synapse

Bis hierhin läuft Synapse erst einmal rein lokal. Damit der Server auch über das Internet erreichbar wird, wird der Webserver nginx als Reverse Proxy vor die Synapse-Instanz gestellt. Zwar könnte man Synapse auch so aufsetzen, dass dieser die Anfragen auch selbst bearbeiten kann, die Konfiguration wäre hier aber etwas umständlicher. nginx als Reverse Proxy ist hier sehr einfach zu installieren und wer bereits ein wenig Erfahrung mit nginx hat, wird sich hier sehr leicht tun.

Installation nginx

Bei nginx nutze ich nicht die Paketquellen von Ubuntu selbst, da die verwendete nginx-Version hier doch schon recht alt ist. Um hier auf einem aktuelleren Stand zu sein, binden wir die Paketquellen aus dem offiziellen nginx-Repository ein. Hier nutze ich immer die sog. „Mainline“, da dies der stabilste Branch von nginx ist.

Dazu machen wir zunächst den Key des Repositories auf dem System bekannt:

wget -O - http://nginx.org/keys/nginx_signing.key | apt-key add -

Anschließend werden die Paketquellen selbst eingebunden:

nano /etc/apt/sources.list.d/nginx.list

In diese Datei fügen wir dann folgende Zeilen hinzu:

# Nginx (Mainline)
deb [arch=amd64] http://nginx.org/packages/mainline/ubuntu/ focal nginx
deb-src [arch=amd64] http://nginx.org/packages/mainline/ubuntu/ focal nginx

Nun kann auch schon der Webserver installiert werden:

apt update && apt install nginx

Grundkonfiguration nginx

Direkt nach der Installation des Webservers sollte die allgemeine Konfiguration überarbeitet/optimiert werden:

nano /etc/nginx/nginx.conf

Hier sollten folgende Einstellungen angepasst/kontrolliert werden:

• user: Der User, unter dem der Webserver läuft. Dies sollte immer www-data sein.
• worker_processes: Die Anzahl der Threads, die nginx zum Abarbeiten von Client-Request verwendet. Die optimale Einstellung ist hier auto, da nginx dann pro CPU-Kern einen Thread verwendet.
• server_tokens: Diese Einstellung sollte auf off gesetzt werden, damit nginx keine Versions-Informationen preisgibt (z.B. auf Fehlerseiten). Wenn diese Variable nicht vorhanden ist, muss man diese im HTTP-Block der Datei einfügen: server_tokens off;

Danach kann auch gleich der Default-vHost deaktiviert werden, da dieser nur eine Demo-Seite für nginx bereit stellt. Ebenso wird der Webserver zur Übernahme der Änderungen neu gestartet:

mv /etc/nginx/conf.d/default.conf /etc/nginx/conf.d/default.conf_disabled 
service nginx restart

TLS-Zertifikate über Let’s Encrypt

Matrix Synapse sollte nach der Installation ausschließlich über über eine HTTPS-gesicherte Verbindung nutzbar sein. Dazu bedarf es zunächst einmal gültiger TLS-Zertifikate.
Ich nutze hier immer Zertifikate von Let’s Encrypt. Als Client für Let’s Encrypt kommt hier acme.sh zum Einsatz.

Um hier technisch auf dem neusten Stand zu sein, kommen hier ECDSA- und RSA-Zertifikate im Hybrid-Betrieb zum Einsatz. Außerdem sollte TLSv1.3 genutzt werden.
Hintergrundinformationen zu diesem Themen sind den folgenden Artikeln zu entnehmen:

• Let’s Encrypt Zertifikate mit acme.sh und nginx
• RSA und ECDSA-Zertifikate mit nginx (Hybrid-Lösung)
• TLSv1.3 unter Ubuntu Server 18.04 LTS mit nginx

Weil Let’s Encrypt nicht als Root-User ausgeführt werden sollte, legen wir zunächst einen speziellen Benutzer auf dem System an:

adduser letsencrypt

Für diesen Benutzer muss kein Passwort vergeben werden (einfach leer lassen). Ebenso braucht man keine weiteren Infos angeben (alles mit Enter bestätigen), da dies ein rein lokaler Benutzer ist, mit dem man sich im Normalfall nicht anmeldet.

Anschließend wird dieser User dann noch der Gruppe www-data hinzugefügt:

usermod -a -G www-data letsencrypt

Der Let’s Encrypt Benutzer braucht darüber hinaus noch die Rechte, den Webserver (nginx) neu laden zu können. Dies wird mittels visudo eingerichtet:

visudo

Ganz am Ende der Datei wird nun folgende Zeile hinzugefügt. Anschließend speichern und den Editor verlassen.

letsencrypt ALL=NOPASSWD: /bin/systemctl reload nginx.service

Nun kann man sich auch schon mit dem neuen Benutzer anmelden:

su - letsencrypt

Der Let’s Encrypt Client acme.sh wird dann einfach mit folgendem Befehl installiert:

curl https://get.acme.sh | sh

Nach der Installation sollte man sich mit dem entsprechenden User einmal ab- und wieder anmelden:

exit
su - letsencrypt

Danach kann acme.sh gleich so konfiguriert werden, dass Zertifikate über Let’s Encrypt ausgestellt werden. Seit dem 01.08.2021 nutzt acme.sh standardmäßig Zertifikate von ZeroSSL (siehe hier). Dieses Standard-Verhalten kann allerdings ganz einfach geändert werden:

acme.sh --set-default-ca --server letsencrypt

Wenn dies erledigt ist, kann man sich erst einmal mit diesem Benutzer wieder abmelden:

exit

Als nächstes bereiten wir nginx für die Generierung der TLS-Zertifikate vor. Dazu legen wir erst einmal einen neuen virtuelle Host an:

nano /etc/nginx/conf.d/HttpGateway.conf

Der Inhalt des vHost sollte folgendermaßen aussehen:

server {
    listen 80 default_server;
    listen [::]:80 default_server;
    server_name matrix.meinedomain.de 192.168.178.60;
 
    root /var/www;

    location ^~ /.well-known/acme-challenge {
        default_type text/plain;
        root /var/www/letsencrypt;
    }

	location / {
		return 301 https://$host$request_uri;
	}
}

Wichtig ist an dieser Stelle v.a. der server_name: Dies sollte eure Domain sein, unter der Matrix später erreichbar sein soll. Daneben wird noch die lokale IP des Server mit angegeben.
Ansonsten behandelt dieser vHost nur die Anfragen für Let’s Encrypt und leitet sämtlichen anderen Traffic an HTTPS weiter.

Am Schluss muss nginx noch neu gestartet werden:

service nginx restart

Nun wird die Verzeichnisstruktur vorbereitet. Dies betrifft sowohl die Verzeichnisse, in denen später die Zertifikate selbst gespeichert werden, als auch das Web-Verzeichnis für Let’s Encrypt:

mkdir -p /var/www/letsencrypt/.well-known/acme-challenge
chown -R www-data:www-data /var/www/letsencrypt
chmod -R 775 /var/www/letsencrypt
mkdir -p /etc/letsencrypt/matrix.meinedomain.de/rsa
mkdir -p /etc/letsencrypt/matrix.meinedomain.de/ecc
chown -R www-data:www-data /etc/letsencrypt
chmod -R 775 /etc/letsencrypt

Wichtig ist hier v.a., dass der Webserver-User (www-data) Zugriff auf diese Verzeichnisse hat.

Bevor man sich nun an die Generierung der Zertifikate macht, sollte kontrolliert werden, ob die entsprechende URL von außen auch korrekt erreichbar ist.

Dazu legen wir uns im Zielverzeichnis, welches später für die Verifizierung von Let’s Encrypt genutzt wird, eine temporäre Datei an:

echo "Test" >> /var/www/letsencrypt/.well-known/acme-challenge/test.txt

Nun ruft man im Browser einfach folgende URLs auf: http://matrix.meinedomain.de/.well-known/acme-challenge/test.txt

In beiden Fällen sollte hier der Inhalt der Datei („Test“) angezeigt werden:

Erst wenn dieser Test erfolgreich abgeschlossen wurde, sollte man mit der Generierung der Zertifikat beginnen!

Als nächstes können die TLS-Zertifikate selbst generiert werden. Dazu wechseln wir erst einmal wieder auf den Let’s Encrypt Benutzer:

su - letsencrypt

Zunächst werden die RSA-Zertifikate erzeugt:

acme.sh --issue -d matrix.meinedomain.de --server letsencrypt --keylength 4096 -w /var/www/letsencrypt --key-file /etc/letsencrypt/matrix.meinedomain.de/rsa/key.pem --ca-file /etc/letsencrypt/matrix.meinedomain.de/rsa/ca.pem --cert-file /etc/letsencrypt/matrix.meinedomain.de/rsa/cert.pem --fullchain-file /etc/letsencrypt/matrix.meinedomain.de/rsa/fullchain.pem --reloadcmd "sudo /bin/systemctl reload nginx.service"

Weiter geht es mit den ECDSA-Zertifikaten:

acme.sh --issue -d matrix.meinedomain.de --server letsencrypt --keylength ec-384 -w /var/www/letsencrypt --key-file /etc/letsencrypt/matrix.meinedomain.de/ecc/key.pem --ca-file /etc/letsencrypt/matrix.meinedomain.de/ecc/ca.pem --cert-file /etc/letsencrypt/matrix.meinedomain.de/ecc/cert.pem --fullchain-file /etc/letsencrypt/matrix.meinedomain.de/ecc/fullchain.pem --reloadcmd "sudo /bin/systemctl reload nginx.service"

An dieser Stelle wird nochmal mittels –server letsencrypt explizit angegeben, dass Zertifikate von Let’s Encrypt erzeigt werden sollen. Dies ist – sofern die Standard-Einstellung von acme.sh geändert wurde (s.o.) – eigentlich überflüssig, schadet an dieser Stelle allerdings auch nicht.

Im Anschluss findet man die Zertifikat-Dateien im Verzeichnis /etc/letsencrypt/matrix.meinedoamin.de/rsa (bzw. /ecc):

• cert.pem: Das öffentliche Zertifikat in Reinform
• ca.pem: Öffentliches Zertifikat aus der sog. Keychain
• fullchain.pem: Entspricht cert.pem + chain.pem
• key.pem: Privates Zertifikat (diese Datei sollte man daher niemals weitergeben)

Am Schluss erfolgt wieder die Abmeldung mit dem User letsencrypt:

exit

Da Zertifikate von Let’s Encrypt eine Gültigkeit von 90 Tagen haben, müssen diese spätestens nach Ablauf dieser Zeitspanne erneuert werden. Im Rahmen der ersten Generierung der Zertifikate wurde dazu unter dem User letsencrypt ein Cronjob angelegt, der sich automatisch um dieser Erneuerung kümmert.

Kurz vor Ablauf der Gültigkeit werden die Zertifikate automatisch – und ohne Zutun des Benutzers – selbstständig erneuert. Daher braucht man sich in Zukunft nicht mehr selbst um die Zertifikate zu kümmern.

Die Sicherheit des HTTPS-Kommunikation kann noch durch den Einsatz sog. Diffie-Hellman-Parameter weiter erhöht werden. Dies sorgt einfach ausgedrückt für einen Sicheren Schlüsselaustausch beim Verbindungsaufbau über HTTPS.

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

mkdir -p /etc/nginx/dhparams 
openssl dhparam -out /etc/nginx/dhparams/dhparams.pem 4096

SSL und Header-Konfiguration nginx

Als nächstes legen wir allgemeine SSL- und Header-Konfigurations-Dateien an, die im weiteren Verlauf werden diese dann in den eigentlichen virtuellen Host für Matrix Synapse per „include“ eingebunden.
Dies bietet u.a. den Vorteil, dass beim Hosten weiterer Webanwendungen auf dem gleichen Server diese „Sippets“ wiederverwendet werden können und nicht in jedem vHost separat aufgeführt werden müssen.

Dazu legen wir zunächst ein eigenes Verzeichnis für diese Snippets an:

mkdir -p /etc/nginx/snippets

Wir starten dann mit den allgemeinen SSL-Einstellungen:

nano /etc/nginx/snippets/ssl.conf

Hier wird folgender Inhalt eingefügt, bevor die Datei gespeichert und geschlossen wird:

#
# Configure SSL
#

# Diffie-Hellman parameter for DHE ciphersuites, recommended 4096 bits
ssl_dhparam /etc/nginx/dhparams/dhparams.pem;

# Not using TLSv1 will break:
# Android <= 4.4.40 IE <= 10 IE mobile <=10
# Removing TLSv1.1 breaks nothing else!
ssl_protocols TLSv1.2 TLSv1.3;

# SSL ciphers: RSA + ECDSA
# Two certificate types (ECDSA, RSA) are needed.
ssl_ciphers 'TLS-CHACHA20-POLY1305-SHA256:TLS-AES-256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-RSA-AES256-GCM-SHA384';

# Use multiple curves.
ssl_ecdh_curve secp521r1:secp384r1;

# Server should determine the ciphers, not the client
ssl_prefer_server_ciphers on;

# SSL session handling
ssl_session_timeout 1d; 
ssl_session_cache shared:SSL:50m; 
ssl_session_tickets off;

# SSL stapling has to be done seperately, becuase it will not work with self signed certs
# OCSP Stapling fetch OCSP records from URL in ssl_certificate and cache them
ssl_stapling on;
ssl_stapling_verify on;

# DNS resolver
resolver 192.168.178.1;

Ganz unten wird hier auch gleich noch der „resolver“ eingefügt: Mit dieser Variablen wird der DNS-Server angegeben. In diesem Beispiel nutze ich dazu die IP-Adresse der FritzBox (192.168.178.1), welche im Netzwerk als als DNS-Server fungiert..

Analog dazu werden die allgemeinen Header-Informationen angelegt:

nano /etc/nginx/snippets/headers.conf

Hier fügen wir folgenden Inhalt ein:

#
# Add headers to serve security related headers
#  
# HSTS (ngx_http_headers_module is required)
add_header Strict-Transport-Security "max-age=63072000; includeSubdomains; preload;" always; 
add_header X-Content-Type-Options "nosniff" always;
add_header X-XSS-Protection "1; mode=block" always;
add_header X-Robots-Tag none always;
add_header X-Download-Options noopen always;
add_header X-Permitted-Cross-Domain-Policies none always;
add_header Referrer-Policy no-referrer always;
add_header X-Frame-Options "SAMEORIGIN" always;

# Remove X-Powered-By, which is an information leak
fastcgi_hide_header X-Powered-By;

Virtueller Host für Matrix Synapse

Nun kann auch schon der eigentliche vHost für Matrix Synapse angelegt werden:

nano /etc/nginx/conf.d/matrix.meinedomain.de.conf

Der Inhalt sieht dabei wie folgt aus:

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name matrix.meinedomain.de;

    #
	# Certificate configuration
    #

    # RSA certificates
    ssl_certificate /etc/letsencrypt/matrix.meinedomain.de/rsa/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/matrix.meinedomain.de/rsa/key.pem;
    # ECC certificates
    ssl_certificate /etc/letsencrypt/matrix.meinedomain.de/ecc/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/matrix.meinedomain.de/ecc/key.pem;

    # This should be ca.pem (certificate with the additional intermediate certifica$
    # See here: https://certbot.eff.org/docs/using.html
    # ECC
    ssl_trusted_certificate /etc/letsencrypt/matrix.meinedomain.de/ecc/ca.pem;

    # Include SSL and header snippets
    include /etc/nginx/snippets/ssl.conf;
    include /etc/nginx/snippets/headers.conf;

    #
    # Matrix Synapse configuration
    #

    # Disable error and access log.
    # This way, no IP will be logged by nginx
    access_log off;
    error_log off;
	
    # Increase timeout values
    # Useful if rooms (on different server) act very slowly. 
    proxy_connect_timeout 300s;
    proxy_send_timeout 300s;
    proxy_read_timeout 300s;

    # If you don't wanna serve a site, comment this out
    #root /var/www/html;
    #index index.html index.htm;

    location /_matrix {
      proxy_pass http://127.0.0.1:8008;
      proxy_set_header X-Forwarded-For $remote_addr;
      proxy_set_header X-Forwarded-Proto $scheme;
      client_max_body_size 50M;
    }

    location /.well-known/matrix/server {
      return 200 '{"m.server": "matrix.meinedomain.de:443"}';
      add_header Content-Type application/json;
    }

    location /.well-known/matrix/client {
      return 200 '{"m.homeserver": {"base_url": "https://matrix.meinedomain.de"}}';
      add_header Content-Type application/json;
      add_header "Access-Control-Allow-Origin" *;
    }
}

Ein besonderes Augenmerk sollte dabei auf folgende Einstellungen gelegt werden:

• Die Domain lautet hier beispielsweise matrix.meinedomain.de. Diese muss natürlich auf die richtige Domain geändert werden.
• access_log und error_log werden für Matrix Synapse deaktiviert. Dies macht v.a. Sinn, wenn man Wert auf Datenschutz und Privatsphäre gelegt wird, da auf diese Weise keine IP-Adressen von nginx geloggt werden.
  Wichtig: Wenn es zu Problemen kommen sollte, kann man das error.log (temporär) wieder aktivieren, um die Fehlersuche zu erleichtern.
• Eine Besonderheit stellt der location-Block für /.well-known/matrix/server dar. Dies ist der Endpunkt, der für die Federation (Server-Server-Kommunikation) genutzt wird. Normalerweise nutzt Matrix hierfür den Port 8448. Die hier gezeigte Variante nutzt dagegen eine sog. Well-Known-URL, die Informationen für den Federation-Endpunkt im JSON-Format zurück liefert. Auf diese Weise kann die Federation-Kommunikation ebenfalls ablaufen. Vorteil dieser Variante ist, dass kein zusätzlicher Port (8448) geöffnet werden muss und ebenfalls kein zweiter vHost für nginx benötigt wird.

Nach dem Anlegen des neuen virtuellen Hosts muss der Webserver noch ein mal neu gestartet werden:

service nginx restart

Funktionstest Matrix Synapse

Die Server-Komponente von Matrix Synapse ist nun fertig eingerichtet. Bevor die Instanz nun „live“ geht, sollten noch zwei Tests durchgeführt werden.

Zum einen sollte sicher gestellt sein, dass die Transportverschlüsselung mittels TLS korrekt eingerichtet ist. Dies betrifft sowohl die Let’s Encrypt Zertifikate, als auch die Konfiguration des Webservers.
Hierzu nutze ich immer gern den SSL Server Test von Qualys SSL Labs. Mit der gezeigten Konfiguration sollte hier auf jeden Fall ein Rating von A+ angezeigt werden.

Zum anderen ist Matrix ja ein dezentrales System, hier spielt also auch die Server-Server-Kommunikation (Federation) eine entscheidende Rolle. Ob hier alles korrekt eingerichtet wurde, kann der Matrix Federation Tester genutzt werden. Mit der Eingabe der Domain (matrix.meinedomain.de) sollte hier zwei mal eine Erfolgsmeldung angezeigt werden:

Damit ist dann sicher gestellt, dass das Federation-Feature von Matrix ordnungsgemäß funktioniert.

Matrix Synapse User anlegen und Client verbinden

Als nächstes sollte nun der erste (Admin-)User für die neue Matrix-Instanz angelegt werden. Da wir in der Konfiguration von Matrix weiter oben die Registrierung von Benutzern deaktiviert haben, muss dies auf der Kommandozeile mit folgendem Befehl erledigt werden:

register_new_matrix_user -c /etc/matrix-synapse/homeserver.yaml http://localhost:8008

Danach fragt das System nach dem „localpart“. Dies ist quasi der Benutzername auf der Instanz (dazu später mehr). Im Anschluss wird dann ein Passwort und eine Bestätigung gefordert. Ganz am Ende kann dieser Benutzer durch die Eingabe von yes zum Administrator der Matrix-Instanz gemacht werden.
Auf diese Art und Weise lassen sich also beliebig viele Benutzer (mit und ohne Admin-Rechte) anlegen.

Nun kann man sich mit dem soeben angelegten User an der Instanz anmelden. Dazu ist natürlich ein Client notwendig.
Der „offizielle“ Client ist hier Element. Diesen gibt es für alle Plattformen (mobil/Desktop) auf der Website von Element.
Interessant ist aber, dass man eigentlich gar kein Programm/App installieren muss, sondern auch den Web-Client von Element nutzen kann. Die folgenden Schritte werden daher beispielhaft am Web-Client gezeigt, das Vorgehen auf anderen Clients sollte hier analog ablaufen.

Nach dem Aufruf des Web-Clients von Element selbst befindet man sich auf der offiziellen Instanz, mit der man einen Matrix-Account bei matrix.org anlegen kann. Weil wir ja unsere eigene Instanz eines Matrix-Servers betreiben, melden wir und hier nicht bei matrix.org, sondern auf unserem Server (matrix.meinedomain.de) an.

Dazu geben wir nach einem Klick auf Anmelden unseren kompletten Benutzernamen ein. Dieser folgt immer dem Schema @benutzername:domain.tld, in diesem Fall also z.B. @testuser:matrix.meinedomain.de
Der Webclient erkennt hier automatisch, dass es sich um eine eigenständige Matrix-Instanz handelt, auf der ihr euch anmelden möchtet und zeigt diese dann auch unter Heimserver an:

Nach einem Klick auf Anmelden befindet ihr auch schon auf eurer eigenen Matrix-Instanz.

Fazit

Wenn ihr dem Artikel soweit gefolgt seid, habt ihr einen eigenen Chat-Server mit Matrix Synapse installiert und eingerichtet. Ihr könnt nun mit beliebigen Usern auf beliebigen Matrix-Servern sicher und verschlüsselt kommunizieren.

Matrix bzw. Element hat sehr viele Features zu bieten, daher kann der Umgang mit dem Client zunächst im Vergleich mit den „herkömmlichen Messengern“ wie Threema, Signal oder auch WhatsApp etwas gewöhnungsbedürftig sein. Die TU Dresden stellt dazu eine sehr umfangreiche Anleitung für Benutzer zur Verfügung. Diese ist auf jeden Fall mal einen Blick wert, um sich mit dem System und den damit verbundenen Möglichkeiten vertraut zu machen.

Weiterführende Artikel

• Let’s Encrypt Zertifikate mit acme.sh und nginx
• RSA und ECDSA-Zertifikate mit nginx (Hybrid-Lösung)
• TLSv1.3 unter Ubuntu Server 18.04 LTS mit nginx
• Nextcloud Talk mit eigenem TURN-Server (coturn)

Links

• Matrix (Kommunikationsprotokoll) (Wikipedia)
• Matrix Synapse (GitHub)
• Element (offizielle Website)
• Clients Matrix (matrix.org)
• PGTune (Optimierungen für PostgreSQL)
• Session Traversal Utilities for NAT (Wikipedia)
• Traversal Using Relays around NAT (Wikipedia, englisch)
• Let’s Encrypt (offizielle Homepage)
• acme.sh (GitHub)
• SSL Server Test (Qualys SSL Labs)
• Matrix Federation Tester
• Element Client Download
• Element Web-Client
• Matrix an der TU Dresden

Ähnliche Artikel:

Matrix: Element auf Ubuntu Server 20.04 LTS mit nginx und Let’s Encrypt Nextcloud auf Ubuntu Server 20.04 LTS mit nginx, MariaDB, PHP, Let’s Encrypt, Redis und Fail2ban Nextcloud auf Ubuntu Server 22.04 LTS mit nginx, PostgreSQL/MariaDB, PHP, Let’s Encrypt, Redis und Fail2ban Jitsi Meet: Videokonferenz-System unter Ubuntu Server mit nginx