Nginx Plugin nicht installiert? So löst du den Certbot-Fehler!

Die Meldung the requested nginx plugin does not appear to be installed wirkt auf den ersten Blick so, als sei Nginx selbst defekt. In der Praxis steckt aber fast immer ein Problem mit der Certbot-Installation, dem Plugin-Paket oder einem gemischten Setup dahinter. Ich zeige dir, wie du den Fehler sauber einordnest, welche Ursachen auf Linux-Servern am häufigsten sind und wie du ihn ohne Rätselraten behebst.

Was die Meldung in Wirklichkeit sagt

Ich trenne diesen Fehler grundsätzlich in zwei Ebenen. Die erste Ebene ist: Certbot hat den Nginx-Installer angefordert, findet ihn aber in der gerade ausgeführten Installation nicht. Die zweite Ebene ist: Das Problem kann auch dadurch entstehen, dass zwar ein Certbot vorhanden ist, aber nicht derjenige, der zu deinem Nginx-Setup passt.

Wichtig ist die Begriffsverwirrung: Das Nginx-Plugin ist ein Certbot-Modul, kein Bestandteil von Nginx selbst. Wenn du also den Befehl certbot --nginx oder certbot certonly --nginx ausführst, erwartet Certbot ein installierteres Plugin, das Konfigurationen lesen, Zertifikate anlegen und Nginx passend anpassen kann. Fehlt genau dieses Modul, kommt die Fehlermeldung zustande.

Die typische Ursache ist deshalb nicht ein kaputter Webserver, sondern ein unvollständiges Paket, eine falsche Paketquelle oder ein Laufzeitumfeld, in dem Certbot den Host-Nginx gar nicht sauber erreichen kann. Genau dort setze ich als Erstes an, bevor ich überhaupt an Zertifikatsdetails denke. Im nächsten Schritt sieht man sich an, welche Ursachen in der Praxis am häufigsten auftauchen.

Die häufigsten Ursachen auf Debian, Ubuntu und in Containern

Der Fehler wirkt ähnlich, aber die Hintergründe unterscheiden sich je nach Umgebung deutlich. Auf klassischen Linux-Servern sehe ich vor allem vier Muster: fehlendes Plugin-Paket, gemischte Installationen, Container-Setups und ein Certbot, der zwar installiert ist, aber nicht aus dem erwarteten Pfad kommt.

Auf Debian und Ubuntu ist das Problem oft banal: Certbot ist da, das Zusatzpaket aber nicht. Auf solchen Systemen heißt das Plugin in der Regel python3-certbot-nginx. Der zweite große Fehler ist das Durcheinander zwischen Paketquellen. Ich sehe regelmäßig Systeme, auf denen ein alter apt-Installationsstand, ein manuell installiertes Python-Paket und ein Snap-Paket gleichzeitig existieren. Dann ist die Fehlersuche fast garantiert unnötig zäh. Im nächsten Abschnitt mache ich die Diagnose deshalb bewusst kurz und praktisch.

So prüfst du in wenigen Minuten, was fehlt

Ich würde immer mit denselben fünf Kommandos starten. Die Reihenfolge ist wichtig, weil du damit zuerst den echten Certbot-Pfad, dann die installierten Plugins und erst danach die Distribution prüfst.

which certbot
certbot --version
sudo certbot plugins
snap list certbot
dpkg -l | grep certbot
rpm -qa | grep certbot

Wenn du in der Ausgabe von sudo certbot plugins kein nginx siehst, ist die Sache ziemlich klar: Das Plugin ist in genau dieser Certbot-Installation nicht vorhanden. Wenn which certbot auf /usr/local/bin/certbot zeigt, du aber eigentlich Snap verwenden wolltest, ist sehr wahrscheinlich die alte Installation im Weg. Und wenn Certbot im Container läuft, Nginx aber auf dem Host, prüfe ich nicht weiter nach Paketnamen, sondern wechsle direkt den Ansatz.

Ein zweiter schneller Check ist nginx -v beziehungsweise nginx -t. Das ist nicht der Haupttest für diese Fehlermeldung, aber er zeigt dir, ob Nginx überhaupt sauber installiert und konfiguriert ist. Wenn Nginx selbst nicht läuft oder die Konfiguration fehlerhaft ist, löst die Plugin-Installation das eigentliche Problem natürlich nicht. Erst wenn dieser Basistest sauber ist, lohnt sich der eigentliche Fix. Genau den gehe ich jetzt nach Installationsweg durch.

Die passende Reparatur je nach Installationsweg

Die richtige Lösung hängt davon ab, wie Certbot auf deinem System installiert wurde. Ich würde nie blind Pakete nachinstallieren, bevor ich sicher bin, dass ich denselben Installationskanal treffe wie die laufende Certbot-Instanz. Sonst reparierst du am Ende das falsche System und der Fehler bleibt unverändert.

Auf Debian und Ubuntu mit apt

Wenn Certbot aus den Systempaketen kommt, fehlt meist nur das Nginx-Zusatzpaket. Dann gehört Certbot und Plugin aus derselben Quelle installiert:

sudo apt update
sudo apt install certbot python3-certbot-nginx
sudo certbot --nginx

