# Let's Encrypt klemmt



## Tian (18. März 2019)

Hallo,

leider besteht bei mir das Probelm, dass Lets Encrypt auf dem NGINX klemmt. Beim Apache geht es. Es werden auch Zertifikate generiert, nur nicht eingebunden und das Feld ist in ISPC auch nicht angekreuzt.


----------



## Till (18. März 2019)

Siehe FAQ: https://www.howtoforge.com/community/threads/lets-encrypt-error-faq.74179/


----------



## florian030 (19. März 2019)

oder nginx gehört nicht zur gruppe www-data


----------



## stefan_sick (19. Mai 2019)

Hi, ähnliches Problem, deswegen poste ich keinen neuen Thread.
Server läuft schon seit Jahren stabil - mittlerweile Debian 9 mit aktuellem ispconfig und nginx.
Letzte signifikante Veränderung war Debian 8 auf 9 Upgrade im März. Seitdem keine Probleme -auch LE Zertifikate wurden erneuert.
Allerdings ist jetzt das Zertifikat des Servers selbst ausgelaufen und wird nicht mehr automatisch erneuert. Daran hängen neben der ispconfig Admin Oberfläche auch mail und ftp. Also kritisch für die Funktionalität des Servers.

Die FAQ Anleitung https://www.faqforge.com/linux/debugging-ispconfig-3-server-actions-in-case-of-a-failure/ habe ich befolgt ohne eine Fehlerquelle zu finden. Wenn ich im Debug Modus das Skript server.sh manuell starte, ist der Output lediglich "Finished".

Das hier ist der Inhalt des fraglichen renewal Skripts:


```
# renew_before_expiry = 30 days
version = 0.10.2
archive_dir = /etc/letsencrypt/archive/ws01.cetas.pro
cert = /etc/letsencrypt/live/ws01.cetas.pro/cert.pem
privkey = /etc/letsencrypt/live/ws01.cetas.pro/privkey.pem
chain = /etc/letsencrypt/live/ws01.cetas.pro/chain.pem
fullchain = /etc/letsencrypt/live/ws01.cetas.pro/fullchain.pem

# Options used in the renewal process
[renewalparams]
account = 6f23..................................
authenticator = webroot
rsa_key_size = 4096
installer = None
[[webroot_map]]
ws01.cetas.pro = /usr/local/ispconfig/interface/acme
```
Bin für jede Hilfe dankbar


----------



## stefan_sick (19. Mai 2019)

PS: wie hier empfohlen








						Strange letsencrypt problem.
					

Hi to all, i have this strange problem. I have a fresh "The Perfect Server - Debian 9 (Nginx, BIND, Dovecot, ISPConfig 3.1)" installation with 20...




					www.howtoforge.com
				



habe ich ispconfig gestern auf git-stable aktualisiert. Hat nicht geholfen.


----------



## Strontium (19. Mai 2019)

Zitat von stefan_sick:


> Allerdings ist jetzt das Zertifikat des Servers selbst ausgelaufen und wird nicht mehr automatisch erneuert


Vermutlich haben sich die Pfade zum Zertifikat geändert - ich würde das mal überprüfen.


----------



## stefan_sick (19. Mai 2019)

Zitat von Strontium:


> Vermutlich haben sich die Pfade zum Zertifikat geändert - ich würde das mal überprüfen.


Die Pfade passen alle noch.


----------



## nowayback (19. Mai 2019)

/var/log/letsencrypt.log


----------



## stefan_sick (20. Mai 2019)

Der entscheidende Fehler ist wohl: 


```
2019-05-20 03:01:22,427:DEBUG:certbot.reporter:Reporting to user: The following errors were reported by the server:

Domain: ws01.cetas.pro
Type:   unauthorized
Detail: Invalid response from http://ws01.cetas.pro/.well-known/acme-challenge/GrPSVaz-ujTWNf06xmbg18MXxmYiaUA5aA1OyxJN1qw [2a01:488:67:1000:523:ffcd:0:1]: "<html>\r\n<head><title>404 Not Found</title></head>\r\n<body bgcolor=\"white\">\r\n<center><h1>404 Not Found</h1></center>\r\n<hr><center>"

To fix these errors, please make sure that your domain name was entered correctly and the DNS A/AAAA record(s) for that domain contain(s) the right IP address.
```


----------



## Till (20. Mai 2019)

Die Domain ws01.cetas.pro  existiert im DNS und verweist auf die richtige server IP?


----------



## stefan_sick (20. Mai 2019)

Zitat von Till:


