# LetsEncrypt erstellt keine Zertifikate mehr



## pixeluser (23. Dez. 2019)

Hallo,
leider habe ich das Problem das Letsencrypt keine Zertifikate mehr auf meinem System erstellt. 
(Debian Stretch) ISPConfig 3.1.15p2
Erst nachdem ich Skip Lets Encrypt Check aktivert habe wurden wieder Zertifikate erstellt.
Im Debug Log gab es nur die Meldung 
Could not verify domain xxx.yyy.zz, so excluding it from letsencrypt request. 
Allerdings nicht warum. Erst hatte ich mod_python in Verdacht und habe dies gegen mod_wsgi ausgetauscht.
Auch eine Manuelle Installation des certbots hat nicht geholfen.

Erst nach der Deaktivierung der Domainvalidierung lief es wieder. Und nein mein Server steht nicht hinter einem Router sonder ist per öffentlicher IP erreichbar via Strato.

Danke
Jan


----------



## Till (24. Dez. 2019)

Und Du bist sicher dass die in der Meldung genannte subdomain auch wirklich von innen (also vom server selbst) und von außen (also den LE servern) erreichbar ist und dass Du den Pfad den LE sucht nicht per rewriting irgendwie umgeleitet hast?


----------



## pixeluser (24. Dez. 2019)

Ja, bin ich mir ziemlich sicher. Ich nutze den Server für private Webseiten und habe bereits einige Webseiten mit LetsEncrypt im letzten Jahr erfolgreich eingerichtet (Vielen Dank nochmal an dieser Stelle für die tollen HowTos). Die neue Domain ist per DNS genauso eingerichtet worden wie die bestehenden, allerdings hat diesmal die Verifikation fehlgeschlagen. Ich habe zur Kontrolle auch noch eine Subdomain über einen anderen Domainverwalter hinzugefügt. Auch hier hat ist die Verifikation fehlgeschlagen. Getestet habe ich unteranderm mit MXToolBox und mit https://letsdebug.net/ , von beiden Seiten aus war die Domain auf dem richtigen Webserver zuerreichen. 
Angelegt habe ich die Domains ganz normal über das Webinterface innerhalb von ISPCONFIG mit root/admin Rechten. 
Am Anfang hat die Installation von Zertifikaten hervorragend geklappt, die meisten Domains laufen damit ja auch schon über ein Jahr.

@Till danke für dein Hilfe


----------



## florian030 (25. Dez. 2019)

Tendenziell hiflreich wäre es, wenn Du xxx.yyy.zz  mal in Deine reale Domain übersetzen könntest.


----------



## pixeluser (26. Dez. 2019)

www.pixelwasser.de 
Wie genau funktioniert die Verifikation der Domain? Leider gibt die Debugmeldung nicht viel her. 
Danke
Jan


----------



## florian030 (26. Dez. 2019)

Die Verifikation versucht lokal alle Namen zum Server aufzulösen, die in das Zertifikat sollen. zB domain.de und www.domain.de. Wenn Du noch weitere Namen dabei hast, dann auch diese.


----------



## Till (26. Dez. 2019)

Let's encrypt with subdomain website - get no certificate
					

have some websites running with let's encrypt without problems, they are all on domainwit autosubdomain www i.e. webseite domain.com with autosubdomain...




					www.howtoforge.com


----------



## pixeluser (26. Dez. 2019)

Danke, sollte test.txt in dem Verzeichnis bereits enthalten sein? Ich habe das gerade erst anlegen müssen. Die Datei ist von "aussen" erreichbar.

https://www.pixelwasser.de/.well-known/acme-challenge/test.txt


----------



## Till (26. Dez. 2019)

Zitat von pixeluser:


> Danke, sollte test.txt in dem Verzeichnis bereits enthalten sein?


Nein, das erstellst Du mit dem touch Befehl der in meinem Post steht.



Zitat von pixeluser:


> Die Datei ist von "aussen" erreichbar.


Dann dürfte der check nicht fehlschlagen. Teste das bitte mal mittels wget vom server aus, also:


wget http://www.pixelwasser.de/.well-known/acme-challenge/test.txt

und

wget https://www.pixelwasser.de/.well-known/acme-challenge/test.txt


----------



## pixeluser (26. Dez. 2019)

wget http://www.pixelwasser.de/.well-known/acme-challenge/test.txt
--2019-12-26 12:39:21--  http://www.pixelwasser.de/.well-known/acme-challenge/test.txt
Auflösen des Hostnamens »www.pixelwasser.de (www.pixelwasser.de)« … 81.169.176.34

Verbindungsaufbau zu www.pixelwasser.de (www.pixelwasser.de)|81.169.176.34|:80 … fehlgeschlagen: Verbindungsaufbau abgelehnt.

