Auf unserem, über eine öffentliche IP erreichbaren Server an der Schule (dort: Proxmox, Linuxmuster,…) läuft ein selbst geschriebenes PHP-Script, das unsere dorthin hochgeladenen UNTIS-Exportdateien des Vertretungsplan parst und jeweils, je nach Endgerät, verschieden darstellt.
(Das Ganze in einer VM mit seit Wochen problemlos laufenden https - apache - Vhost und eingetragener Domain, so etwas wie „vertretungsplan.schuldomain.de“).
ABER: Aufgrund von Sicherheitseinstellungen unserer Verwaltungscomputer / der Netze der Verwaltung kann mein Vertretungsplan-Kollege aber die Exportdatei nicht auf diesen Host hochladen. Denn der oben erwähnte Proxmox ist mit seiner öffentlichen IP nicht „erlaubt“.
Also habe ich eine Umleitung gebastelt:
Auf einem weiteren Server (V-Server), der unsere Homepage enthält, habe ich die Vertretungsplan-Domain angelegt, die Letsencrypt-Zertifikate erstellt, das „renew“ eingerichtet. Dann eine Weiterleitung eingerichtet (ProxyPass und ProxyPass-Reverse) auf den Server in die Schule.
Dort habe ich tatsächlich - obwohl ja der Host physisch / per IP ein ganz anderer ist - erfolgreich die Letsencrypt-Zertifikate beantragt, eingerichtet - LÄUFT ! Diesen V-Server benutze ich also nur als Sprungbrett.
Eine Zeitlang habe ich dann auf beiden Hosts problemlos die Zertifikate erneuern können.
Jetzt auf einmal meldet aber der certbot auf dem Schulserver einen Fehler 401:
Invalid Response, unauthorized, Fehler 401, findet die .well-known/acme-challege/Buchstabensalat nicht.
Auch mit einem --webroot und genaueren Einstellungen wiederholt sich der Fehler.
Nun die Frage, ob ich hier vielleicht einen ganz anderen Weg gehen sollte und es auf technisch andere Weise schaffe, von dem „Sprungbrett“ verschlüsselt auf unseren Schulserver weiterzuleiten ?
Öhm… für mich wäre die Frage, warum es „nicht erlaubt“. Liegt das an der unsignierten Verbindung?
Könnte es sein, dass Port 80 nicht mehr offen ist?
Über welchen weg werden die Untis-Dateien dort hoch geladen? 443 Https?
Abhängig davon welche Vorraussetzungen es gibt, könnte man auch die beiden Hosts (ggf. eindirektion) Miteinader verbinden.
Sonst halt, abhängig von der SVN-Umgebung, könnte man vielleicht auch über ssh oder scp die Dateien hochschieben.
Wenn das alles aus Netzwerksicht nicht möglich ist, gibt es sicher jemanden, der ein Dropbox-Artiges Programm geschrieben hat, dass dann per HTTPS erreichbar gemacht werden kann.
P.S.:
vielleicht ist auch etwas wie XIBO eine Option in diesem Kontext, könnte viele Probleme abnehmen.
Nee, als Bestandteil des so genannten „Pädagogischen Netzes“ trennen die Leute von der Stadt hier das Verwaltungsnetz komplett ab und erlauben keinerlei Netzwerkverkehr von einem zum anderen.
Doch, ist offen.
Ja, und klappte bislang auch problemlos.
Genau. Ich glaub, ich mach das cronmäßig mit einem scp-Script.
Wollte aber mal wissen, ob Ihr Profis noch eine andere Lösung kennt, oder wisst, wie man verschlüsselte Weiterleitungen auf andere Hosts im Zusammenhang mit Zertifikaten professionell managed!
Wie kommen die Clients ins Internet? Über einen Proxy oder sind manche Ports offen?
Könntest du etwas genauer sein :-)?
Puh, also ich spreche jetzt nur für mich: wir kommen gar nicht erst in ein solches Dilemma. Entweder wir können unser Firewalling so machen, dass es passt und man vom einen Netz ins andere Rüber kopieren kann - oder wir setzen und halt eine Freigabe für SFTP oder was wir brauchen :/.
Für die Weiterleitung, könnte man einen NGINX-Proxy-Manager in Betrieb nehmen. Weiß aber nicht, in wie weit das dein konkretes Problem löst. Prinzipiell würde ich hier meinen Zeiger so setzen, wie ich Ihn brauche.
Fallbezogen wäre XIBO eine gute Möglichkeit für die Anzeige der Vertretungspläne.
hoffe ich konnte dir etwas nützlich sein :-).
Timo
wir hatten vor Kurzem beim Erneuern ein ähnliches Problem, aber da lag es einfach an fehlenden Updates von letsencrypt. Klingt bei deinem Thema irgendwie zu einfach, aber hast du das schon geprüft?
schonmal versucht certbot --standalone zumachen und vorher die entsprechenden Ports freimachen und den Webserver mal kurz ausschalten? ich mein, wenn der das Eintrag auflöst, muss ja certbot funktionieren und ein Zertifikat erstellen dass öffentlich akzeptiert wird. sollte doch egal sein wozu den server da genau verwendest… proxy usw…
aber ja ist natürlich etwas sinnfrei, wenn der direkte Zugang zum netz auf lokaler ebene aus datenschutzgründen verboten wird und dann die Daten durchs Internet geschickt werden, als ob das irgendwie besser wäre (kein Vorwurf an dich)… aber jo… ich verstehe schon so ist das halt mit so Regelungen…
so …
Es ist verrückt, aber - trotz der ganzen Fehlermeldungen ist jetzt letsencrypt aktualisiert. Offenbar reicht es, wenn der zuerst erreichte Server, der den Datenverkehr in unser Netz über seine reverse-proxy-Einsetllung weiterleitet, seine Keys aktualisiert. Auf dem „Endpoint“ wurde seit über 4 Monaten der key nicht gewechselt.
Keine Ahnung, weshalb das funktioniert.
Ich musste das Ganze so lösen, dass ich das letsencrypt-Verzeichnis vom Proxy-Weiterleitungs-Server auf den Endpoint kopierte und dann natürlich den apache-service neustartete.
L.G.
Christoph
Und: Danke an alle, die sich mit diesem merkwürdigen Setting befasst haben!