Zertifikat für Subdomain mit linuxmuster-dehydrated klappt nicht?

Hallo Michael,

wenn Du Zertifikate von Let’s Encrypt verwenden möchtest, dann musst Du
nachweisen, dass Dir die entsprechenden Domains gehören - da führt
nunmal kein Weg daran vorbei.

Bei einem Wildcard-Zertifikat musst du (jedes mal!) einen Eintrag beim
DNS-Server vornehmen.

Wenn du alle Servernamen im Zertifikat angibst, für die es gelten soll,
dann muss jeder einzelne Server auch aus dem Internet per http(s)
erreichbar sein.

Aber wenn Dir tatsächlich wie in Deinem Beispiel die Domain
intern.example.org” gehört, dann kannst Du doch alle Deine Servernamen
wie nextcloud.intern.example.org etc. im Internet auflösen lassen? Es
kann auch alles auf dieselbe IP-Adresse zeigen, das ist kein Problem.

Beste Grüße

Jörg

Hallo Jörg.
Ja, das hatte ich ja erfolglos versucht (s. oben).

Ich habe den linuxmuster-Server umgestellt auf einen FQDN und auch die Weiterleitung im IPfire eingestellt. Das klappte alles. Per Port 80 wird mir auch die default-Seite des lml-Servers unter http://server.intern.example.org/.well-known/acme-challenge angezeigt. Alles bestens bis hierhin. Leider scheitert es dann am dehydrated-Script, da das Zertifikat aus Gründen, die vermutlich mit IPv6 zusammenhängen, nicht ausgeliefert werden kann. Ich hatte einen CNAME-Eintrag von der Domain intern.example.org auf meinen lml-Server eingerichtet, der auch funktionierte. Ich verstehe nicht ganz, warum es nicht ausreicht, wenn ich nachweise, dass die Domain intern… “mir gehört”. Warum muss dann es dann noch jeder einzelne Client selbst nachweisen?

Schöne Grüße,
Michael

Hallo Michael,

wie das mit dem “dehydrated”-Skript funktioniert weiß ich nicht - ich
mache das so:

https://www.linuxmuster.net/wiki/anwenderwiki:server:ssl-tls-letsencrypt

Dass man für jeden FQDN nachweisen muss, dass man ihn kontrolliert, ist
durchaus sinnvoll, denn es kann immer sein, dass eine Subdomain jemand
anderem gehört. Beispielsweise zeigt “schule-bw.de” auf den
Landesbildungsserver, andererseits haben viele Schulen eine Domain wie
hoelderlin.hd.schule-bw.de

Viele Grüße

Jörg

Hi.
Ja, aber bei mir gehört ja die Subdomain bereits mir. In der nächst darunter liegenden Ebene kommen ja nur noch die Clients, die dann “automatisch” zu dieser Subdomain gehören müssen?!?
Oder gibt es auch noch weiter geschachtelte sub-sub-(sub-sub)-Domains? Wäre mir neu…

Der von dir vorgestellte Weg via Certbot verlangt eine vollständige python-Umgebung. Ich glaube, dass das der Grund war, warum die dehydrated-Lösungen entwickelt wurden: Klein, schlank und nur ein bash-Script.

Aber wenn’s damit besser läuft, würde ich auch das nochmal ausprobieren, doch ich denke, dass es das gründsätzliche Problem auch nicht lösen wird: Wie vorgehen, wenn man EIN Zertifikat für die ganze Subdomäne haben will, ohne jeden einzelnen Client per Port 80 von außen zugänglich machen zu müssen?

Schöne Grüße,
Michael

Hallo Michael,

klar, man kann beliebig viele Sub-Sub-Subdomains konfigurieren.
Technisch gesehen gibt es im DNS-System auch keinen Unterschied zwischen
einem Rechner und einer Subdomain.

Die Dehydrated-Lösung ist in der Tat eleganter, da muss Dir nur jemand
anders helfen, ich kenne mich nicht aus. Auch bei Wildacard-Zertifikaten
mit der DNS-Challange bin ich raus.

Trotzdem weiterhin viel Erfolg!

Beste Grüße

Jörg

Wahnsinn!!! Das Problem ist gelöst … hat mich zwar einiges an Zeit, Nerven und ??? gekostet, aber am Ende lag der “Fehler” mal wieder an einer völlig unerwarteten Stelle: Ich habe im IPFire die Option “GeoIP Block” aktiviert.
So kam es, dass Anfragen aus Amerika von den LE-Servern beblockt wurden und das Zertifikat nie erfolgreich erstellt werden konnte. Ich hatte während der Fehlersuche an sehr vielen Stellen gedreht aber darauf bin ich erst gekommen, als ich die Anfrage ganz offiziell ins LE-Forum geschickt habe und jemand antwortete, der offenbar nicht in .de sitzt: Der konnte den Server nämlich auch nicht erreichen und somit war auch klar, warum das immer wieder in einem Timeout endete … Mann,Mann,Mann … hätte ich natürlich auch früher dran denken können – man muss “nur” drauf kommen! Für alle, die die Option ebenfalls aktiviert haben: Unter GeoIP Block dürfen Anfragen aus US nicht als “zu blocken” aktiviert sein! Dann läuft das auch :slight_smile:

Das Problem ist also tatsächlich endlich gelöst:

./dehydrated --cron
# INFO: Using main config file /home/linuxadmin/www/dehydrated/config
Processing nextcloud.intern.example.org
 + Signing domains...
 + Generating private key...
 + Generating signing request...
 + Requesting new certificate order from CA...
 + Received 1 authorizations URLs from the CA
 + Handling authorization for nextcloud.intern.example.org
 + 1 pending challenge(s)
 + Deploying challenge tokens...
 + Responding to challenge for nextcloud.intern.example.org authorization...
 + Challenge is valid!
 + Requesting certificate...
 + Checking certificate...
 + Done!
 + Creating fullchain.pem...
 + Done!