wget https://www.pixelwasser.de/.well-known/acme-challenge/test.txt
--2019-12-26 12:39:38--  https://www.pixelwasser.de/.well-known/acme-challenge/test.txt
Auflösen des Hostnamens »www.pixelwasser.de (www.pixelwasser.de)« … 81.169.176.34

Verbindungsaufbau zu www.pixelwasser.de (www.pixelwasser.de)|81.169.176.34|:443 … fehlgeschlagen: Verbindungsaufbau abgelehnt.


----------



## Till (26. Dez. 2019)

Jetzt weißt Du warum die LE Verifikation nicht geht, irgend was in Deinem setup blockiert den Zugang vom server selbst. Du bist sicher dass da kein Router oder eine externe Firewall vor dem Server installiert ist? Stimmt die IP denn, nicht dass Du eine falsche IP in der lokalen hosts datei des Systems hast?


----------



## pixeluser (26. Dez. 2019)

Danke, laut ifconf ist der Server richtig im Netz.

Allen Anschein nach hat fail2ban zugeschlagen und den die IP intern geblockt. Jetzt kann ich auch wieder per wget auf die Datei zugreifen.


----------



## tintoretto (17. Dez. 2020)

Ich habe ein ähnliches Problem, bei zwei meiner Webseiten (mit ISPconfig angelegt) kann ich kein Let's Encrypt Zertifikat erstellen - offensichtlich aus zwei verschiedenen Gründen. Ich habe den oben beschriebenen Test durchgeführt. Bei der einen (ohne Subdomains) kann ich auf das Testfile per Browser zugreifen, aber nicht mit wget, dort bekomme ich die Fehlermeldung "404 Not Found" siehe Anhang, was habe ich da falsch gemacht?
Die zweite kommt später dran, da muss ich noch etwas überprüfen.


----------



## Till (18. Dez. 2020)

Schau ins access und error.log der Webseite, was genau steht da für den request via wget drin?


----------



## tintoretto (18. Dez. 2020)

Vom externen Rechner aus funktioniert wget normal [212.186.38.74 - - [18/Dec/2020:11:36:31 +0100] "GET /.well-known/acme-challenge/test.txt HTTP/1.1" 200 287 "-" "Wget/1.20.3 (linux-gnu)"], die Fehlermeldung kommt, wenn ich es vom Server aus versuche.


----------



## Till (18. Dez. 2020)

Ist der Server hinter einem NAT Router? Dann musst Du den let's Encrypt check deaktivieren wenn Dein Router den Zugriff blockiert, wie im LE FAQ steht: 









						Let’s Encrypt Error FAQ
					

There are many threads that deal with problems to generate SSL certificates with Let’s Encrypt so I start a FAQ here. Please read the whole post when...




					www.howtoforge.com


----------



## tintoretto (18. Dez. 2020)

Das nehme ich nicht an, zumal die Zertifikaterstellung bei drei der anderen Webseiten klaglos funktioniert hat. Es ist ein VS bei Simplyroot.de, und ich habe eine IPv4 für den gesamten Server, aber zusätzlich 6 separate IPv6 für die einzelnen Webseiten. Soll ich es trotzdem mit deaktiviertem Check probieren?


----------



## Till (18. Dez. 2020)

Ja, versuch es trotzdem mal. wenn es von extern funktioniert, dann sollte das LE cert ausgestellt werden.


----------



## tintoretto (18. Dez. 2020)

Das hat jetzt tatsächlich funktioniert funktioniert, der Haken beim Let's Encrypt SSL bleibt! - Danke für die Hilfestellung und Geduld


----------



## tintoretto (12. Jan. 2021)