> Die Domain ws01.cetas.pro  existiert im DNS und verweist auf die richtige server IP?


 Ja - danke, das ist der Fall. Sonst hätte es ja auch die letzten Jahre nicht funktioniert


----------



## Till (20. Mai 2019)

Hast Du ws01.cetas.pro  als website in ispconfig angelegt, oder hattest Du das cert komplett manuell auf der shell erstellt?

Du kannst die acme challenge mal so testen:

touch /usr/local/ispconfig/interface/acme/.well-known/acme-challenge/test.txt

Du solltest dann im Browser die test.txt Datei so aufrufen können:



			http://ws01.cetas.pro/.well-known/acme-challenge/test.txt
		


denn .well-known/acme-challenge/ aller URL's ist global auf das verzeichnis /usr/local/ispconfig/interface/acme/.well-known/acme-challenge/ gemapped auf ISPConfig servern


----------



## stefan_sick (20. Mai 2019)

ws01.cetas.pro ist in isconfig angelegt als website. Der beschriebene Test funktioniert:


			http://ws01.cetas.pro/.well-known/acme-challenge/a


----------



## Till (20. Mai 2019)

Versuch mal folgendes:


stell sicher dass ein aktueller certbot installiert ist.
Aktualisiere ispconfig auf git-stable (nicht git-master) mit dem ispconfig_update.sh befehl.
in der website ws01.cetas.pro  den haken bei letsencrypt und ssl raus nehmen, speichern, haken bei ssl und letsencrypt wieder setzen und erneut speichern.


----------



## hilfswicht (20. Mai 2019)

Welche IPv6 ist denn in ISPconfig der Website zugewiesen? 
2a01:488:67:1000:523:ffcd:0:1 
Firefox zeigt mir die Domain leider nur über IPv4?


----------



## stefan_sick (20. Mai 2019)

@Till 
gestern alles erfolglos probiert. Heute hat mir Hr. Schaal geholfen. Zertifikat erneuert, aber mir ist nicht klar, was falsch lief. Der Server zeigt noch Fehler zB beim Restart der Services.

@*hilfswicht*
Richtig, die IPv6 ist nur der ws01.cetas.pro zugewiesen, nicht aber den anderen Domains auf dem Server.


----------



## suther (31. Mai 2019)

Da ich auch seit dem letzten Update massive Probleme mit letsencrypt habe, möchte ich mich hier an den Thread mal mit anhängen.

