Ispconfig + LE

[nowayback]

Moin,

nun muss ich doch mal nachfragen... Ich habe folgende Konstellation:
OS: Debian 9
ISPConfig: 3.1.11
5 betroffene Domains, alle Domains haben 3-5 DNS Server von denen alle gültige und richtige Daten liefern, sowohl IPv4 als auch IPv6 bei denen es konfiguriert ist.
Diese Domains zeigen auf unterschiedliche öffentliche statische IPs unter denen die Websites auch erreichbar sind und sein sollen.
Die lokale Auflösung auf dem Server funktioniert auch.
Getestet wurden die Domains und mit und ohne www.
Nun sind wiederholt einige Lets encrypt Zertifikate nicht erneuert worden und ich habe mich mal auf die Suche gemacht.

Problem 1: im Log von LE passierte gar nichts. Seltsam aber es gibt ja Debug... Debug sagte folgendes:

06.03.2018-21:43 - WARNING - Could not verify domain example.com, so excluding it from letsencrypt request.
06.03.2018-21:43 - WARNING - Could not verify domain www.example.com, so excluding it from letsencrypt request.
06.03.2018-21:43 - WARNING - Let's Encrypt SSL Cert for: example.com could not be issued.

Kurz ne Runde durch die Plattform geguckt und siehe da... ISPConfig ist schuld. Also ab ins Interface und den Check geskippt.
Frage: Warum ist dies hier erforderlich? Warum schafft ISPConfig es nicht, die Domain zu prüfen?

Okay, weiter mit geskippten Check:
Jetzt versuchte ich erneut ein LE Zertifikat zu bekommen, aber auch ohne Erfolg. Log:

06.03.2018-21:57 - DEBUG - Create Let's Encrypt SSL Cert for: example.com
06.03.2018-21:57 - DEBUG - Let's Encrypt SSL Cert domains:  --domains example.com --domains www.example.com
06.03.2018-21:57 - DEBUG - exec: /root/.local/share/letsencrypt/bin/letsencrypt certonly -n --text --agree-tos --expand --authenticator webroot --server https://acme-v01.api.letsencrypt.org/directory --rsa-key-size 4096 --email postmaster@example.com  --domains example.com --domains www.example.com --webroot-path /usr/local/ispconfig/interface/acme
You are running with an old copy of letsencrypt-auto that does not receive updates, and is less reliable than more recent versions. We recommend upgrading to the latest certbot-auto script, or using native OS packages.
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator webroot, Installer None
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for example.com
http-01 challenge for www.example.com
Using the webroot path /usr/local/ispconfig/interface/acme for all unmatched domains.
Waiting for verification...
Cleaning up challenges
Unable to clean up challenge directory /usr/local/ispconfig/interface/acme/.well-known/acme-challenge
Failed authorization procedure. example.com (http-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching http://example.com/.well-known/acme-challenge/O8HzHI0jRzEwFfWAkPxorFMQbaids_pEIqRPgXytZC8: Timeout, www.example.com (http-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching http://www.example.com/.well-known/acme-challenge/YeAk4mX5oCUDNBQJUcVJmdaez4KBpfrvSuNYQQzlisE: Timeout
06.03.2018-21:57 - DEBUG - Let's Encrypt Cert config path is: /etc/letsencrypt/renewal/example.com.conf.
06.03.2018-21:57 - WARNING - Let's Encrypt SSL Cert for: example.com could not be issued.
06.03.2018-21:57 - WARNING - /root/.local/share/letsencrypt/bin/letsencrypt certonly -n --text --agree-tos --expand --authenticator webroot --server https://acme-v01.api.letsencrypt.org/directory --rsa-key-size 4096 --email postmaster@example.com  --domains example.com --domains www.example.com --webroot-path /usr/local/ispconfig/interface/acme
06.03.2018-21:57 - DEBUG - SSL Disabled. example.com

Jetzt seh ich langsam Fragezeichen aufsteigen...
Also mal eine Testdatei angelegt in /usr/local/ispconfig/interface/acme/.well-known/acme-challenge und geguckt ob ich sie via http://www.example.com/.well-known/acme-challenge/test.txt und http://example.com/.well-known/acme-challenge/test.txt erreichen kann... das funktionierte auch, aber http://example.com/.well-known/acme-challenge/test.txt wurde umgeleitet zu http://www.example.com/.well-known/acme-challenge/test.txt was richtig und eigentlich kein Problem sein sollte.

Okay, nochmal Log lesen...

 DEBUG - exec: /root/.local/share/letsencrypt/bin/letsencrypt

O.O Warum in 3 Teufels Namen nimmt er nicht meinen certbot unter /opt/... ? Also nochmal ab durch die Plattform und siehe da:

/usr/local/ispconfig/server/lib/classes/letsencrypt.inc.php:                            $letsencrypt = explode("\n", shell_exec('which letsencrypt certbot /root/.local/share/letsencrypt/bin/letsencrypt /opt/eff.org/certbot/venv/bin/certbot'));
/usr/local/ispconfig/server/lib/classes/cron.d/900-letsencrypt.inc.php:                 $letsencrypt = explode("\n", shell_exec('which letsencrypt certbot /root/.local/share/letsencrypt/bin/letsencrypt /opt/eff.org/certbot/venv/bin/certbot'));

Frage: Warum ist der Hartcodiert?

Das Log weiter durchgeguckt:

You are running with an old copy of letsencrypt-auto that does not receive updates, and is less reliable than more recent versions. We recommend upgrading to the latest certbot-auto script, or using native OS packages.

Würde mein certbot aus /opt/ benutzt werden, gäbe es die Meldung nicht, denn der ist aktuell und bekommt updates.
Frage: Wie ist nun das beste Vorgehen, um den veralteten Krempel loszuwerden und Updatesicher "meinen" certbot zu verwenden?

Außerdem Frage: Warum könnte es certbot nicht schaffen die Domain zu validieren? Mir fällt da einfach nichts brauchbares mehr ein.

Nachtrag:

Select the appropriate numbers separated by commas and/or spaces, or leave input
blank to select all options shown (Enter 'c' to cancel): 5 6
Obtaining a new certificate
Performing the following challenges:
tls-sni-01 challenge for example.com
tls-sni-01 challenge for www.example.com
Waiting for verification...
Cleaning up challenges
Deployed Certificate to VirtualHost /etc/nginx/sites-enabled/100-example.com.vhost for example.com, www.example.com
Deployed Certificate to VirtualHost /etc/nginx/sites-enabled/100-example.com.vhost for example.com, www.example.com

Please choose whether or not to redirect HTTP traffic to HTTPS, removing HTTP access.
-------------------------------------------------------------------------------
1: No redirect - Make no further changes to the webserver configuration.
2: Redirect - Make all requests redirect to secure HTTPS access. Choose this for
new sites, or if you're confident your site works on HTTPS. You can undo this
change by editing your web server's configuration.
-------------------------------------------------------------------------------
Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 2
Redirecting all traffic on port 80 to ssl in /etc/nginx/sites-enabled/100-example.com.vhost
Redirecting all traffic on port 80 to ssl in /etc/nginx/sites-enabled/100-example.com.vhost

-------------------------------------------------------------------------------
Congratulations! You have successfully enabled https://example.com and
https://www.example.com

You should test your configuration at:
https://www.ssllabs.com/ssltest/analyze.html?d=example.com
https://www.ssllabs.com/ssltest/analyze.html?d=www.example.com
-------------------------------------------------------------------------------

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at:
   /etc/letsencrypt/live/example.com/fullchain.pem
   Your key file has been saved at:
   /etc/letsencrypt/live/example.com/privkey.pem
...

Es muss also an dem veralteten certbot unter /root/ liegen. Mit meinem klappt es anstandslos.

Danke und Grüße
nwb

 

[Till]

Frage: Warum ist der Hartcodiert?

Er ist nicht hartcodiert sondern alle von certbot verwendeten Installationspfade werden abgesucht. Und der root pfad ist nunmal der erste der gefunden wird. Der Fehler liegt aber an certbot selbst, denn die Entwickler von certbot waren so schlau beim update ihrer eigenen software das Verzeichnis zu ändern ohne aber die alte version zu entfernen. Benenne mal das Verzeichnis unter root um und versiche es nochmal.

 

[florian030]

Kurz ne Runde durch die Plattform geguckt und siehe da... ISPConfig ist schuld. Also ab ins Interface und den Check geskippt.
Frage: Warum ist dies hier erforderlich? Warum schafft ISPConfig es nicht, die Domain zu prüfen?

ISPConfig ist nicht schuld. Es wird lediglich versucht, lokal die Domain zu erreichen. Wenn das nicht geht, weil Du zB NAT einsetzt, dann ist das ein Setup-Problem. Und genau dafür gibt es ja die Option. Ohne Check kann es Dir nur passieren, dass Du ein Cert für (Sub)Domains anforderst, die nicht erreichbar sind / im DNS eingetragen sind. Und dann will LE nicht.

 

[nowayback]

ISPConfig ist nicht schuld. Es wird lediglich versucht, lokal die Domain zu erreichen. Wenn das nicht geht, weil Du zB NAT einsetzt, dann ist das ein Setup-Problem. Und genau dafür gibt es ja die Option. Ohne Check kann es Dir nur passieren, dass Du ein Cert für (Sub)Domains anforderst, die nicht erreichbar sind / im DNS eingetragen sind. Und dann will LE nicht.

Deswegen schrieb ich extra:

Diese Domains zeigen auf unterschiedliche öffentliche statische IPs unter denen die Websites auch erreichbar sind und sein sollen

Außerdem schrieb ich:

alle Domains haben 3-5 DNS Server von denen alle gültige und richtige Daten liefern, sowohl IPv4 als auch IPv6 bei denen es konfiguriert ist

und:

Die lokale Auflösung auf dem Server funktioniert auch.

Magst du mir bitte deinen Beitrag nun genauer erklären?