Auf aktuellen Debian- und Ubuntu-Versionen ist das die naheliegende Lösung, solange du nicht bewusst auf Snap umgestiegen bist. Ich achte hier immer darauf, dass kein zweites certbot in /usr/local/bin oder aus einem Python-Venv dazwischenfunkt. Falls du schon eine halbfertige Änderung mit --nginx angestoßen hast, kann sudo certbot --nginx rollback helfen, die automatische Konfigurationsänderung wieder zurückzunehmen.

Mit Snap

Wenn du den Snap-Weg gewählt hast, sollte auch das gesamte Certbot-Ökosystem aus Snap kommen. Dann entferne ich zuerst konkurrierende Systempakete, damit nicht das falsche Binary ausgeführt wird:

sudo apt remove certbot
sudo snap install --classic certbot
sudo ln -s /snap/bin/certbot /usr/local/bin/certbot
sudo certbot --nginx

Der Vorteil von Snap ist aus meiner Sicht vor allem die saubere Abgrenzung: ein klarer Installationspfad, weniger Paket-Mix, weniger Überraschungen bei Updates. Wenn dein Server ohnehin auf systemd basiert, ist das oft der robusteste Weg. Entscheidend ist nur, dass du nicht parallel noch ein apt- oder pip-basiertes Certbot verwendest.

Lesen Sie auch: Apache selbstsigniertes Zertifikat - So geht's richtig!

Mit Pip, Virtualenv oder Docker

Bei pip oder einer virtuellen Umgebung muss das Nginx-Plugin in dieselbe Umgebung installiert werden wie Certbot selbst. Dann kann ein Setup so aussehen:

python3 -m venv /opt/certbot-venv
source /opt/certbot-venv/bin/activate
pip install certbot certbot-nginx
certbot --nginx

Bei Docker würde ich mit dem Nginx-Installer nicht gegen die Wand laufen wollen. Die Certbot-Dokumentation weist darauf hin, dass die Installer-Plugins aus dem Container heraus den Host-Webserver nicht erreichen. In der Praxis heißt das: Für Container-Setups ist --nginx meist der falsche Hebel. Nimm lieber webroot, standalone oder gleich DNS-01, je nachdem, wie dein Stack aufgebaut ist.

Wenn du an diesem Punkt den direkten Fix aufgesetzt hast, ist die wichtigste Frage noch nicht erledigt: Ist --nginx überhaupt die richtige Methode für deinen Fall? Genau das ordne ich im nächsten Abschnitt ein.

Wann ein anderer Weg sinnvoller ist als das Nginx-Plugin

Ich nutze das Nginx-Plugin gern, aber nicht dogmatisch. Es ist praktisch, wenn Certbot direkt auf dem Server läuft, Nginx bereits produktiv bedient und du eine automatische Anpassung der Konfiguration willst. Es ist aber nicht die beste Wahl, wenn du Container verwendest, wenn du Wildcard-Zertifikate brauchst oder wenn du den Webserver bewusst nicht anfassen möchtest.

Für Wildcards ist die Entscheidung übrigens ziemlich klar: Dafür ist das Nginx-Plugin nicht gedacht, weil dafür DNS-Validierung nötig ist. Wenn du also *.example.de absichern willst, gehe ich gar nicht erst über --nginx, sondern direkt über DNS-01. Dasselbe gilt oft für Umgebungen mit Load Balancern, Containern oder strengen Firewall-Regeln. Der saubere Weg ist dann nicht der vermeintlich bequemste, sondern der, der später verlässlich erneuert werden kann. Genau deshalb lohnt sich am Ende noch ein Blick auf die Stabilität des gesamten Setups.

So bleibt die Zertifikatsverwaltung stabil

Wenn der Fehler einmal behoben ist, würde ich mich nicht darauf verlassen, dass es beim nächsten Lauf schon wieder gutgeht. Die meisten Probleme kommen zurück, weil jemand später das Installationsmodell ändert, ein zweites Certbot-Paket nachzieht oder die automatische Erneuerung nie getestet hat. Ich halte deshalb drei Dinge für entscheidend: ein Installationsweg, ein Plugin-Set und ein getesteter Renew-Check.

• Halte Certbot und sein Nginx-Plugin aus einer Paketquelle.
• Prüfe nach jeder Änderung mit sudo certbot renew --dry-run, ob die automatische Verlängerung funktioniert.
• Sichere Nginx-Konfigurationsdateien, bevor du mit --nginx produktiv arbeitest.
• Kontrolliere nach dem Zertifikatslauf mit nginx -t, ob die Konfiguration noch gültig ist.
• Wenn du mehrere Webserver oder Container orchestrierst, plane von Anfang an mit DNS-01 statt mit einem Host-Plugin.

Mein praktischer Rat ist schlicht: Wenn du auf einem normalen Linux-Server arbeitest, bring Certbot und das Nginx-Plugin in denselben Installationspfad, prüfe mit certbot plugins, ob nginx wirklich geladen ist, und teste danach die Erneuerung einmal manuell. So wird aus der Fehlermeldung kein Dauerproblem, sondern ein kurzer Hinweis auf ein sauberes Setup, das im Alltag ruhig weiterläuft.