Moodlebox: HTTPS unterstützen

Einige Ressourcen:

• https://serverfault.com/questions/750902/how-to-use-lets-encrypt-dns-challenge-validation
• https://b3n.org/intranet-ssl-certificates-using-lets-encrypt-dns-01/

Hallo Nicolas,
Ich habe MoodleBox noch nie gespielt und meine Apache-Server noch nicht für die Bereitstellung von HTTPS konfiguriert, aber ich verstehe nicht, wo die Schwierigkeit bei der Installation eines Servers und eines SSL-Zertifikats liegen würde. Läuft die ModelBox nicht auf einer Linux-Distribution?
Nach dem, was ich gelesen habe, scheint es recht einfach zu sein, HTTPS auf einem Linux-Rechner zu konfigurieren, zumindest beispielsweise auf Debian.
Ich bin möglicherweise völlig falsch, wenn es um die MoodleBox geht, und das installierte Betriebssystem kann sehr unterschiedlich sein. In jedem Fall habe ich die folgenden Referenzen notiert, um mein Verfahren zum Einrichten von HTTPS auf meinen Installationen zu leiten:
So sichern Sie Apache mit Let’s Encrypt unter Ubuntu 16.04 |
Einrichten eines HTTPS-Servers unter Debian

PG

Es ist keine Frage der Schwierigkeit der Installation. Das Problem ist zweifach:

1. Es ist kompliziert, ein Zertifikat zu erhalten, wenn der Server nur im Intranet erreichbar ist, da die Instanz, die das Zertifikat bereitstellt, überprüfen muss, ob der Server tatsächlich legitim ist, und da sie ihn nicht erreichen kann, schlägt die Überprüfung fehl. Dies könnte über die obigen Links umgangen werden (dies muss ich vor der Implementierung testen;
2. es erfordert eine IANA-registrierte öffentliche Root-Domain (TLD), und die aktuelle ".home"-Domain ist es nicht. Unter Umständen muss also die Standard-URL, über die man auf die MoodleBox zugreift, geändert werden, was lästig ist.

Hallo Nicolas,

Vielen Dank für Ihre Antwort. Das sind zwei Punkte, von denen ich tatsächlich eine Intuition hatte. Als ich jedoch ein wenig herumwanderte, um mehr über SSL- und HTTPS-Zertifikate zu erfahren, dachte ich eher, dass wir eine Lösung finden würden:

1. Lokale Selbstzertifizierung (ich habe keinen Zweifel, dass Sie vor der Implementierung testen können)
2. Die Registrierung des Root-Domain-Namens bei ICANN scheint mir nicht obligatorisch zu sein ...

Es scheint mir, dass Ihre Antwort meine Vision bestätigt: nichts Unüberwindbares für eine Person Ihres Informatikniveaus!
Das Beste daran ist, dass es auch für eine Person meines bescheidenen Niveaus (mehr oder weniger langfristig) überwindbar sein kann! Auf jeden Fall beabsichtige ich, mich der Herausforderung zu stellen: Erstellen Sie meinen eigenen HTTPS-Server, ohne auf einen registrierten Domainnamen zu verweisen (nur auf eine IP-Adresse). Ich werde mich auf jeden Fall bei Ihnen melden, wenn ich zuerst Erfolg habe. (Vorsicht, das kann bei mir etwas dauern... Warte nicht auf mich!)

Hinweis: Ich befürchte jedoch, dass wir immer wieder Warnungen vor der Qualität des selbst vergebenen Zertifikats enthalten werden. Jeder Client muss während der ersten Verbindung einen privaten Schlüssel akzeptieren und registrieren.

Seh dich später,
PG

Ich befürchte jedoch, dass wir immer wieder vor der Qualität des selbst vergebenen Zertifikats warnen werden. Jeder Client muss während der ersten Verbindung einen privaten Schlüssel akzeptieren und registrieren.

Deshalb werde ich versuchen, mit Let's encrypt ein "echtes" Zertifikat zu erstellen.

Wie erwartet wird eine nicht-öffentliche Root-Domain von Letsencrypt nicht zugelassen.

$ sudo certbot certonly -d moodlebox.home --manual --register-unsafely-without-email --preferred-challenges dns

(several lines omitted)
Obtaining a new certificate
An unexpected error occurred:
The request message was malformed :: Error creating new authz :: Name does not end in a public suffix
Please see the logfiles in /var/log/letsencrypt for more details.

Erklärung hier: https://www.reddit.com/r/sysadmin/comments/3vyjd9/letsencrypt_non_public_domain/

Falls Sie ein Zertifikat für beispielsweise intranet.lan erhalten würden, können alle anderen dies auch tun! Also ... Bösewichte, die Ihre internen Domänen kennen, hätten kein Problem damit, Ihre Benutzer auf eine "intranetähnliche Phishing-Site" umzuleiten, und für sie wäre alles "grün", da dem Zertifikat vertraut wird. Selbst für SIE wäre es nicht direkt verdächtig, da das Zertifikat gültig und von LE signiert ist. Bei einer „privaten“ Unternehmens-CA können sie in der Regel keine weitere ausstellen.

Erforderliche Schritte:

• [x] Ändern Sie den FQDN in einen real existierenden Domänennamen
• [x] Zertifikat mit certbot von Let's Encrypt generieren
• [x] Konfigurieren Sie nginx für HTTPS
• [x] Konfigurieren Sie Moodle für die Verwendung von HTTPS
• [ ] Konfigurieren Sie die automatische Verlängerung des Zertifikats

Der letzte Punkt der Checkliste (Automatische Verlängerung des Zertifikats konfigurieren) scheint leider nicht machbar: Der Eigentümer der Domain muss den TXT-Eintrag für jede Verlängerung ändern, was für alle MoodleBoxen im Feld unpraktisch ist, es sei denn, es hat einen eigenen eindeutigen Domainnamen .

Ich fürchte, ich kann diese Funktion nicht in das Standardbild einfügen.

Hallo Nicolas,
Ich habe gelesen, dass einige Browser eine Website in naher Zukunft als unsicher markieren werden, wenn die Website kein SSL-Zertifikat verwendet. Dies wäre eine schlechte Sache, wenn die MoodleBox als unsicheres Gerät in den Sinn kommt.

Daher suchte ich nach Ideen, um ein SSL-Zertifikat in den Raspberry Pi zu bekommen. Was halten Sie von diesen Ideen?

• https://tutorials-raspberrypi.de/raspberry-pi-ssl-zertifikat-kostenlos-mit-lets-encrypt-erstellen/
• https://pimylifeup.com/raspberry-pi-ssl-lets-encrypt/
• https://www.stewright.me/2017/01/add-ssl-nginx-site-free-lets-encrypt/

Viele Grüße Ralf

Ich weiß nicht, ob das SSL-Zertifikat eines lokalen Webservers online aktualisiert werden muss? Daher sollte der Zertifikataktualisierungsprozess nur ausgeführt werden, wenn die MoodleBox verbunden und über Ethernet online ist. Dies wäre die gleiche Bedingung wie sie für die Zeitsynchronisierung oder für einen aktualisierten DNS-Eintrag benötigt wird.

Was passiert, wenn das SSL-Zertifikat ungültig wird und die MoodleBox nicht mit dem Internet verbunden ist? Sie haben geschrieben, dass die Benutzer für jede Verlängerung einen Textdatensatz ändern müssen. Es sollte ein Skript für den Erneuerungsprozess geben. Und die URL ist für jede MoodleBox gleich.

Hallo Ralf,
Wenn Sie sich die Checkliste oben ansehen, habe ich das alles bereits getan (über das hervorragende LetsEncrypt).

Allerdings bin ich in eine Sackgasse geraten. Zunächst einmal ist es, wie hier erwähnt , nicht möglich, ein SSL-Zertifikat mit einer nicht-öffentlichen Root-Domain zu erhalten. Dies muss also den FQDN von moodlebox.home in etwas wie einen öffentlichen ändern, sagen wir moodlebox.me. Das ist kein Problem (außer dass alle Benutzer ihre Gewohnheiten ändern müssen, was schlecht ist), ich habe es getan.

Zweitens habe ich leider keine Lösung für die Erneuerung des Zertifikats gefunden, da jede MoodleBox-Installation ein eindeutiges Zertifikat benötigt, sodass wir in der Situation sind, dass wir LetsEncrypt jedes Mal verschiedene Zertifikate nach demselben FQDN fragen müssen ( siehe Erklärung hier ).

Wenn Sie eine Lösung haben, freue ich mich, Sie zu hören.

Okay ... das Problem lässt sich mit Tausenden von dynamischen DNS-Einträgen für die MoodleBoxen auf der ganzen Welt nicht beheben.

Was halten Sie von einem selbstsignierten Zertifikat auf der MoodleBox. Das Zertifikat kann mit einem Installationsskript installiert werden. Der Admin könnte dieses Skript im Terminal starten oder es kann automatisch gestartet werden. Ja, ich weiß, dass jeder Benutzer eine Warnung erhält, dass ein selbstsigniertes Zertifikat nicht sicher ist. Aber wenn jeder Benutzer diesem Zertifikat vertraut, sollte die Verbindung sicher sein.

Der Webserver könnte einen Download-Link für das Zertifikat in einem Profil bereitstellen, sodass jeder Benutzer es auf seine Geräte herunterladen kann. Viele Arbeitsbereiche, Universitäten und Schulen verwenden selbstsignierte Zertifikate für ihre interne Serverkommunikation und Proxyserver.

Jede MoodleBox generiert ein eigenes Zertifikat. Aber was passiert, wenn ein Benutzer mehr als nur eine MoodleBox hat? Er kann das WLAN von MoodleBox1 auf Moodlebox4 ändern und öffnet dann die URL https://moodlebox.home. Das WLAN ist anders, aber die URL ist dieselbe. Wäre es möglich, ein zweites Profil für ein zweites Wi-Fi zu akzeptieren, aber die gleiche URL?

Ich fürchte, dass die Warnung vor einem unbekannten (selbstsignierten Zertifikat) nicht viel mehr beruhigen wird als die, dass die Verbindung nicht sicher ist ;-)

