Friedliche Koexistenz zweier Server an einer DynDNS-url / letsencrypt-Problem

[Thörty]

Hallo,

neben meiner DS213plus habe ich am Router einen cubietruck hängen, auf dem eine moodle-Installation zu Test- und Entwicklungszwecken läuft.

Ich möchte jetzt vorübergehend diesen cubie für einige Tage von außen zugänglich machen, damit zwei Kollegen damit arbeiten können. Die DS 213 plus habe ich so eingerichtet bekommen, dass der Zugriff über eine Subdomain möglich ist (cubie.sub.domain.tld).

moodle läßt leider keine logins über http zu, sondern verlangt zwingend https - war bisher nicht nötig, da die Zugriffe bislang immer aus dem internen Netz kamen. Dort scheint diese Beschränkung nicht zu greifen. Beim Versuch dem cubie mittels certbot ein Zertifikat zu verpassen, taucht folgender Fehler auf (domain und IP anonymisiert):

Which names would you like to activate HTTPS for?
-------------------------------------------------------------------------------
1: cubie.sub.domain.tld
-------------------------------------------------------------------------------
Select the appropriate numbers separated by commas and/or spaces, or leave input
blank to select all options shown (Enter 'c' to cancel):
Obtaining a new certificate
Performing the following challenges:
tls-sni-01 challenge for cubie.sub.domain.tld
2017/06/09 12:31:35 [notice] 6976#6976: signal process started
Waiting for verification...
Cleaning up challenges
2017/06/09 12:31:42 [notice] 6979#6979: signal process started
Failed authorization procedure. cubie.sub.domain.tld (tls-sni-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Incorrect validation certificate for tls-sni-01 challenge. Requested 0da740db---***---e4a45d1ec2cb98.acme.invalid from [*** IP ***:443. Received 2 certificate(s), first certificate had names "imap.sub.domain.tld, mail.sub.domain.tld, smtp.sub.domain.tld, sub.domain.tld"

IMPORTANT NOTES:
 - The following errors were reported by the server:

   Domain: cubie.sub.domain.tld
   Type:   unauthorized
   Detail: Incorrect validation certificate for tls-sni-01 challenge.
   Requested
   0da740dbce396a---***---e4a45d1ec2cb98.acme.invalid
   from [*** IP ***]:443. Received 2 certificate(s), first
   certificate had names "imap.sub.domain.tld, mail.sub.domain.tld,
   smtp.sub.domain.tld, sub.domain.tld"

   To fix these errors, please make sure that your domain name was
   entered correctly and the DNS A record(s) for that domain
   contain(s) the right IP address.

Fragen:

• Kann ich das Zertifikat der DS mit vertretbarem Aufwand auch für den zweiten Rechner verwenden? Den eingehenden Traffic (Port 443) auf Port 80 am cubie weiterzuleiten funktioniert nicht (ist ja auch irgendwie logisch).
• Kann ich https an der DS kurzfristig deaktivieren und dann certbot auf dem cubie ausführen, oder gibt das weitere Fehler?
• bin ich völlig auf dem Holzweg? Wenn ja, dann bitte ich um Erleuchtung!

Vielen Dank im Voraus

Thorsten

 

[Fusion]

Die Domains die du in der Anfrage einträgst müssen alle auflösbar und via Port 80/443 erreichbar sein.

 

[Thörty]

Die sind beide auflösbar und erreichbar, nur halt technisch bedingt unter einer gemeinsamen IP. Wenn Letsencrypt dann fragt, drängelt sich die DS vor. Deshalb scheitert certbot.

 

[Fusion]

Kannst du auf dem cubie ein selbst-signiertes Cert installieren?

Oder wenn du einen Reverse Proxy auf der DS schaltest, die als Endpunkt der externen Verbindung mit LE ausgestattet ist und dann per http auf den cubie weitergibt? Dann sollte die Verbindung ja auch von Innen sein, nämlich nur von der DS auf den Cubie.

Wenn beides ausscheidet.
Certbot auf dem cubie, dann muss kurzzeitig 80/443 auf den cubie direkt geleitet werden, weil sonst /.well-known/acme-challenge immer von der DS abgefangen wird.
Oder man muss schauen, welche indirekten Auth Methoden certbot noch kann (TXT records im DNS oder Dateien auf dem webserver, etc, weiß ich grad nicht) die nicht "kompromittiert" sind.

 

[Thörty]

Guten Morgen,

Klar, selbstsigniertes Zertifikat ginge, finde ich aber suboptimal, zumal meine Kollegen nicht so technikaffin sind, als das sie eine Zertifikatswarnung nicht verwirren würde.

Das Weiterleiten von 443 ? 80 funktioniert nicht. Schon ausprobiert.

Nächster Versuch wäe tatsächlich, die DS vorübergehend vom Netz zu trennen und den Traffic direkt auf den Cubie durchzuleiten. Dann sollte es funktionieren. Ich fürchte allerdings, dass ich spätestens bei der ersten Aktualisierung des Zertifikats wieder vor dem gleichen Problem stehen werde.

Vielen Dank, bitte Daumen weiter gedrückt halten ;-)

 

[TheGardner]

Das wird wohl so sein! Sehe auch keine andere Lösung als die DS dann immer für den Moment vom Netz zu nehmen!

 

[Fusion]

@Thörty - was verstehst du genau unter 443 > 80 Weiterleitung?

Mit dem Reverse Proxy kommt die Anfrage von außen auf 443 und wird an der DS terminiert (ob jetzt cubie.nas.domain.de oder cubie.domain.de ist egal, hängt halt von deiner config ab).
Reverse Proxy z.B. cubie.domain.de, https, 443 und Ziel auf 192.168.1.5, http, 80 (oder wo auch immer der Cubie läuft)
Die DS baut dann ihrerseits über http und Port 80 nur im LAN eine Verbindung zum Cubie auf. Spielt also Mittelsmann.
Das sollte für den Cubie wie eine reine lokale Verbindung aussehen und der https Zwang damit entfallen.

Moodle selbst kann ich grad nicht testen, aber die Fritzbox habe ich nach diesem Schema angesprochen und diese präsentiert dann auf dem Login-Schirm die möglichen Nutzer für eine Anmeldung.
Das macht sie auch nur für lokale Verbindungen.

 

[Thörty]

Guten Morgen Fusion, ich möchte nicht so unhöflich sein, Dein Post unbeantwortet zu lassen.

Weiterleitung Port 443 auf Port 80:
Ich habe probiert, den Traffic von Port 443 der Disk Station auf Port 80 des Cubie weiterzuleiten, in der Hoffnung, dass ich die Seite über https://... aufrufen kann, der https-Verkehr auf der DS terminiert wird und sich die DS die Seite dann über http vom cubie holt. Ich denke, dass mir dabei irgendwo ein Fehler unterlaufen ist, denn es hat in der Form nicht funktioniert. Ich habe mir aber nicht gemerkt, welches Problem dabei genau aufgetreten ist, kann es also nicht mehr nachvollziehen.

Ich habe moodle inzwischen davon überzeugen können, auch unsichere Verbindungen zuzulassen. Das ist langfristig immer noch keine Lösung, aber kurzfristig kann ich damit leben.

Vielen Dank für Deine Hilfe!

 

[Fusion]

Wenn moodle inzwischen auch unsichere Verbindungen akzeptiert sollte der Reverse Proxy gleich zweimal funktionieren.
Einzig was da reinspucken könnte ist, wenn irgendein Verkehr eben nicht über den Port läuft den der Reverse Proxy empfängt und weiterleitet.

 

[Thörty]

Ja, das denke ich auch. Ich werde das später auch nochmal ausprobieren.

Ich muss allerdings erst noch ein anderes Problem lösen, bevor sich alle ins Wochenende verdrücken ;-)