Hallo,
Jetzt habe ich endlich die andere Baustelle angehen können:
VServer mit Debian10 (nach Anleitung Perfect Server installiert), ISPConfig 3.2.1:
5 Webseiten, von denen 4 mit Let's Encrypt SSL einwandfrei funktionieren, nur eine macht Schwierigkeiten.
Ich hatte eine Domain xxxx.at, mit ISPconfig angelegt, und dazu eine subdomain nextcloud.xxxx.at als eigene Site, nach der Anleitung "How to install Nextcloud with ISPConfig 3.1" angelegt, das hat zunächst gut funktioniert, auch mit Let's Encrypt-Zertifikaten, einzeln angelegt. Seit Mitte Dezember wurde das Zertifikat als abgelaufen angezeigt und ließ sich nicht erneuern.
Jetzt habe ich, weil auch die Gültigkeit des Zertifikats immer nur für xxxx.at und www.xxxx.at angezeigt wurde, geschlossen, dass ich wahrscheinlich die Subdomain nextcloud als echte Subdomain (nicht als eigenen Eintrag in Sites) anlegen muss, habe sie gelöscht und die neue Subdomain cloud.xxxx.at für Nextcloud angelegt.
Wenn ich jetzt bei den Domain-Einträgen Let's Encrypt SSL anhake, tut es so, als wäre es angelegt worden, aber beim Zugriff auf die Webseite bekomme ich wieder die Meldung, dass das Zertifikat am 14. Dez abgelaufen sei.
Bei den Let's Encrypt Logs kenne ich leider zu wenig aus, um da etwas Schlüssiges herauszulesen. Da kommt dann weiter unten ein Eintrag ticket2.steler.de, den ich mir nicht erklären kann - bin ich da gehackt worden, oder was sonst kann da hin führen?
Ich hänge zum Vergleich die aktuelle letsencrypt.log und die letsencrypt.log.96 vom 26. Okt an, wo für mich bis auf einen alias-Eintrag (für den ich den record nicht im DNS eingetragen hatte) alles gelaufen zu sein scheint.
Wäre sehr dankbar für Hilfe bzw eine Lösungsmöglichkeit.


----------



## tintoretto (18. Jan. 2021)

Jetzt habe ich das gleiche Problem mit dem Zertifikat einer anderen Webseite, die bisher klaglos gelaufen ist - wird als abgelaufen angezeigt und wird nicht erneuert


----------



## Till (18. Jan. 2021)

Haken bei le raus, speichern, haken bei le wieder rein. Und ansonsten, schau ins let's encrypt log. Kann auch einfachs ein dass dein certbot zu alt ist und außerdem haben einige certbot versionen mal ihre eigenen config files zerstört und konnten sie danach nicht mehr lesen. Gibt also alle möglichen Gründe, certbot ist leider keine allzu gute und stabile software.


----------



## tintoretto (18. Jan. 2021)

Das Haken raus und wieder rein habe ich schon probiert, hat in beiden Fällen nicht funktioniert, kannst du eventuell mal reinschauen, auch in die vom letzten Dienstag, ich kenn mich da leider nicht so gut aus.


----------



## Till (18. Jan. 2021)

Prüf bitte einmal ob die Domains im dns wirklich noch auf den richtigen server zeigen. Laut log kommen zugriffe aus dem internet nicht auf dem server an.


----------



## tintoretto (18. Jan. 2021)

Das habe ich mir schon angeschaut, weil ich im Log diesen Eindruck hatte, aber da ist alles richtig eingetragen, soweit ich es beurteilen kann. Auch beim Testzugriff per wget auf ein Textfile
.well-known/acme-challenge/test.txt werden beide Domains richtig aufgelöst.


----------



## tintoretto (18. Jan. 2021)

Wenn ich mit wget vom Server selbst aus versuche zuzugreifen bekomme ich tatsächlich Fehlermeldungen. Obwohl die IPv4 und IPv6 Adressen richtig aufgelöst werden, kommt im einen Fall:
HTTP request sent, awaiting response... 404 Not Found
2021-01-18 21:08:37 ERROR 404: Not Found.

im anderen Fall:
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://ticket2.steler.de [following]
--2021-01-18 21:09:18-- https://ticket2.steler.de/
Resolving ticket2.steler.de (ticket2.steler.de)... 2606:4700:3030::ac43:892e, 2606:4700:3035::6815:1aa
0, 104.21.26.160, ...
Connecting to ticket2.steler.de (ticket2.steler.de)|2606:4700:3030::ac43:892e|:443... connected.
HTTP request sent, awaiting response... 200 OK

Dieser Eintrag war mir auch schon im letsencrypt log aufgefallen, (siehe vergangenen Dienstag), irgendeine Idee, wie ich das beheben kann?

Bei den DNS-Einträgen ist nichts anders angelegt als bei den drei übrigen Webseiten, bei denen alles klaglos funktioniert.


----------



## Till (18. Jan. 2021)

Möglicherweise hast Du irgedwelche rewrite regeln via htaccess angelegt, welche den zugriff von LE verhindern.


----------



## tintoretto (18. Jan. 2021)

In der htaccess ist nichts auffälliges, die schaut gleich aus wie bei allen anderen.
Und die IP 104.21.26.160 ist anscheinend in den USA und hat keine A Einträge.
Meinst du, es bringt etwas, beide Sites im ISPconfig komplett zu löschen und neu anzulegen, und dann die Webseite von einem Backup zurückzuspielen?


----------



## tintoretto (20. Jan. 2021)

Ist eigentlich die Ursache für die Meldung
HTTP request sent, awaiting response... 404 Not Found
2021-01-18 21:08:37 ERROR 404: Not Found.
ein Fehler am eigenen Server oder auf den DNS-Servern?


----------

