allsky-rodgau.de

Nach einem Update von indi‑allsky passiert es häufig, dass plötzlich wieder das lokale Self-Signed-Zertifikat (z. B. allsky.local) verwendet wird, obwohl zuvor ein gültiges Let’s-Encrypt-Zertifikat eingerichtet war. Wie das geht erkläre ich an anderer Stelle!

Ursache ist fast immer, dass die Update-Routinen die Apache-Konfiguration des Systems verändern oder zurücksetzen. Dieser Beitrag zeigt, wie man das Problem erkennt, sauber behebt und das Setup so gestaltet, dass es auch zukünftige Updates übersteht.

1. Problemursache: indi‑allsky überschreibt die Standard-Apache-Konfiguration

indi‑allsky legt bei der Installation eine eigene Apache-Konfigurationsdatei an, typischerweise:

/etc/apache2/sites-available/indi‑allsky.conf

Diese Datei wird bei Updates gelegentlich überschrieben oder erneut aktiviert. Da sie standardmäßig auf ein Self-Signed-Zertifikat verweist, fällt Apache nach einem Update auf dieses Zertifikat zurück. Zusätzlich ist die Datei alphabetisch weit vorne und wird daher bei Port 443 häufig als „Default VirtualHost“ geladen.

2. Diagnose: Welcher VirtualHost ist aktiv?

Ein schneller Blick zeigt, welcher Host tatsächlich das Zertifikat bereitstellt:

sudo apachectl -S

Die Ausgabe sollte bei einem funktionierenden Setup z. B. zeigen:

*:443 access.allsky-rodgau.de (/etc/apache2/sites-enabled/000-access.allsky-rodgau.de.conf)

Wenn dort stattdessen localhost oder indi‑allsky.conf steht, nutzt Apache nicht das gewünschte Zertifikat.

3. Eigene Domain-Konfiguration anlegen und priorisieren

Am stabilsten ist es, eine eigene Apache-Datei anzulegen, die indi‑allsky nicht überschreiben kann. Beispiel:

sudo cp /etc/apache2/sites-available/indi‑allsky.conf \
        /etc/apache2/sites-available/000-access.allsky-rodgau.de.conf

Dann in dieser neuen Datei die beiden SSL-Pfade auf Let’s Encrypt umstellen:

SSLCertificateFile /etc/letsencrypt/live/access.allsky-rodgau.de/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/access.allsky-rodgau.de/privkey.pem

Zusätzlich sollte ein eindeutiger ServerName gesetzt werden:

ServerName access.allsky-rodgau.de

Die neue Datei aktivieren:

sudo a2ensite 000-access.allsky-rodgau.de.conf
sudo systemctl reload apache2

4. Die alte indi‑allsky.conf deaktivieren

Damit Apache das Self-Signed-Zertifikat nicht mehr verwendet:

sudo a2dissite indi‑allsky.conf
sudo systemctl reload apache2

Nach der Deaktivierung zeigt apachectl -S nur noch die eigene Domain als aktiven SSL-Host.

5. Exkurs: Warum das Entfernen von „Listen“-Direktiven wichtig ist

Ein häufiger Fehler besteht darin, dass in indi‑allsky.conf eigene Listen-Direktiven enthalten sind, z.B.:

Listen [::]:443
Listen [::]:80

Apache definiert diese Ports jedoch bereits in:

/etc/apache2/ports.conf

Wenn die Listen-Direktiven doppelt vorkommen, führt das beim Neustart zu Fehlern wie:

Cannot define multiple Listeners on the same IP:port

Lösung: Alle Listen-Zeilen aus indi‑allsky.conf entfernen oder auskommentieren. VirtualHosts benötigen nur Blöcke wie:

<VirtualHost *:443> ... </VirtualHost>

Die Ports selbst werden nicht im vHost geöffnet.

6. Neustart und Funktionsprüfung

Nach jeder Änderung empfiehlt sich:

sudo apachectl configtest
sudo systemctl reload apache2
sudo apachectl -S

Danach sollte wieder das Let’s-Encrypt-Zertifikat unter der gewünschten Domain erscheinen.

7. Anfragen via http auf https:// weiterleiten

Damit Anfragen über http:// korrekt verarbeitet werden, benötigt Apache einen eigenen VirtualHost für Port 80. Ohne diese Definition landet der gesamte unverschlüsselte Traffic im Standard-Host „localhost“, was zu unerwartetem Verhalten und fehlenden Weiterleitungen führen kann. Erst durch einen expliziten VirtualHost erkennt Apache, dass auch unverschlüsselte Anfragen zu access.allsky-rodgau.de gehören. Ein sauber konfigurierter Port-80-Block sorgt dafür, dass alle HTTP-Requests zuverlässig auf HTTPS umgeleitet werden. Der Block sieht in der Praxis bei mir so aus:

<VirtualHost *:80>
    ServerName access.allsky-rodgau.de
    Redirect permanent / https://access.allsky-rodgau.de/
</VirtualHost>

Diese Weiterleitung stellt sicher, dass sämtliche Zugriffe – unabhängig davon, ob Nutzer oder Dienste zunächst HTTP verwenden – automatisch im verschlüsselten Bereich landen.

8. Optional: Hardening gegen zukünftige Updates

Um das Setup robuster zu machen, ohne Paketupdates zu beschädigen, gibt es zwei sinnvolle Maßnahmen:

Option A: indi‑allsky.conf entschärfen

echo "# disabled by admin" | sudo tee /etc/apache2/sites-available/indi‑allsky.conf

Wenn diese Datei versehentlich wieder aktiviert wird, verursacht sie keinen Schaden.

Option B: Höhere Priorisierung der eigenen Konfiguration

Apache lädt VHosts alphabetisch. Eine Datei, die mit 000- beginnt, wird immer bevorzugt. Dadurch bleibt der eigene VirtualHost auch dann dominant, wenn indi‑allsky bei Updates neue Dateien ablegt.

Hinweis: Das Setzen von chattr +i auf Konfigurationsdateien ist zwar möglich, führt aber unter Umständen zu Fehlermeldungen bei zukünftigen Paketupdates. Für produktive Systeme empfehle ich diese Methode daher nicht.

Fazit

Durch das Auslagern der SSL-Konfiguration in eine eigene Datei, das Setzen eines eindeutigen ServerName und das Deaktivieren der indi‑allsky-Standardkonfiguration lässt sich sicherstellen, dass Apache dauerhaft das richtige Let’s-Encrypt-Zertifikat nutzt. Die Kombination aus priorisierter Datei und der Entfernung überflüssiger Listen-Direktiven sorgt dafür, dass auch zukünftige Updates das Setup nicht unbeabsichtigt verändern.