Hi.
Gerade habe ich versucht, per LE ein Zertifikat zu erzeugen. Leider klappte es dann aber doch nicht so wie erhofft.
Konkret: Unsere Domain für Webseite & Co “example.org” liegt auf einem vServer. Intern heißt unser lml-V6.2-Server jetzt “server.intern.example.org”. Nach außen haben wir keine feste IP, sondern nutzen DDNS-Services. Allerdings ist auf dem vServer ein DNS-CName-Eintrag vorhanden, der immer nach “schule.example.org” zeigt. Die Portfreigaben auf Port 80 sind wie in der Anleitung gefordert eingerichtet.
Rufe ich das Script auf, erhalte ich die Meldung:
ERROR: Challenge is invalid! (returned: invalid) (result: {
"type": "http-01",
"status": "invalid",
"error": {
"type": "urn:acme:error:connection",
"detail": "DNS problem: NXDOMAIN looking up A for server.intern.example.org",
"status": 400
},
(natürlich anstelle von “example” mit unserem Domain-Namen). Offensichtlich klappt da also die Verbindung von außen nach innen noch nicht. Ich sehe nur gerade nicht, woran das jetzt scheitert?
Hat einer eine gute Idee?
Michael
dehydrated erzeugt zusammen mit LE eine kryptische Datei und legt die auf deinem Webserver ab
LE holt sich die Datei unter der Adresse http://server.intern.example.org/.well-known/acme-challenge/<kryptische_datei>
Wenn das klappt, hast du LE gegenüber nachgewiesen, dass du den Host kontrollierst, für den du das Zertifikat willst, und LE stelLt dir das Cert aus.
Da dein Server server.intern.example.org schon mal gar keinen DNS Eintrag hat, kann das natürlich nicht klappen.
Hi Frank.
Ich nehme mal an, dass es daran scheitert, dass ich eine zuästzliche Zuordnung auf dem vServer (CName) brauche. Also irgendwas intern.example.org --> DDNS-Anbieter?
Michael
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?
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:
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:
Offenbar 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 …)
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.
;; 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
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
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.
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…
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?
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 …
Die 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:
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 …
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!):
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.
…
