Wenn Let’s Encrypt nicht erneuern will …
Freitag, 23. April 2021
Ich habe das jetzt schon ein paarmal beobachtet: Let's Encrypt, hier „vertreten“ durch den Certbot, meldet immer mal wieder für die eine oder andere (Sub-)Domain, daß eine Erneuerung des Zertifikats nicht möglich sei, weil die Bots, die die Challenge überprüfen, in einen Timeout gelaufen seien. Die Standard-Vermutung ist, sie seien in die Firewall geraten. Das passierte bisher sowohl hier auf meinem eigenen Server als auch auf dem Server eines Vereins, den ich administriere.
Und jedesmal überprüfte ich die vier IP-Adressen, mit denen Let's Encrypt zugreifen wollte, und sie standen natürlich nicht in der Firewall. fail2ban wußte jeweils auch nix davon.
Das Problem löst sich manchmal von selbst, indem Let's Encrypt dann doch irgendwann nach Tagen oder Wochen die Erneuerung durchführt, als wäre nichts gewesen. Aber manchmal will es gar nicht funktionieren, dann muß man etwas nachhelfen – so wie ich heute bei einer Subdomain, bei der sich der Certbot bereits seit 40 Tagen vergeblich um eine Erneuerung bemühte.
Die Lösung ist … unkonventionell und vom Typ „muß ich nicht verstehen, oder?“. So geht's: (mehr …)
Jitsi-Meet, nginx, Let’s Encrypt und die Zertifikats-Erneuerung
Mittwoch, 21. Oktober 2020
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. (mehr …)
Mumble-Server (murmurd) auf Debian Jessie
Donnerstag, 10. August 2017
Weil wir schon grad bei neuen Diensten sind … dieser Tage hatte ich der DinLUG – Dinslakener Linux User Group Hosting zugesagt. Und zwar nicht nur das Blog, sondern auch einen Mumble-Server. Letzteres interessierte mich auch selbst, deshalb habe ich zugesagt, einen solchen zu installieren.
Mumble ist eine freie Sprachkonferenzsoftware, die sich wegen niedriger Latenzzeit und guter Audioqualität für alle Arten von Audio-Konferenzen eignet. Die Verbindungen zwischen Server und Client sind dabei grundsätzlich verschlüsselt.
Die Installation ist weniger kompliziert, als ich befürchtet hatte:
:~$ apt-get install mumble-server
– und dann ist schon alles da. Die Konfiguration erfolgt über eine einzelne Datei, nämlich /etc/murmur-server.ini, die auch nicht sonderlich umfangreich ist. Aber natürlich gibt es auch Fußangeln, sonst wäre ja alles zu einfach. (mehr …)
OwnCloud mit nginx und MariaDB auf Debian Jessie
Dienstag, 8. August 2017
Ja, ich könnte für Dateien, die ich einzelnen Personen oder Gruppen weitergeben will, einen FTP-Server aufsetzen. Die mochte ich aber noch nie. Oder, wie ich es die letzten Jahre gemacht habe, weiterhin die jeweilige Datei in ein temporäres Verzeichnis auf meinen Webserver schieben und dann den Link weitergeben. Aber irgendwie ist das so noch nicht das Wahre. Außerdem hoste ich noch jemanden, der auch so eine Datei-Austausch-Möglichkeit braucht, aber nicht mit einer Shell umgehen kann. So landete ich schließlich bei OwnCloud.
(Ob das die optimale Webanwendung für meinen Fall ist, NextCloud oder Seafile vielleicht besser wären usw., diskutiere ich hier nicht; das soll jeder für sich selbst entscheiden.)
Die in der Überschrift genannte Kombination ist allerdings etwas tricky; ich suchte und probierte jedenfalls ein paar Stunden lang herum, bis alles lief, und dabei unterliefen mir auch noch so ein paar eigene Fehler. Das waren die Haken: (mehr …)
Let’s Encrypt!, nginx und WordPress
Dienstag, 21. Februar 2017
Es ist wirklich schade, daß CAcert mit seiner Assurance-Policy es immer noch nicht geschafft hat, in die CA-Listen der großen Browser zu kommen. Ich benutze die Zertifikate von dort immer noch – zum Beispiel in meinem Mailserver, wo nur wenige User mit draufhängen, denen ich noch problemlos einzeln erklären kann, warum ihre Software vielleicht anfangs wegen des Zertifikats meckert. Aber für Websites usw. ist es so halt nicht wirklich brauchbar.
„Wir Nerds“ wissen, wo man das passende Root-Certifikat runterziehen kann, aber der Durchschnittsbenutzer wird das eher nicht wissen. Er sieht nur von seinem Browser den Hinweis, daß da Pöhse Dinge™ passieren könnten, wenn er weitermacht, und wird sich dann eher eine andere Informationsquelle suchen. Daher habe ich mich dann letztendlich doch für LetsEncrypt! entschieden, um allgemein alle Websites auch mit ordentlichem https anbieten zu können.
Allerdings stellte sich heraus, daß das im Zusammenhang mit nginx nicht so einfach ist wie mit apache2, und daß der Certbot, den man sich dafür installieren muß, an ein paar Stellen ein wenig pingelig ist. (mehr …)