let's Encrypt mit Subdomains bzw. Aliasdomains

speedy8

Member
Hallo,
ich nutze aktuell die neueste Version von ISPConfig (3.1.15) auf meinem Debian9-Server.
Ich bin auch sehr froh, dass zwischenzeitlich Let'sEncrypt-Zertifikate direkt durch ISPConfig unterstützt werden. Leider ist mir kürzlich aufgefallen, dass einige Alias-Domains, welche ich bei mir eingetragen habe, nicht korrekt mit einem Zertifikat versorgt werden.

Und zwar folgendes:

www.meineHauptdomain.de ->Zertifikat funktioniert prima
bilder.meineHauptdomain.de ->als Alias angelegte Domain, die auf ein bestimmtes Verzeichnis verweist

Ich habe hier keine Subdomain angelegt, weil eben in ein Verzeichnis im gleichen Grundverzeichnis verwiesen werden soll, wäre ja bei Subdomain nicht möglich.

Für diese Alias-Domain wurde jetzt aber kein korrektes Zertifikat erstellt, so dass ich bei Aufruf der Seite https://bilder.meineHauptdomain.de entsprechend eine Fehlermeldung über ein falsches Zertifikat erhalte.

Im Netz habe ich einmal gelesen, und hier wurde darüber auch schon einmal geschrieben, und nach der Anleitung sollte ich händisch bzw. über einen Cronjob die Zertifikatserneuerung starten. Mmhh, ich dachte, dass das ISPConfig nun schon kann? Oder müsste ich noch irgendwo Hand anlegen?

Wäre schön, wenn mir hier jemand weiterhelfen kann.

Mfg
 

Till

Administrator
Im Netz habe ich einmal gelesen, und hier wurde darüber auch schon einmal geschrieben, und nach der Anleitung sollte ich händisch bzw. über einen Cronjob die Zertifikatserneuerung starten.

Auf garkeinen Fall! ISPConfig fügt alle Alias und subdomains automatisch zum zertifikat der website hinzu. Wenn dies fehlgeschlagen ist weil z.B. die Aliasdomain noch nicht auf den Server gezeigt hat, dann einfach LE bei der website deaktivieren, speichern, nochmal aktivieren. Sollte es dann imemr noch nicht gehen, dann schau mal ins le log warum er kein zertifikat für die Aliasdomain erhalten hat.
 

speedy8

Member
Hallo Till,
ich habe das mal ausgetestet wie von Dir beschrieben, aber ohne Erfolg.
also ich habe jetzt mal in der letsencrypt.log nachgeschaut, und das liest sich so, als ob vermeintlich der certbot nicht richtig installiert ist, oder?