Ich verstehe, dass in einer großen Institution die Installation eines Zertifikats auf verwalteten Geräten in Ordnung ist. Dies ist jedoch in Einrichtungen, in denen Geräte nicht verwaltet werden, nicht machbar. Daher bin ich nicht so sehr daran interessiert, allen Benutzern eine solche Komplexität hinzuzufügen, zumindest nicht, bis es wirklich blockiert.

Vielleicht füge ich eine Dokumentation hinzu, wie man HTTPS auf der MoodleBox aktiviert und wie man sich ein selbstsigniertes Zertifikat beschafft. Was denkst du?

Ja. Ich denke, wir sollten eine Moodlebox-Version mit einem selbstsignierten Zertifikat ausprobieren.

Um es dem Admin etwas einfacher zu machen, sollte alle benötigte Software installiert sein und alle Verzeichnisordner vorhanden sein. Ich habe einige Anleitungen gefunden, die viele Installationsschritte zeigen ... nein, das sollte mit der MoodleBox sehr einfach sein.

Gute Idee. Ich denke, ich werde MoodleBox mit einem bereits generierten selbstsignierten Zertifikat und mit einer Konfigurationsdatei für nginx veröffentlichen, die mit auskommentierten Anweisungen (und Dokumentation) vorbereitet ist.

Wenn dies erledigt ist, könnte man es schaffen, indem man nur 2 Dateien bearbeitet (nginx- und Moodle-Konfigurationsdateien).

Getestet: es funktioniert 👍

@ralf-krause: wenn du dich testen willst: dann logge dich per SSH ein

1. Holen Sie sich Root-Rechte: sudo -s
2. Ordner erstellen: mkdir /etc/nginx/ssl
3. Generieren Sie Zertifikat und Schlüssel mit diesem Befehl (eine Zeile, keine neuen Zeilen): openssl req -new -x509 -sha256 -nodes -newkey rsa:4096 -keyout /etc/nginx/ssl/moodlebox.key -out /etc/nginx/ssl/moodlebox.crt -days 3650 -extensions v3_ca -extensions SAN -config <(cat /etc/ssl/openssl.cnf <(printf "[SAN]\nsubjectAltName=DNS:*.moodlebox.home")) -subj "/C=CH/O=MoodleBox/CN=moodlebox.home"
4. Fügen Sie die folgenden 3 Zeilen zur Datei /etc/nginx/sites-available/default hinzu, direkt nach der Zeile listen [::]:80 default_server; :

listen 443 ssl;

ssl_certificate /etc/nginx/ssl/moodlebox.crt;

ssl_certificate_key /etc/nginx/ssl/moodlebox.key;

1. In Datei /var/www/moodle/config.php , Zeile beginnend mit $CFG->wwwroot , ändern http mit https .
2. Starten Sie nginx neu: systemctl restart nginx
3. Root beenden: exit .

Ja, es funktioniert mit https! Sehr schön!

Hallo Nicolas,
Die MoodleBox funktioniert gut mit https, ist aber nicht einfach zu bedienen! Ich habe das Zertifikat im Schlüsselbund auf meinem Mac installiert und als "Immer vertrauenswürdig" eingestellt. Ich dachte, dass alles funktionieren würde.

