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

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

Hallo,

kannst du diesen Namen außerhalb eures Schulnetzes auflösen?

Konkret: Was gibt ein

nslookup server.intern.example.org

zurück, wenn du “irgendwo im Internet” sitzt?

VG

Frank

Nein, klappt nicht -->
server can’t find server.intern.example.org: NXDOMAIN

Dann muss es auf dem vServer zu finden sein, ja?
Intern ist die Einstellung so aber richtig.
Michael

Hallo,

mit der in linuxmuster-dehydratet gewählten Challenge funtioniert LE so:

  • Du sagst in der Konfig: ich will ein Cert für server.intern.example.org
  • 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.

VG

Frank

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

Hallo Michael,

entscheidend ist, dass der DNS-Eintrag beim für Deine Domäne zuständigen
DNS-Server gesetzt ist. Probier mal:

dig example.org NS

(natürlich mit Deiner Domäne), dann siehst Du, welcher DNS-Server das ist.

Auf dem benötigst Du dann je einen Eintrag für den Servernamen, unter
dem Dein Webserver von intern und von extern erreichbar ist.

Das Zertifikat kannst Du für beide Hostnamen ausstellen lassen.

Beste Grüße

Jörg

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: 74

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 …)

Michael

Hallo Michael,

hier sind zwei Nameserver im Spiel:

  1. Der LML-Server für Aufrufe aus dem Schulnetz

Hier sollte die IP-Adresse 10.16.1.1 sein.

  1. 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 :wink:

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 :slight_smile:
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.pem

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:

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

Auswahl_075

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 :frowning:

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