2019-09-26 23:59:10,934:DEBUG:certbot.main:certbot version: 0.38.0
2019-09-26 23:59:10,935:DEBUG:certbot.main:Arguments: []
2019-09-26 23:59:10,935:DEBUG:certbot.main:Discovered plugins: PluginsRegistry(PluginEntryPoint#apache,PluginEntryPoint#manual,PluginEntryPoint#nginx,PluginEntryPoint#null,PluginEntryPoint#standalone,PluginEntryPoint#webroot)
2019-09-26 23:59:10,980:DEBUG:certbot.log:Root logging level set at 20
2019-09-26 23:59:10,980:INFO:certbot.log:Saving debug log to /var/log/letsencrypt/letsencrypt.log
2019-09-26 23:59:10,981:DEBUG:certbot.plugins.selection:Requested authenticator None and installer None
2019-09-26 23:59:11,126:DEBUG:certbot_apache.configurator:Apache version is 2.4.25
2019-09-26 23:59:12,987:DEBUG:certbot.plugins.disco:No installation (PluginEntryPoint#nginx): Could not find a usable 'nginx' binary. Ensure nginx exists, the binary is executable, and your PATH is set correctly.
Traceback (most recent call last):
File "/opt/eff.org/certbot/venv/local/lib/python2.7/site-packages/certbot/plugins/disco.py", line 130, in prepare
self._initialized.prepare()
File "/opt/eff.org/certbot/venv/local/lib/python2.7/site-packages/certbot_nginx/configurator.py", line 160, in prepare
"Could not find a usable 'nginx' binary. Ensure nginx exists, "
NoInstallationError: Could not find a usable 'nginx' binary. Ensure nginx exists, the binary is executable, and your PATH is set correctly.
2019-09-26 23:59:12,990:DEBUG:certbot.plugins.selection:Single candidate plugin: * apache
Description: Apache Web Server plugin
Interfaces: IAuthenticator, IInstaller, IPlugin
Entry point: apache = certbot_apache.entrypoint:ENTRYPOINT
Initialized: <certbot_apache.override_debian.DebianConfigurator object at 0x7f4d202a7d50>
Prep: True
2019-09-26 23:59:12,992:DEBUG:certbot.plugins.selection:Selected authenticator <certbot_apache.override_debian.DebianConfigurator object at 0x7f4d202a7d50> and installer <certbot_apache.override_debian.DebianConfigurator object at 0x7f4d202a7d50>
2019-09-26 23:59:12,992:INFO:certbot.plugins.selection:plugins selected: Authenticator apache, Installer apache
2019-09-26 23:59:13,001:DEBUG:certbot.main:picked account: <Account(RegistrationResource(body=Registration(status=None, terms_of_service_agreed=None, agreement=u'https://letsencrypt.org/documents/LE-SA-v1.1.1-August-1-2016.pdf', only_return_existing=None, contact=(u'mailto:postmaster@meineDomain.de',), key=Jxxxxx(key=<ComparableRSAKey(<cryptography.hazmat.backends.openssl.rsa._RSAPublicKey object at 0x7f4d22xxf650>)>), external_account_binding=None), uri=u'https://acme-v01.api.letsencrypt.org/acme/reg/4765651', new_authzr_uri=u'https://acme-v01.api.letsencrypt.org/acme/new-authz', terms_of_service=u'https://letsencrypt.org/documents/LE-SA-v1.1.1-August-1-2016.pdf'), c25a6ffa26c62db3f9d0cf56ad7929fd, Meta(creation_host=u'server.meinedomain.de', creation_dt=datetime.datetime(2016, 9, 30, 19, 16, 4, tzinfo=<UTC>)))>
2019-09-26 23:59:13,002:DEBUG:acme.client:Sending GET request to https://acme-v02.api.letsencrypt.org/directory.
2019-09-26 23:59:13,005:DEBUG:urllib3.connectionpool:Starting new HTTPS connection (1): acme-v02.api.letsencrypt.org:443
2019-09-26 23:59:13,680:DEBUG:urllib3.connectionpool:https://acme-v02.api.letsencrypt.org:443 "GET /directory HTTP/1.1" 200 658
2019-09-26 23:59:13,680:DEBUG:acme.client:Received response:
HTTP 200
Server: nginx
Date: Thu, 26 Sep 2019 21:59:13 GMT
Content-Type: application/json
Content-Length: 658
Connection: keep-alive
Cache-Control: public, max-age=0, no-cache
X-Frame-Options: DENY
Strict-Transport-Security: max-age=604800

{
"C5Iqnbxxxxx": "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-09-26 23:59:13,682:DEBUG:certbot.util:Not suggesting name "mail.*"
Traceback (most recent call last):
File "/opt/eff.org/certbot/venv/local/lib/python2.7/site-packages/certbot/util.py", line 275, in get_filtered_names
filtered_names.add(enforce_le_validity(name))
File "/opt/eff.org/certbot/venv/local/lib/python2.7/site-packages/certbot/util.py", line 489, in enforce_le_validity
"Valid characters are A-Z, a-z, 0-9, ., and -.".format(domain))
ConfigurationError: mail.* contains an invalid character. Valid characters are A-Z, a-z, 0-9, ., and -.
2019-09-26 23:59:13,686:DEBUG:certbot.log:Exiting abnormally:
Traceback (most recent call last):
File "/opt/eff.org/certbot/venv/bin/letsencrypt", line 11, in <module>
sys.exit(main())
File "/opt/eff.org/certbot/venv/local/lib/python2.7/site-packages/certbot/main.py", line 1378, in main
return config.func(config, plugins)
File "/opt/eff.org/certbot/venv/local/lib/python2.7/site-packages/certbot/main.py", line 1127, in run
domains, certname = _find_domains_or_certname(config, installer)
File "/opt/eff.org/certbot/venv/local/lib/python2.7/site-packages/certbot/main.py", line 423, in _find_domains_or_certname
domains = display_ops.choose_names(installer, question)
File "/opt/eff.org/certbot/venv/local/lib/python2.7/site-packages/certbot/display/ops.py", line 129, in choose_names
code, names = _filter_names(names, question)
File "/opt/eff.org/certbot/venv/local/lib/python2.7/site-packages/certbot/display/ops.py", line 180, in _filter_names
question, tags=sorted_names, cli_flag="--domains", force_interactive=True)
File "/opt/eff.org/certbot/venv/local/lib/python2.7/site-packages/certbot/display/util.py", line 253, in checklist
force_interactive=True)
File "/opt/eff.org/certbot/venv/local/lib/python2.7/site-packages/certbot/display/util.py", line 179, in input
ans = input_with_timeout(message)
File "/opt/eff.org/certbot/venv/local/lib/python2.7/site-packages/certbot/display/util.py", line 85, in input_with_timeout
raise EOFError
EOFError
2019-09-26 23:59:13,690:ERROR:certbot.log:An unexpected error occurred:

