
Ich hoste eine Webseite mit Apache auf einem Raspberry Pi (Debian) und kann den Server scheinbar nicht dazu bringen, das aktuelle Zertifikat auszustellen. Ich habe ein selbstsigniertes SSL-Zertifikat generiert /home/pi/ssl/
mit:
openssl req -new -sha256 -x509 -nodes -days 365 -out example.com.pem -keyout example.com.key
Apache sucht das .pem
und .key
Dateipaar in der Datei /etc/apache2/sites-enabled/owncloud.conf
, die Folgendes enthält:
SSLCertificateFile /home/pi/ssl/example.com.pem
SSLCertificateKeyFile /home/pi/ssl/example.com.key
Wenn ich diese Dateien lösche und Apache neu starte, erhalte ich die Fehlermeldung [FAIL] Reloading web server config: apache2 failed!
. Dieser Fehler tritt beim Neustart nach der Generierung eines neuen Zertifikatdateipaars nicht auf, Apache scheint also das Zertifikat aufzurufen.
Das Zertifikat, das in den Browsern angezeigt wird (Chrome Incognito oder private Fenster von FF/Safari und sogar ein Browser auf einem Computer, der die Domäne sicherlich nie zuvor angefordert hat), ist jedoch ein altes Zertifikat, das ich vor einem Monat generiert habe – siehe unten:
Irgendwelche Ideen, warum das passiert?
Antwort1
Es stellte sich heraus, dass das ausgestellte Zertifikat aus irgendeinem Grund das standardmäßige Apache-Zertifikat „Snakeoil“ war. Ich stellte dies folgendermaßen fest:
grep -i -r "SSLCertificateChainFile" /etc/apache2/
.. was zwei Zeilen aus der Datei zurückgab /etc/apache2/sites-available/default-ssl
, die auf das Snakeoil-Zertifikat verwiesen. Ich habe diese Zeilen auskommentiert und der Browser gibt jetzt das angepasste Zertifikat zurück.
Antwort2
Eine häufige Ursache für solche Probleme sind mehrere laufende Apache-Instanzen. Die Konfigurationsänderungen werden von einem Prozess übernommen, den Sie (neu) starten, aber die Anforderung wird von einem alten Prozess bedient, der mit einer alten Konfiguration ausgeführt wird.
Beenden Sie den Dienst:
service apache2 stop
Überprüfen Sie, ob die Site noch erreichbar ist. Wenn ja, haben Sie die Ursache identifiziert.
Jetzt lauf
ps aux | grep apache
Sie erhalten eine Liste der laufenden Apache2-Prozesse und ihrer PIDs. Beenden Sie sie alle (Beachten Sie, dass dieser Befehl möglicherweise auch unabhängige Prozesse mit Apache im Namen/Benutzer usw. zurückgibt, wie z. B. Apache Tomcat. Diese möchten Sie möglicherweise nicht beenden.)
kill <pid>
Führen Sie ps aux erneut aus und stellen Sie sicher, dass keine Prozesse mehr ausgeführt werden.
Überprüfen Sie noch einmal, ob auf die Site zugegriffen werden kann. Dies sollte nicht der Fall sein.
Starten Sie nun den Apache-Dienst
service apache2 start
Überprüfen Sie, ob das neue Zertifikat bereitgestellt wird.
Wenn Sie Prozesse nicht beenden möchten, können Sie das System neu starten. Dies hat den gleichen Effekt.