TL;DR Deutsch
Prüfe die IPv6 Config deines Servers. Let’s Encrypt bevorzugt IPv6 bei der Domain-Validierung, was zu Problemen bei der automatischen Zertifikatserneuerung in FreePBX führen kann, falls IPv6 nicht korrekt konfiguriert ist. Zur Lösung kann man IPv6 in FreePBX manuell konfigurieren, indem man die IPv6-Auto-Konfiguration deaktiviert und eine statische IPv6-Adresse direkt in der Netzwerkkonfigurationsdatei (/etc/sysconfig/network-scripts/ifcfg-<interface>) einträgt. Nach einem Neustart des Netzwerkdienstes sollte die Erneuerung des Let’s Encrypt Zertifikats erfolgreich durchführbar sein. Alternativ ließe sich auch der AAAA-Record entfernen, sodass FreePBX nur per IPv4 erreichbar ist.
TL;DR English
Check your server’s IPv6 config. Let’s Encrypt prefers IPv6 for domain validation, which can lead to problems with automatic certificate renewal in FreePBX if IPv6 is not configured correctly. To solve this, you can manually configure IPv6 in FreePBX by disabling IPv6 auto-configuration and entering a static IPv6 address directly in the network configuration file (/etc/sysconfig/network-scripts/ifcfg-<interface>). After restarting the network service, the Let’s Encrypt certificate should be successfully renewed. Alternatively, the AAAA record could also be removed so that FreePBX is only accessible via IPv4.
Was ist passiert?
Ich betreibe seit einiger Zeit FreePBX und hatte bisher nur gelegentlich Probleme mit dem per Web UI automatischen Let’s Encrypt Prozess in FreePBX, Lösung war dann eigentlich immer innerhalb von ein paar Stunden gefunden und das Zertifikat wurde automatisch erneuert.
Neulich wurde ich dann aber von einer Chrome Warnung empfangen. Die Website verwendet normalerweise Verschlüsselung um meine Informationen zu schützen, hieß es da. Weil HSTS aktiv ist, konnte ich auch nicht einfach auf weiter oder dergleichen klicken, um trotzdem zur Admin-Oberfläche von FreePBX zu kommen. Klar, man könnte einfach die HSTS Settings für die betroffene Website löschen, das war mir aber zu blöd. Also, Inkognito-Tab auf und ab zur Website, abgelaufenes Zertifikat akzeptiert und weiter ging es.
Mein Irrweg zur Ursachenfindung
Soweit so gut. Woran lag es aber nun, dass das Zertifikat nicht abgerufen werden konnte? Ich hatte keinen blassen Schimmer. Das übliche Rumgegoogle brachte zwar dutzende an Threads, dort fand sich dann aber immer eine adequate Problemlösung. Für mich war dieses Mal nichts dabei.
Probiert habe ich das Übliche:
- temporäres komplettes Abschalten der Firewall
- Neustarten der Kiste (hatte mir sonst schon öfter mal geholfen bei Problemen mit dem Abruf von Zertifikaten)
- warten (mehrere Tage, to be exact)
- mehrfach überprüfen, ob die DNS Settings korrekt sind
- Erreichbarkeit des Verification Tokens per Port 80 geprüft
Hat alles nichts gebracht. Hab das Problem dann erstmal für ein paar Tage ad acta gelegt, weil ich erstens nicht jeden Tag mit der FreePBX Web UI zu tun habe und zweitens es mich ja nicht daran hinderte, FreePBX weiterhin normal zu benutzen. Nur durch den reinen Ablauf des Zertifikats wird die Verbindung zum Server nicht unsicher(er).
Fehlersuche. Aber ernsthaft.
Am 27.03.2024 ist es mir dann zu blöd geworden und ich habe mich nochmal rangesetzt. Nervig ist vor allem das Let’s Encrypt Rate Limit von 5 Versuchen/Stunde. Klar, man möchte Missbrauch vorbeugen und 5 Versuche pro Stunde sind eigentlich schon großzügig angesetzt, aber wenn man bei der Fehlersuche ist, kann das schon einschränkend sein.
Weil ich immer noch nicht auf die Ursache gestoßen war, klapperte ich nochmal alles ab, was sich in letzter Zeit an der Config wohl geändert haben könnte. Fündig wurde ich auch direkt. In der Woche zuvor hatte ich meine Domains zu einem neuen Provider umgezogen (bin komplett vom Shared Hosting weg) und im Zuge dessen habe ich auch endlich mal eigene Name Server eingesetzt. Eventuell kommt dazu auch noch ein Beitrag. Eigene DNS Server aufzusetzen war auch ein interessantes Abenteuer…
Ich prüfte also, ob sich wohl an meiner DNS Config etwas geändert haben könnte. Ich schaute mehrfach: A und AAAA Records waren 100 % richtig gesetzt. Die Records wurden auch korrekt von allen drei Name Servern übermittelt, hier sollte es also eigentlich nicht zu Problemen kommen.
Weil mir die FreePBX spezifischen Let’s Encrypt Threads dann irgendwann zu blöd geworden sind, habe ich es mit allgemeineren Let’s Encrypt Threads probiert. ChatGPT von OpenAI, das bisher übrigens oft eine gute Hilfestellung in solchen Angelegenheiten war, hat dieses Mal auf ganzer Linie versagt. Keine Hilfe also. In irgendeinem Hilfethread bin ich dann auf Let’s Debug – ein Tool, das einem mögliche Hindernisse bei der Let’s Encrypt Validierung aufzeigt – gestoßen. Endlich! Kannte ich vorher leider noch nicht und hätte mir wahrscheinlich schon so manch Stunde Fehlersuche ersparen können. Nach ein paar Sekunden warten offenbarte mir Let’s Debug auch schon eine vermutete Fehlerquelle. Der AAAA Record sei über Port 80 nicht erreichbar. {Surprised Pikachu Face hier einsetzen}
Problem: AAAA Record funktioniert nicht
Es dämmerte mir. Im Rahmen des Umzugs habe ich erstmals auch AAAA Records für die Kiste angelegt, vorher war sie lediglich über IPv4 erreichbar. Ich bin also verwundert, prüfe aber nochmal alles in Bezug auf die A und AAAA Records gründlich. Klapper auch nochmal die Einstellungen bei dem Provider ab, bei dem ich meine FreePBX hoste. IPv6 gleich und richtig eingetragen. AAAA Records werden richtig ausgegeben. Hä?
Ich google FreePBX IPv6. Halte ich für unwahrscheinlich, aber kommt die FreePBX Distro eventuell nicht mit IPv6 zurecht? Da heißt es, FreePBX sei perfekt auf IPv6 ausgelegt, alles würde einwandfrei funktionieren.
Ich SSH also auf die Kiste. Glücklicherweise wird man da direkt von den IPs begrüßt, die FreePBX zu haben meint. IPv4 stimmt. Perfekt. IPv6 kommt mir aber merkwürdig vor. Ist offensichtlich eine verbindungslokale Adresse. Aha! Mein FreePBX Server kennt anscheinend seine öffentliche IPv6 nicht. Hätte ich mir eigentlich schon denken sollen. Die Kiste kann die IPv6 offensichtlich per DHCP nicht abrufen, eigentlich typisch für Server, die sich ohne NAT im öffentlichen Netz befinden. Da gibts einfach keinen DHCP Server, der dir hübsch automatisch eine IP zuweist. Ich überlege: Soll ich wieder auf IPv4 only zurück? Wenn ja, warum eigentlich? Ich entscheide mich dagegen. Ich möchte die Kiste auch über IPv6 nutzen können.
Problemlösung: IPv6 Adresse konfigurieren
Ich befrage wieder ChatGPT, wie ich denn auf schnellstem Wege die statische IPv6 dauerhaft einrichten könne.
Je nach Distribution solle ich entweder in die /etc/network/interfaces (Debian, Ubuntu) oder die /etc/sysconfig/network-scripts/ifcfg-<interface> (CentOS, Red Hat) editieren. Ich verwende die FreePBX Distro, basiert also auf CentOS.
Schnell per nano die ifcfg-eth0 geöffnet. Vor Edit sah sie so aus:
TYPE="Ethernet"
PROXY_METHOD="none"
BROWSER_ONLY="no"
BOOTPROTO="dhcp"
DEFROUTE="yes"
IPV4_FAILURE_FATAL="no"
IPV6INIT="yes"
IPV6_AUTOCONF="yes"
IPV6_DEFROUTE="yes"
IPV6_FAILURE_FATAL="no"
IPV6_ADDR_GEN_MODE="stable-privacy"
NAME="eth0"
UUID="1d39469c-ecd0-11ee-a951-0242ac120002"
DEVICE="eth0"
ONBOOT="yes"
ZONE=external
DESCRIPTION="unset"Nach Edit dann so:
TYPE="Ethernet"
PROXY_METHOD="none"
BROWSER_ONLY="no"
BOOTPROTO="dhcp"
DEFROUTE="yes"
IPV4_FAILURE_FATAL="no"
IPV6INIT="yes"
IPV6_AUTOCONF="no" # Auto-Konfiguration deaktiviert
IPV6_DEFROUTE="yes"
IPV6_FAILURE_FATAL="no"
IPV6ADDR="2001:db8:abcd:0012::1/64" # IPv6-Adresse (Beispiel) und Präfixlänge
IPV6_ADDR_GEN_MODE="stable-privacy"
NAME="eth0"
UUID="1d39469c-ecd0-11ee-a951-0242ac120002"
DEVICE="eth0"
ONBOOT="yes"
ZONE=external
DESCRIPTION="unset"Zum big finish noch einmal “sudo systemctl restart network” und jetzt sollte es doch laufen, oder?
Erwartungsvoll in die Zertifikatsverwaltung der Web UI. Neues Let’s Encrypt Zertifikat erzeugen und: Tadaa! Hat geklappt!
Resümee: Hohlmaus am Steuer
Resümierend lässt sich nur sagen: Es saß wieder eine Hohlmaus vor dem Computer. Letztendlich lag es nur an einer inkorrekten IP Config, dass meine FreePBX zwar über IPv4 aber nicht über IPv6 erreichbar war. Zum Thema IPv6 hat Let’s Encrypt auch eine Hilfeseite. Die IPv6 Adresse wird offensichtlich bei der Domain-Validierung bevorzugt. Kein Wunder, dass es bei mir die ganze Zeit nicht geklappt hat.