• Der Safari-Browser zeigt die MoodleBox-Website problemlos an.
• Der Chrome-Browser öffnet die MoodleBox, aber es zeigt ein großes Zeichen "Nicht sicher". :-(
• Der Firefox-Browser verwendet einen eigenen Zertifizierungsordner und die Benutzer müssen die Website erneut überprüfen. :-(

Um einen einfachen Zugriff auf die MoodleBox zu haben, sollten wir sie ohne https verwenden.

Außerdem habe ich einen Blocker für das selbstsignierte Zertifikat gefunden ... die Moodle Mobile App verbindet sich mit diesem Zertifikat nicht mit der MoodleBox, selbst wenn das Zertifikat in einem Profil (.mobileconfig) installiert ist und von jeder App verwendet werden kann.

Vielen Dank für Ihre Rückmeldung. In diesem Fall haben wir leider Pech.

Dafür scheint es keine gute Lösung zu geben. Ich lasse das erstmal offen, falls jemand eine geniale Idee hat.

Benötigt Dokumentation, wenn (wenn?) Feature implementiert ist.

Hallo @martignoni

Ich habe mir gerade diesen Fall durchgelesen und finde, dass die Lösung mit Let’s Encrypt und echten Public Domains nicht der richtige Weg ist. MoodleBox wird hauptsächlich in einer Intranetumgebung verwendet, nicht wahr?

Ich denke, wir müssen auf jeder MoodleBox ein Root-Zertifikat erstellen (dh eine eigene CA hosten), das der Benutzer dann zu seinen "Vertrauenswürdigen Zertifikaten" auf seinem Client hinzufügen kann. Mit dieser Lösung soll es möglich sein, von dieser CA ein selbstsigniertes Zertifikat für Moodle zu generieren. Wenn der Benutzer danach auf die Plattform zugreift, sollte die Verifizierungskette als sicher verifiziert werden, da das Stammzertifikat auf der Client-Seite gespeichert wird.

Von Haus aus lauscht nginx also auf Port 80/443, aber Moodle wwwroot ist standardmäßig https . Und der gesamte Datenverkehr, der auf Moodle zugreift, wird auf 443 umgeleitet. Nur die Zielseite, die den root certificate -Download bereitstellt, ist über Port 80 zugänglich. Das ist eine Entscheidung des Benutzers, wenn er die unsichere Nachricht vermeiden möchte.

Lassen Sie mich wissen, was Sie darüber denken? Ich kann es versuchen. 😙

Überblick

• [x] Chrom (70.0.3538.77 - Win10)
• [x] FF (Quantum 63.0.1-Win10)
• [x] Kante (42.17134.1.0 - Win10)
• [ ] Android (6.0) mit Moodle Mobile App (3.5.2)
• [x] [Moodle Mobile Browser-App](https://mobileapp.moodledemo.net) (3.5.2)

Ergebnisse

Chrom

Ich habe gerade einen einfachen Test gemacht und es scheint mit Chrome zu funktionieren:

Clientseitig muss nur das Stammzertifikat als vertrauenswürdige Zertifizierungsstelle hinzugefügt werden und der MoodleBox wird dann vertraut:

Feuerfuchs

Mit FF müssen Sie es direkt in den Zertifikatspeicher des Browsers importieren:

Kante

Edge funktioniert einwandfrei (durchführen des Zertifikatsimports auf dem Client, siehe oben):

Safari

Mit Safari kann ich keinen Test machen... Ich besitze kein Apple-Gerät.

Moodle-Mobil

Es sollte mit der Moodle Mobile App funktionieren, wenn die RootCA vorhanden ist. Ich weiß nur nicht, wie ich das zu meinem Android-Gerät hinzufügen kann. Aber es gibt eine Moodle Mobile Browser App zu Testzwecken mit dem gleichen Verhalten:

Danke. Das ist sehr interessant und könnte eine Lösung sein. Das Hauptproblem ist dann die Vielfalt der Möglichkeiten, die Root-CA zu den verschiedenen Browsern hinzuzufügen, was leider in Bezug auf die Benutzerfreundlichkeit ein Chaos darstellt.

Könnten Sie mir bitte auf ein "How to" verweisen, das eine solche Root-CA und ein darauf basierendes SSL-Zertifikat erstellt?

Auf meinem Win10-Client ist es nur der FF, der das Stammzertifikat nicht vom Betriebssystem übernimmt. Ich denke, die meisten Benutzer verwenden Chrome.

Ich habe dies als Leitfaden verwendet: https://medium.freecodecamp.org/how-to-get-https-working-on-your-local-development-environment-in-5-minutes-7af615770eec

Aktualisieren

Der letzte Punkt der Checkliste (Automatische Verlängerung des Zertifikats konfigurieren) scheint leider nicht machbar: Der Eigentümer der Domain muss den TXT-Eintrag für jede Verlängerung ändern, was für alle MoodleBoxen im Feld unpraktisch ist, es sei denn, es hat einen eigenen eindeutigen Domainnamen .

Ich fürchte, ich kann diese Funktion nicht in das Standardbild einfügen.

Wie wäre es mit einer Lösung mit ngrok?

Hallo Adrian,
Bei meinem Test im Februar 2018 stellte ich fest, dass jeder Browser auf macOS eine eigene Zertifikatsprüfung haben wollte. Der Blocker war, dass die Moodle Mobile-App auf iOS das selbstsignierte Zertifikat von der MoodleBox nicht akzeptierte.
Viele Grüße Ralf

@ralf-krause: die Situation ist nicht die gleiche, weil wir zu diesem Zeitpunkt nicht daran gedacht haben, dem Browser eine Root-CA hinzuzufügen.

Vielleicht sollte MoodleBox dieses HTTPS als experimentelle Option haben? Standardmäßig ist HTTP und HTTPS ist für fortgeschrittene Benutzer, die wissen, wo die Grenzen liegen. Mit einem nicht offiziellen Zertifikat wird es schwierig, alle Anforderungen zu erfüllen.

Kennst du ngrok @martignoni? Aber für eine statische Domain ist es ein kostenpflichtiges Abonnement ... 😏

Ich denke, wir müssen auf jeder MoodleBox ein Root-Zertifikat erstellen (dh eine eigene CA hosten), das der Benutzer dann zu seinen "Vertrauenswürdigen Zertifikaten" auf seinem Client hinzufügen kann. Mit dieser Lösung soll es möglich sein, von dieser CA ein selbstsigniertes Zertifikat für Moodle zu generieren. Wenn der Benutzer danach auf die Plattform zugreift, sollte die Verifizierungskette als sicher verifiziert werden, da das Stammzertifikat auf der Client-Seite gespeichert wird.

Von Haus aus lauscht nginx also auf Port 80/443, aber Moodle wwwroot ist standardmäßig https . Und der gesamte Datenverkehr, der auf Moodle zugreift, wird auf 443 umgeleitet. Nur die Zielseite, die den root certificate -Download bereitstellt, ist über Port 80 zugänglich. Das ist eine Entscheidung des Benutzers, wenn er die unsichere Nachricht vermeiden möchte.

Ich habe ein bisschen daran gearbeitet und werde versuchen, es in einer nächsten Version zu implementieren. Ich behalte jedoch Port 80 als Standardport bei, sodass sich die UX für die meisten Benutzer nicht ändert.

Notiz an mich selbst: Anleitung zur Umsetzung

Vorbereitung

sudo -s
mkdir /root/CA
mkdir /etc/nginx/ssl

Zertifizierungsstelle

# Generate our CA private key.
openssl genrsa -out /root/CA/moodlebox.CA.key 2048
# Generate a CA root certificate.
openssl req -x509 -new -extensions v3_ca -nodes -key /root/CA/moodleboxCA.key -sha256 -days 3652 -out /root/CA/moodleboxCA.pem -subj "/C=CH/O=MoodleBoxCA/CN=net.moodlebox.ca"

Erstellen Sie ein SSL-Zertifikat, das mit dem obigen CA-Stammzertifikat signiert ist

# Generate our website private key.
openssl genrsa -out /etc/nginx/ssl/moodlebox.key 2048
# Create a CSR.
openssl req -new -key /etc/nginx/ssl/moodlebox.key -out /etc/nginx/ssl/moodlebox.csr -subj "/C=CH/O=MoodleBox/CN=moodlebox.home"
# Create the signed SSL certificate.
openssl x509 -req -in /etc/nginx/ssl/moodlebox.csr -CA /root/CA/moodleboxCA.pem -CAkey /root/CA/moodleboxCA.key -CAcreateserial -out /etc/nginx/ssl/moodlebox.pem -days 3652 -sha256
# Delete CSR.
rm /etc/nginx/ssl/moodlebox.csr

__nginx__ konfigurieren

Fügen Sie die folgenden 3 Zeilen zur Datei /etc/nginx/sites-available/default hinzu, direkt nach der Zeile listen [::]:80 default_server; .

listen 443 ssl;

ssl_certificate /etc/nginx/ssl/moodlebox.crt;

ssl_certificate_key /etc/nginx/ssl/moodlebox.key;

Und __nginx__ neu laden

sudo systemctl reload nginx.service

Notiz

Dies ist eine coole Dokumentation: https://gist.github.com/Soarez/9688998

Hallo @martignoni

Cool, dass du an diesem Thema arbeitest. Daumen hoch! 👍

Grüße
Adrian

Dokumentation veröffentlicht. Schluss :-)