Eine seltsame Sache die mir aufgefallen ist: Die Letsencrypt-Configs (in /etc/letsencrypt/reneval werden alle mit einem Fehler erzeugt.
In der Zeile webroot_path steht nämlich ganz am Ende ein ,
Sieht dann so aus : 
	
	



```
webroot_path = /usr/local/ispconfig/interface/acme,
```
Kann mir jemand ein Tipp geben, wo die configs generiert werden, damit ich den Fehler dauerhaft beheben kann?

Davon abgesehen werden die Zertifikate in meinem Apache auch nicht mehr eingebunden...


----------



## Till (31. Mai 2019)

Die configs generiert certbot selbst, nicht ispconfig. Certbot hat aber leider in den letzten versionen diverse Fehler für die wir dann immer workarounds einbauen mussten. Daher zur Zeit am Besten imemr auf ISPConfig git-stable updatenm, das ist 3.1.13p1 plus bugfixes für 3.1.14


----------



## suther (31. Mai 2019)

Also Version 3.1.13p1 hab ich drauf. Wie spiele ich die Bugfixes für 3.1.14 ein?


----------



## Till (31. Mai 2019)

ispconfig_update.sh aufrufen und 'git-stable' auswählen wenn der updater fragt.


----------



## suther (31. Mai 2019)

Jetzt fragt er mich: 



> Loading SQL patch file: /tmp/update_from_dev_stable.sh.eBWEx65GVg/ispconfig3-stable-3.1-e6bd0a7dfa0abc5dc2b26913c059405ae468a768/install/sql/incremental/upd_d
> Reconfigure Permissions in master database? (yes,no) [no]:


Was soll ich hier (und ggf. bei folgenden Fragen) wählen?


----------



## Till (31. Mai 2019)

Nimm 'yes'.


----------



## suther (31. Mai 2019)

Ok, hab die dev installiert, nun geht es wieder.
Danke @Till.


----------



## juser (24. Juni 2019)

Ich häng mich hier mal mit dran. Ich hab ebenfalle seit einiger Zeit das Problem das die Haken bei SSL und Let's Encrypt nicht gesetzt bleiben. Nicht immer aber immer öfter.
Ich hab momentan ISPConfig 3.1.13 am laufen, muß ich auch auf die dev updaten?


----------



## florian030 (25. Juni 2019)

nimm 3.1.13 p1


----------



## juser (25. Juni 2019)

Hab ich gemacht, die Domain hab ich auch neu angelegt. Aber keine Änderung, die Haken bleiben nicht gesetzt.

Es wird aber jedes Mal wenn ich die Haken setze und auf speichern klicke ein neues Zertifikat erstellt wie ich unter /etc/letsencrypt/archive/ gesehen habe.


----------



## suther (25. Juni 2019)

@juser Ich hatte ja die 3.1.13p1, bei der hat es bei mir nicht funktioniert. Mit der DEV gehts nun.


----------



## Till (25. Juni 2019)

Ja, es muss die dev sein, also ispconfig_update.sh aund dann git-stable als update ziel auswählen. dass ist die 3.1.13p1 plus einige Bugfixes, wie den fix für LE.


----------



## juser (25. Juni 2019)

Nee, hat nicht funktioniert. Haken bleiben immer noch nicht gesetzt. Bei Domain die schon länger im System sind bleiben die Haken gesetzt.
Ich hab jetzt ISPConfig Version: 3.1dev


----------



## Till (25. Juni 2019)

Dann müsstest Du mal den debug mode nutzen um zu sehen warum das so ist.


----------



## juser (25. Juni 2019)

Und das hat mir der Debugger in die Logdatei geschrieben. Wobei ich gesehen habe das als Server nginx ausgegeben wird (in rot und fett), ich hab aber definitiv einen Apache am laufen. Ich kann außer der falschen Serverangabe nur noch unter den einzelen Blöcken die Angabe certbot.errors.CertStorageError: entdecken, sagt mir aber erstmal so nichts.
Vllt. hab ihr mehr Wissen und könnt mir sagen was hier falsch läuft.


2019-06-25 13:04:03,745EBUG:certbot.main:certbot version: 0.28.0
2019-06-25 13:04:03,746EBUG:certbot.main:Arguments: ['-n', '--text', '--agree-tos', '--expand', '--authenticator', 'webroot', '--server', 'https://acme-v02.api.letsencrypt.org/directory', '--rsa-key-size', '4096', '--email', 'postmaster@xx.yyyyy.de', '--domains', 'xx.yyyyy.de', '--domains', 'www.xx.yyyyy.de', '--webroot-path', '/usr/local/ispconfig/interface/acme']
2019-06-25 13:04:03,747EBUG:certbot.mainiscovered plugins: PluginsRegistry(PluginEntryPoint#manual,PluginEntryPoint#null,PluginEntryPoint#standalone,PluginEntryPoint#webroot)
2019-06-25 13:04:03,760EBUG:certbot.log:Root logging level set at 20
2019-06-25 13:04:03,761:INFO:certbot.log:Saving debug log to /var/log/letsencrypt/letsencrypt.log
2019-06-25 13:04:03,762EBUG:certbot.plugins.selection:Requested authenticator webroot and installer None
2019-06-25 13:04:03,763EBUG:certbot.plugins.selection:Single candidate plugin: * webroot
Description: Place files in webroot directory
Interfaces: IAuthenticator, IPlugin
Entry point: webroot = certbot.plugins.webroot:Authenticator
Initialized: <certbot.plugins.webroot.Authenticator object at 0x7fd00ee5acf8>
Prep: True
2019-06-25 13:04:03,764EBUG:certbot.plugins.selection:Selected authenticator <certbot.plugins.webroot.Authenticator object at 0x7fd00ee5acf8> and installer None
2019-06-25 13:04:03,764:INFO:certbot.plugins.selectionlugins selected: Authenticator webroot, Installer None
2019-06-25 13:04:03,774EBUG:certbot.mainicked account: <Account(RegistrationResource(uri='https://acme-v01.api.letsencrypt.org/acme/reg/49746248', new_authzr_uri='https://acme-v01.api.letsencrypt.org/acme/new-authz', body=Registration(agreement='https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf', contact=('mailto:postmaster@dikomm.de',), terms_of_service_agreed=None, status=None, only_return_existing=None, key=JWKRSA(key=<ComparableRSAKey(<cryptography.hazmat.backends.openssl.rsa._RSAPublicKey object at 0x7fd00f026160>)>)), terms_of_service='https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf'), 9750d31c89ca6293a26514af556fddc9, Meta(creation_host='xx.yyyyy.de', creation_dt=datetime.datetime(2019, 1, 18, 9, 23, 5, tzinfo=<UTC>)))>
2019-06-25 13:04:03,776EBUG:acme.client:Sending GET request to https://acme-v02.api.letsencrypt.org/directory.
2019-06-25 13:04:03,782EBUG:requests.packages.urllib3.connectionpool:Starting new HTTPS connection (1): acme-v02.api.letsencrypt.org
2019-06-25 13:04:03,975EBUG:requests.packages.urllib3.connectionpool:https://acme-v02.api.letsencrypt.org:443 "GET /directory HTTP/1.1" 200 658
2019-06-25 13:04:03,976EBUG:acme.client:Received response:
HTTP 200
*Server: nginx*
Content-Type: application/json
Content-Length: 658
X-Frame-Options: DENY
Strict-Transport-Security: max-age=604800
Expires: Tue, 25 Jun 2019 11:04:03 GMT
Cache-Control: max-age=0, no-cache, no-store
Pragma: no-cache
Date: Tue, 25 Jun 2019 11:04:03 GMT
Connection: keep-alive

{
  "_ciyRt5ELKI": "https://community.letsencrypt.org/t/adding-random-entries-to-the-directory/33417",
  "keyChange": "https://acme-v02.api.letsencrypt.org/acme/key-change",
  "meta": {
    "caaIdentities": [
      "letsencrypt.org"
    ],
    "termsOfService": "https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf",
    "website": "https://letsencrypt.org"
  },
  "newAccount": "https://acme-v02.api.letsencrypt.org/acme/new-acct",
  "newNonce": "https://acme-v02.api.letsencrypt.org/acme/new-nonce",
  "newOrder": "https://acme-v02.api.letsencrypt.org/acme/new-order",
  "revokeCert": "https://acme-v02.api.letsencrypt.org/acme/revoke-cert"
}
2019-06-25 13:04:03,989EBUG:certbot.cert_manager:Renewal conf file /etc/letsencrypt/renewal/xx.yyyyy.de-0001.conf is broken. Skipping.
2019-06-25 13:04:03,994EBUG:certbot.cert_manager:Traceback was:
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/certbot/cert_manager.py", line 383, in _search_lineages
    candidate_lineage = storage.RenewableCert(renewal_file, cli_config)
  File "/usr/lib/python3/dist-packages/certbot/storage.py", line 460, in *init*
    self._check_symlinks()
  File "/usr/lib/python3/dist-packages/certbot/storage.py", line 519, in _check_symlinks
    "expected {0} to be a symlink".format(link))
certbot.errors.CertStorageError: expected /etc/letsencrypt/live/xx.yyyyy.de-0001/cert.pem to be a symlink

2019-06-25 13:04:04,002EBUG:certbot.cert_manager:Renewal conf file /etc/letsencrypt/renewal/z3hosting.de.conf is broken. Skipping.
2019-06-25 13:04:04,002EBUG:certbot.cert_manager:Traceback was:
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/certbot/cert_manager.py", line 383, in _search_lineages
    candidate_lineage = storage.RenewableCert(renewal_file, cli_config)
  File "/usr/lib/python3/dist-packages/certbot/storage.py", line 441, in *init*
    "file reference".format(self.configfile))
