# let's Encrypt mit Subdomains bzw. Aliasdomains



## speedy8 (25. Sep. 2019)

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 (26. Sep. 2019)

Zitat von speedy8:


> 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 (27. Sep. 2019)

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,934EBUG:certbot.main:certbot version: 0.38.0
> 2019-09-26 23:59:10,935EBUG:certbot.main:Arguments: []
> 2019-09-26 23:59:10,935EBUG:certbot.mainiscovered plugins: PluginsRegistry(PluginEntryPoint#apache,PluginEntryPoint#manual,PluginEntryPoint#nginx,PluginEntryPoint#null,PluginEntryPoint#standalone,PluginEntryPoint#webroot)
> 2019-09-26 23:59:10,980EBUG:certbot.log:Root logging level set at 20
> ...


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 (27. Sep. 2019)

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


----------



## speedy8 (27. Sep. 2019)

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 (30. Sep. 2019)

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


----------



## Till (1. Okt. 2019)

Zitat von speedy8:


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


Musst Du ja auch nicht, da keine verwendet werden.

Zum weiteren vorgehen:

https://www.faqforge.com/linux/debugging-ispconfig-3-server-actions-in-case-of-a-failure/


----------



## speedy8 (1. Okt. 2019)

Hallo,
habe jetzt wie unter dem Link beschrieben die Einstellungen vorgenommen, den crontab-Job auskommentiert und dann den Befehl 

```
/usr/local/ispconfig/server/server.sh
```
als root gestartet.

Das Ergebnis sieht wie folgt aus

```
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 (2. Okt. 2019)

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 (12. Dez. 2019)

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 (13. Dez. 2019)

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 (13. Dez. 2019)

Zitat von Till:


> 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?


----------



## mcpsoftworks (13. Dez. 2019)

Zitat von mcpsoftworks:


> 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!


----------



## Till (13. Dez. 2019)

Wenn Du remote Login support für ISPConfig brauchst, dann wende Dich bitte an den ISPConfig Support von Schaal @IT: https://www.ispconfig.org/get-support/?type=ispconfig


----------