Aus dieser Log ergeben sich für mich folgende Fragen:

1. ist hier irgendwas nicht korrekt installiert, oder woher stammen die Fehlermeldungen?

2. Gibt es denn die Möglichkeit, dass ich alle letsencrypt-Zertifikate deaktiviere, dann alle gespeicherten Zertifikate lösche, und sie nach Aktivieren der Zertifikats-Unterstützung alle wieder herstellen lassen?

Danke.
Mfg
 

Till

Administrator
Scheinbar hjast Du irgendwie mail.* statt einer validen emailadresse in die certbot config bekommen? Hast Du versucht mail.* als alias anzulegen oder sowas?
 

speedy8

Member
Moin Till,
Ja, ich habe für meinen Webmailer seinerzeit eine entsprechende Datei für den Apache erstellt, welche zusätzlich genau die Alias-Eintragung beinhaltete, daß sämtliche vorhandene Domains mit mail.domains.de auf den Webmailer zielten.
OK, werde jetzt Mal den Alias Mail.* Entfernen.
Gibt's in Ispconfig eigentlich zwischenzeitlich eine Möglichkeit, um solche allgemeinen serverseitige Adressen zu verwalten wie eben den Webmailer, das ispconfig-login etc., So daß darüber dann auch die Zertifikate erstellt werden. Diese Dinge beruhen bei mir aus der Vorzeit aus eigenen sites-enable-dateien.

Und ist nur der Alias Mail.* Für die Fehlermeldung verantwortlich?

Mfg
 

speedy8

Member
Hallo Till,
also ich hatte ja am Freitag den Eintrag "alias mail.*" entsprechend gelöscht. Jetzt kommt die eingangs benannte Fehlermeldung nicht mehr. Dafür passiert aber ansonsten nichts.
Ich habe danach im ISPConfig bei den betreffenden Alias-Domains zunächst den Haken gesetzt bei "Nicht in Let's Encrypt Zertifikat aufnehmen" und gespeichert. Danach Haken wieder rausgenommen ... und nichts passierte. Habe dann auch noch einmal die Alias-Domain durch Entfernen des Hakens bei "Aktiv" deaktiviert, gespeichert und danach das ganze Retoure. Aber wenn ich in /var/log/letsencrypt/letsencrypt.log schaue, dann gab es dort keine Veränderung. Der letzte Eintrag lautet konstant

root@meinServer:/# tail -f /var/log/letsencrypt/letsencrypt.log 2019-09-30 03:00:17,932:DEBUG:certbot.cli:Var post_hook=echo '1' > /usr/local/ispconfig/server/le.restart (set by user). 2019-09-30 03:00:17,989:INFO:certbot.renewal:Cert not yet due for renewal 2019-09-30 03:00:17,990:DEBUG:certbot.plugins.selection:Requested authenticator apache and installer apache 2019-09-30 03:00:17,999:DEBUG:certbot.plugins.selection:Selecting plugin: * apache Description: Apache Web Server plugin Interfaces: IAuthenticator, IInstaller, IPlugin Entry point: apache = certbot_apache.entrypoint:ENTRYPOINT Initialized: <certbot_apache.override_debian.DebianConfigurator object at 0x7fab524ef390> 2019-09-30 03:00:18,000:DEBUG:certbot.plugins.storage:Plugin storage file /etc/letsencrypt/.pluginstorage.json was empty, no values loaded 2019-09-30 03:00:18,000:DEBUG:certbot.renewal:no renewal failures

Ich hatte gar nicht gelesen, dass ich hier irgendwelche Plugins im Certbot installieren/einrichten muss?!

Mfg
 

speedy8

Member
Hallo,
habe jetzt wie unter dem Link beschrieben die Einstellungen vorgenommen, den crontab-Job auskommentiert und dann den Befehl
Code:
/usr/local/ispconfig/server/server.sh
als root gestartet.

Das Ergebnis sieht wie folgt aus
Code:
01.10.2019-23:14 - DEBUG - Calling function 'check_phpini_changes' from plugin 'webserver_plugin' raised by action 'server_plugins_loaded'.
01.10.2019-23:14 - DEBUG - Remove Lock: /usr/local/ispconfig/server/temp/.ispconfig_lock
finished.
die LOCK-Datei finde ich aber überhaupt nicht, wenn ich in das angegebene Verzeichnis schaue.
Was meint denn nun die erste Fehlermeldung genau?

