Ja, das ist unser vServer – wie es zu erwarten war. Auf dem kann ich (unter PLESK) einstellen, „was immer ich will“. Da ich intern wie extern ja seit vorhin den gleichen FQDN benutze, reicht hier ein zusätzlicher Eintrag, oder?
Hallo Michael,
das ist gut, so kannst Du alles selbst einrichten.
Wenn das Zertifikat nur für einen Servernamen gelten soll, dann reicht
der eine Eintrag.
Viele Grüße
Jörg
Ok, das Problem ist also jetzt auf den vServer verlagert und wird hier so allmählich OT …
Ich habe gerade eine neue Subdomain unter Plesk eingerichtet: intern.example.org. Die DNS-Einstellungen dieser Domain habe ich so eingestellt wie bisher:
*.intern.example.org CNAME unser-DDNS-name.service.com Wenn ich im Browser jetzt intern.example.org aufrufe, erhalte ich eine Dummy-html-Seite des vServers. Das ist schon mal gut.
Wähle ich im Browser server.intern.example.org, wird versucht, nach 10.16.1.1 aufzulösen, was natürlich nicht klappen kann, da das Netz ja nicht nach außen geroutet wird.
Die Befehle von oben liefern jetzt aber immerhin schon mal:
# dig intern.example.org NS
; <<>> DiG 9.8.1-P1 <<>> intern.example.org NS
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61970
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; QUESTION SECTION:
;intern.example.org. IN NS
;; ANSWER SECTION:
intern.example.org. 7200 IN NS server.intern.example.org.
;; ADDITIONAL SECTION:
server.intern.example.org. 3600 IN A 10.16.1.1
;; Query time: 1 msec
;; SERVER: 10.16.1.1#53(10.16.1.1)
;; WHEN: Thu Mar 22 15:34:53 2018
;; MSG SIZE rcvd: 74Offenbar ist die Adresse 10.16.1.1 da falsch bzw so kann die Anfrage nicht dort ankommen, wo sie hingehört. (Falls das hier im Forum zu speziell ist, kann ich auch ein Ticket an den Provider schicken …)
Michael
Hallo Michael,
hier sind zwei Nameserver im Spiel:
- Der LML-Server für Aufrufe aus dem Schulnetz
Hier sollte die IP-Adresse 10.16.1.1 sein.
- Dein vServe für Aufrufe aus dem Internet
Hier muss die IP-Adresse die sein, unter der Dein Schulserver aus dem
Internet erreichbar ist.
Fall a: Du hast eine feste IP-Adresse - die trägst Du im Plesk ein
Fall b: Du hast eine Dynamische IP-Adresse. Dann musst Du folgenden
Eintrag setzen:
server.intern.example.org CNAME dein.dynamischer.hostname
Wenn Du ein “dig server.intern.example.org” absetzt, dann sollte aus dem
Schulnetz die Antwort genau so lauten wie in Deinem Post und von
irgendwo sonst im Internet sollte die öffentliche IP-Adresse geliefert
werden.
Viele Grüße
Jörg
Hallo Jörg.
Ok, wieder einen kleinen Schritt weiter — aber noch nicht am Ziel:
“dig server.intern.example.org”
liefert jetzt immerhin:
;; ANSWER SECTION:
server.intern.example.org. 2737 IN CNAME unser-ddns-name.anbieter.de.
unser-ddns-name.anbieter.de. 36 IN A 178.XXX.YYY.ZZZ (unsere IP)Sieht alles richtig aus, würde ich sagen? nslookup klappt jetzt und ping kommt auch an — aber das dehydrated-Script löst das trotzdem noch nicht auf.
… und ich weiß jetzt auch warum: Unsere Nextcloud drängelt sich da vor! Ich hatte die damals so eingestellt, dass sie sowohl unter http:// als auch unter https:// reagiert und alles automatisch auf https:// umlenkt wird. In der FritzBox habe ich aber nur eine Portweiterleitung für 443 und nicht für Port 80 angelegt. Daher frage ich mich, warum der trotzdem anspringt.
Michael
Hej,
du kannst es machen wie du willst, entscheidend ist, dass die folgende Adresse aus Sicht von Letsencrypt tut:
Beim ersten Mal (oder wenn du kein gültiges Zertifikat (mehr) hast), muss das auch
ohne Umleitung auf 443/SSL unter Port 80 tun. Später ist das dann egal, da lässt sich LE dann auch von 80 auf 443 schicken, um die Challenge zu beantworten, gesetzt den Fall, dass das Zertifikat noch gilt.
Wie du deinen Webserver konfigurierst (oder konfiguriert hast), musst du natürlich irgendwie selber wissen 
VG
Frank
Hi Frank.
Ja, ich denke, dass sich das Problem gerade in Luft auflöst … wenn ich intern mit dig/nslookup arbeite, erhalte ich überall die richtigen Antworten. Gerade habe es aber von einem anderen (externen) Server versucht und dort habe ich dann das NXDOMAIN erhalten. Das bedeutet anscheinend, dass der neue DNS-Eintrag noch nicht überall (insbesondere bei google --> 8.8.8.8) eingetragen ist. Ich warte daher noch etwas und versuche es später nochmal.
Wenn ich die Adresse http://server.intern.example.org/.well-known/acme-challenge/ übrigens lokal auf dem lml-Server mit elinks aufrufe, erhalte ich ein “Empty file.”. Sieht alles gut aus – bis auf die noch fehlende Verbindung von außen nach innen.
Schöne Grüße,
Michael
Hallo Michael,
ist den POrt 80 auf die lmn weitergeleitet?
Wie lautet die Domain der NExtcloud?
Steht die in Rot oder, wie ich vermute, in Orange?
Du könntest das ganze lets encrypt geraffel ja auf der nextcloud laufen
lassen und dann immer das cert auf die lmn kopieren…
LG
Holger
Hi Holger.
Port 80 ist so eingestellt, wie es in der Doku zu linuxmuster-dehydrated steht.
Die VM mit Nextcloud hatte ich seinerzeit auf einem Ubuntu-16-04-Server aufgesetzt — ohne irgendwelche speziellen Domain-Einstellungen. Und ja, das ganze läuft in Orange.
Wenn ich das LE auf dem NextCloud-Server laufen lasse, muss man die Zertifikate aber alle 90 Tage hin- und herbewegen. Das macht es komplizierter. Im anderen Thread wurde das Thema ja auch schon besprochen. Einfacher ist es, wenn der lml-Server es selbst kann, denke ich.
Wenn ich den NextCloud-Rechner doch noch dazu bewegen will, würde ich das dehydrated-Script (ohne linuxmuster- davor) nehmen. Die sonstigen Einstellungen müssten dann aber natürlich passend zum lml-Server sein, damit man das auch verteilen kann. An welchen Stellen (außer /etc/hostname) müsste man dazu denn überall drehen?
Michael
Und wieder etwas später …
Mittlerweile erreiche ich den Server unter Port 80 aus dem Internet. Die default-Seite, die auch in der Schule erscheint, wird angzeigt. Jubel …
Nun habe ich erneut das Script angeworfen:
linuxmuster-dehydrated --cron
# INFO: Using main config file /etc/linuxmuster-dehydrated/config
Processing server.intern.example.org
+ Signing domains...
+ Generating private key...
+ Generating signing request...
+ Requesting challenge for server.intern.example.org...
+ Hook: Nothing to do...
+ Responding to challenge for server.intern.example.org...
+ Hook: Nothing to do...
+ Hook: Nothing to do...
ERROR: Challenge is invalid! (returned: invalid) (result: {
"type": "http-01",
"status": "invalid",
"error": {
"type": "urn:acme:error:connection",
"detail": "Fetching http://server.intern.example.org/.well-known/acme-challenge/mbskngekürztO3yk: Timeout",
"status": 400
},
"uri": "https://acme-v01.api.letsencrypt.org/acme/challenge/Q1gbjgekürzt920524828",
"token": "mbsknIOgekürzt29U3yk",
"keyAuthorization": "mbskgekürzt29U3yk.9MqbIWBPjs",
"validationRecord": [
{
"url": "http://server.intern.example.org/.well-known/acme-challenge/mgekürtz9U3yk",
"hostname": "server.intern.example.org",
"port": "80",
"addressesResolved": [
"178.xxx.yyy.zzz"
],
"addressUsed": "178.xxx.yyy.zzz"
}
]
})Also jetzt ein Timeout? Wieder was neues 
…
Seltsamerweise ist unter /etc/linuxmuster-dehydrated/certs aber sehr wohl etwas angekommen.
-rw------- 1 root root 1683 Mär 22 18:53 cert-1521741219.csr
-rw------- 1 root root 0 Mär 22 18:53 cert-1521741219.pem
-rw------- 1 root root 3243 Mär 22 18:53 privkey-1521741219.pemDie Adresse http://server.intern.example.org/.well-known/acme-challenge/ ist jetzt übrigens von überall aus aufrufbar und liefert “Empty file!”. In dem Verzeichnis unter /var/www/linuxmuster-dehydrated/
befindet sich nur eine index.html-Datei und sonst nichts.
Kann da auch ein Rechteproblem hinterstecken? Mir kommt es so vor, als wenn da nur noch eine winzige Kleinigekeit zum Erfolg fehlt. Kann mir einer den Gefallen tun, und die Datei 000-default unter
/etc/apache2/sites-enabled hier posten? Es sieht für mich danach aus, als hätte der LE-Server keine Rechte, um die Datei im acme-challenge-Verzeichnis abzulegen …
Michael
Hi.
Gerade habe ich es nochmal versucht … ein Rechteproblem ist das doch nicht!
Wenn ich das Script “linuxmuster-dehydrated --cron” anwerfe, wird im Verzeichnis “/var/www/linuxmuster-dehydrated” ein Token abgelegt. Schreibrechte sind also da! Die Datei gehört zwar root:root (richtig??) aber ich kann sie (solange das Script läuft und den Timeout noch nicht gemeldet hat) auch über einen Browser extern abfragen:
http://server.intern.example.org/.well-known/acme-challenge/rQo2gekürztEjjfFyY liefert mir dann den
Inhalte der Datei. Es sieht also alles völlig richtig aus. Die Datei ist auch sofort da – keine Verzögerung.
Sobald das Script den Timeout meldet, wird die Datei wieder gelöscht. Auch in den apache2-error/access-Logs wird nichts ungewöhnliches gemeldet.
Oder kann es sein, dass sich da im Zuge des Umstellung von LE etwas geändert hat?
Seid ihr ganz sicher, dass es bei euch noch funktioniert? Mich wundert weiterhin, dass zwei der drei Dateien ankommen und die dritte die Größe 0 hat …
Schöne Grüße,
Michael
Hallo,
Jepp:
11:45/0 august /etc/cron.daily # linuxmuster-dehydrated -c -x
# INFO: Using main config file /etc/linuxmuster-dehydrated/config
Processing august.qg-moessingen.de
+ Checking domain name(s) of existing cert... unchanged.
+ Checking expire date of existing cert...
+ Valid till May 1 23:37:10 2018 GMT (Longer than 30 days). Ignoring because renew was forced!
+ Signing domains...
+ Generating private key...
+ Generating signing request...
+ Requesting challenge for august.qg-moessingen.de...
+ Hook: Nothing to do...
+ Responding to challenge for august.qg-moessingen.de...
+ Hook: Nothing to do...
+ Challenge is valid!
+ Requesting certificate...
+ Checking certificate...
+ Done!
+ Creating fullchain.pem...
+ Hook: Restarting Apache...
* Reloading web server config apache2 [ OK ]
+ Done!
+ Hook: Nothing to do...
11:46/0 august /etc/cron.daily # date
Fri Mar 23 11:47:14 CET 2018
VG
Frank
Mit Frank (@ironiemix ) habe ich das Problem per PM weiter disktutiert (auch, um problemlos die echten domain-Namen posten zu können). Stand der Dinge ist, dass es offenbar tatsächlich ein Problem gibt – und zwar scheint es daran zu liegen, dass es keinen immer funktionierenden, automatischen Fallback von IPv6 auf IPv4 gibt… genaueres findet sich hier (wobei das Problem dort bereits als “fixed” markiert ist!):
Moin. Ich melde mich auch hier nochmal … in der Hoffnung, dass noch jemand mitliest.
Auch mit einer “echten” Subdomain gibt es hier Probleme … das klappt leider auch nicht wie erhofft. Jetzt habe ich die subdomain intern.example.org angelegt und gar keinen CNAME mehr eingerichtet (weil die Weiterleitung ja nie geklappt hat (Meldung: Timeout – 400)).
Wenn ich jetzt das Zertifikat unter domains.txt einrichten will, z.B. für:
intern.example.org
www.intern.example.org
server.intern.example.org
nextcloud.intern.example.org
opsi.intern.example.org
coova.intern.example.org
(alles in eine Zeile)
wird bei der Erstellung versucht, jeden einzelnen Host auf Port 80 zu erreichen und dort nach /.wellknown/acme-challenge/ gesucht. Das ist natürlich auf diese Weise alles nicht von außen erreichbar, so dass ich auch auf diesem Weg nicht weiterkomme. Wie macht ihr das bzw wieso hat sonst niemand das Problem?
Ach ja: Versuche ich es hingegen mit Wildcards für die gesamte Domain via:
*.intern.example.org intern.example.org > star_intern_example_org
wird gemeldet, dass das nicht via http_01 sondern nur via dns_01 geht … damit komme ich dann allerdings erst recht nicht weiter 
Alles was ich brauche ist (falls das so überhaupt möglich ist):
EIN Zertifkat für *.intern.example.org, das ich dann überall hinkopieren kann, wo ich es brauche… hatte nicht erwartet, dass das so ausartet.
Schönen Gruß,
Michael
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
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!