certbot.errors.CertStorageError: renewal config file {} is missing a required file reference

2019-06-25 13:04:04,029EBUG:certbot.cert_manager:Renewal conf file /etc/letsencrypt/renewal/yy-xxxx.de.conf is broken. Skipping.
2019-06-25 13:04:04,029EBUG:certbot.cert_manager:Traceback was:
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/certbot/cert_manager.py", line 383, in _search_lineages
    candidate_lineage = storage.RenewableCert(renewal_file, cli_config)
  File "/usr/lib/python3/dist-packages/certbot/storage.py", line 441, in *init*
    "file reference".format(self.configfile))
certbot.errors.CertStorageError: renewal config file {} is missing a required file reference

2019-06-25 13:04:04,081:INFO:certbot.renewal:Cert not yet due for renewal
2019-06-25 13:04:04,081:INFO:certbot.main:Keeping the existing certificate


----------



## Till (25. Juni 2019)

Sorry, ich meinte den ispconfig debug mode: https://www.faqforge.com/linux/debugging-ispconfig-3-server-actions-in-case-of-a-failure/ aber das LE log ist auch schonmal nicht schlecht. Das nginx bezieht aich aufd en server von LE, nicht Deinen.

Poste bitte mal die ausgabe von:

ls -la /etc/letsencrypt/live/xx.yyyyy.de-0001/


----------



## juser (25. Juni 2019)

Das Verzeichnis xx.yyyyy.de-0001/ gibt es bei mir nicht.


----------

