Jitsi-Meet, nginx, Let’s Encrypt und die Zertifikats-Erneuerung
21. Oktober 2020 um 17:46 Uhr von Atari-Frosch
Während mein Jitsi-Meet immer noch nicht so richtig funktioniert, wie es soll, kam gestern früh Let's Encrypt angeschlappt und erklärte, es könne das Zertifikat für die Site nicht erneuern, weil:
Attempting to renew cert (meet.atari-frosch.de) from /etc/letsencrypt/renewal/meet.atari-frosch.de.conf produced an unexpected error: Failed authorization procedure. meet.atari-frosch.de (http-01): urn:ietf:params:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://meet.atari-frosch.de/.well-known/acme-challenge/$CODE [2a01:4f8:150:81e4::2]: "<html>\r\n<head><title>404 Not Found</title></head>\r\n<body bgcolor=\"white\">\r\n<center><h1>404 Not Found</h1></center>\r\n<hr><center>". Skipping.
Öhm.
Der Witz dabei ist: Die Erst-Anforderung des Zertifikats war gar kein Problem. Da sollte man doch davon ausgehen können, daß die Erneuerung genauso problemlos durchläuft. Tja, Theorie und Praxis, ne.
Also schaute ich mir als erstes die nginx-Konfiguration für die Site an. Da fand ich dann tatsächlich einen seltsamen Abschnitt, der das Problem zu erklären schien: Dem nginx wurde nämlich vorgegeben, auf einen Request in das Verzeichnis /.well-known/ mit einem 404 (file not found) zu antworten. Genau da schreibt aber der Certbot seine „Challenge“ rein, und ein Let's-Encrypt-Server muß dann darauf zugreifen können.
Na, das konnte ja nicht funktionieren. Das Zertifikat hatte ich glaube ich sogar vor der eigentlichen Installation von Jitsi-Meet angelegt gehabt; Jitsi-Meet hat seine Konfiguration für nginx selbst mitgebracht und dem nginx direkt untergeschoben. Ich hatte darin nicht mehr viel verändert und den Rest nicht angefaßt, weil ich davon ausging, die wissen besser als ich, was da drinstehen sollte.
Also nahm ich meinen eigenen location block für Let's Encrypt, wie ich ihn bei allen anderen Sites eingesetzt hatte, und setzte den an die Stelle der vorgegebenen Konfiguration von Jitsi-Meet. Damit war dann aber nginx wieder nicht einverstanden:
2020/10/20 13:30:07 [emerg] 24011#24011: named location "@root_path" can be on the server level only in /etc/nginx/sites-enabled/atarifrosch-meet:93
Aha. Soso. Ja, die Variable @root_path wird in der Konfiguration für Jitsi-Meet verwendet, in den anderen nicht.
Ein Suchmaschinenlauf brachte mich nicht weiter, denn DuckDuckGo kann offenbar nicht zwischen den Zeichenketten "root path" und "@root_path" unterscheiden, obwohl ich ihm die explizit in Anführungszeichen gesetzt hatte.
Ich starrte also noch eine Weile auf diese Konfigurationsdatei, um herauszufinden, was den nginx hier stört. Nun ist es ja so, daß Jitsi-Meet nicht in ein übliches Server-Verzeichnis installiert wird, sondern nach /usr/share/jitsi-meet/. Die Challenge für das Zertifikat wiederum möchte ich aber im üblichen Server-Verzeichnis für die Site ablegen. (Der Versuch, die Challenge im Jitsi-Meet-Verzeichnis abzulegen, ging übrigens ebenso schief.)
Und dann kam noch ein indirekter Tip aus dem Fediversum: Erik Pusch meinte, ich sollte mal auf Redirects testen. Ja, das war's dann wohl:
Der fiel auf die Nase, weil verschiedene Location Blocks mit der Variablen root auf verschiedene Verzeichnisse zeigten. Das ist erstmal wohl kein Problem und sogar so vorgesehen, aber tatsächlich gibt es da wohl rewrites, die dann nicht wissen, auf welchem root sie aufsetzen sollen.
Ergebnis war, ich verschob das ganze Jitsi-Meet-Geraffel in das Server-Verzeichnis und bog das natürlich auch dem nginx bei. Dann rief ich den Certbot nochmal auf und siehe da: Die Erneuerung lief einwandfrei durch.
Jetzt müßte nur noch Jitsi-Meet richtig funktionieren …
Das sieht nämlich derzeit so aus, daß ich mit Test-Usern eigentlich in die selbe Konferenz gehe, aber wir uns nicht sehen oder hören können. Sogar das Log sagt, daß beide IPs in derselben Konferenz sind. Ich bekomme angezeigt, daß ich (als Moderator) alleine in der Konferenz bin, während der Test-Partner angezeigt bekommt, daß die Konferenz keinen Moderator habe und er deshalb nicht rein dürfe. Wäre schon praktisch, gerade jetzt bei massiv steigenden Corona-Fällen, wenn man sich mal „treffen“ könnte, ohne sich real zu treffen … aber das ist wie gesagt schon wieder eine andere Baustelle.