mfg
 

Till

Administrator
Erstmal sind das keine Fehlermeldungen sondern Informationen was das programm gerade macht und die 2. Zeile besagt doch dass die Lock datei entfernt wurde, also ist sie natürlich nicht mehr da wenn Du nachher schaust. Die Ausgabe ist so ok, Du scheinst aber LE nicht bei der Webseite aktiviert zu haben bevor Du es aufgerufen hast.
 

mcpsoftworks

New Member
hallo liebe Leute!

Wir habe sehr viele Aliasdomains, die alle an der Hauptdomain angehängt sind. Teilweise fliegen domains raus, die abgelaufen sind, und dann ist das Letsencrypt der hauptdomain nicht mehr aktiviert, worüber sich die Kundschaft dann beschwert. Das ist wie einen Flohzirkus hüten. Kann man nicht das so umprogrammieren, daß die Alias domains gecheckt werden, ob sie auf die ipadresse auflösen korrekt, und sie erst DANN in die -d xxx.domain.xom liste aufnehmen?
Ich musste die validierung abstellen, weil mit der validierung funktioniert es überhaupt nicht.

Habt Ihr da irgendwelche Ideen oder Konfigurationstipps? Eventuell DNS Validierung einbauen so wie im Plesk? (das ist dort recht gut gelöst, habe ich beim letzten Mal gesehen)
LG
Christoph
 

Till

Administrator
Genau dafür ist die Validierung da, sie prüft ob eine Domain auf den server verweist und fügt sie nur dann zum SSL cert hinzu. Habe ich auf allen meinen Servern aktiv und funktioniert überall einwandfrei. Der einzige Fall ind em man die Validierung deaktivieren muss ist wenn Dein Server hinter einem router steht der Zugriffe vom server selbst auf die Domains blockiert wodurch sie sich natürlich nicht validieren lassen. Wenn die Validierung bei dir nicht geht, solltest Du schauen wo das Problem in Deiner config ist und das beheben anstatt die Validierung zu deaktivieren.

Eine simple DNS Abfrage hilft Dir bei LE übrigens nicht, denn diese kann nicht testen ob der LE Token erreichbar ist auf dem server und somit ein LE cert ausgestellt werden kann oder nicht.
 

mcpsoftworks

New Member
Genau dafür ist die Validierung da, sie prüft ob eine Domain auf den server verweist und fügt sie nur dann zum SSL cert hinzu. Habe ich auf allen meinen Servern aktiv und funktioniert überall einwandfrei. Der einzige Fall ind em man die Validierung deaktivieren muss ist wenn Dein Server hinter einem router steht der Zugriffe vom server selbst auf die Domains blockiert wodurch sie sich natürlich nicht validieren lassen. Wenn die Validierung bei dir nicht geht, solltest Du schauen wo das Problem in Deiner config ist und das beheben anstatt die Validierung zu deaktivieren.

Eine simple DNS Abfrage hilft Dir bei LE übrigens nicht, denn diese kann nicht testen ob der LE Token erreichbar ist auf dem server und somit ein LE cert ausgestellt werden kann oder nicht.
Vom Server selbst auf sich selbst? hmmm. Ich bin bei Hetzner ....

Das Problem liegt nicht am Router oder Firewall sondern wir hatten eine Wordpress filematch Regel, und den Zugang zu txt files zu unterbinden, wodurch auch die Validierung verunmöglicht wurde.
Ich konnte es auf dem betreffenden Server mit einer Änderung der Dateiendung von .txt auf .html beheben, allerdings die FilesMatch Korrektur ist besser.

Gäbe es die Möglichkeit explizit *-txt beim acme.-challenge zu erlauben, egal was im Rest vom ghost konfiguriert ist?
 
Zuletzt bearbeitet:

mcpsoftworks

New Member
Vom Server selbst auf sich selbst? hmmm. Ich bin bei Hetzner ....
Um es noch genauer zu sagen: Der Server lebt durch unzählige updates seit 2012... vermutlich der ältest dienende bei uns, mit ca 200 vhosts. Es gibt mittlerweile unzählige neue features, der server hat komplett aufgehört zu funktionieren etc.... Mit Debien 7, dann auf 8 aktualisiert und nun auf 9....
Aber du kannst unsere Konfiguration gern anschauen und eventuelle Probleme für den Panel sammeln und vielleicht auf fixen :) (wir haben NUR Standard Config nach den diversen Howtos). Z.b. hat heut SSL komplett aufgehört zu funktionieren, und der gesamte Apache greift nur noch auf den ersten VHost zu!
 

Werbung

Top