Ein Howto vom 02. und 03.01.2018
Worum geht es?
Auf einer alten Workstation soll eine NextCloud die Zusammenarbeit von Mitgliedern einer Arbeitsgruppe unterstützen. Der Rechner läuft hier in meinem Netzwerk hinter dem Router und soll den Zugriff HTTPS gesichert über das Internet ermöglichen.
Der Aufbau und die Konfiguration des Servers ist hier beschrieben.
Hier geht es nur darum den Zugriff auf den Server zu zeigen und die Einbindung des im Browser nicht bekannten Zertifikates zu beschreiben.
Was soll am Ende dieses Textes gewonnen sein?
Der Browser des eigenen Rechners ist mit einem selbst erstellten und selbst signierten Zertifikat abgesichert und ermöglicht einen HTTPS Zugriff auf die NextCloud im Netzwerk ohne Fehlermeldung.
Es kann auf dem Portal gearbeitet werden, ohne daß die Verbindung abgehört werden kann oder die Paßwörter offen über das Netz transportiert werden. Das war das Ziel.
Technische Voraussetzungen
Der Rechner läuft im Netzwerk hinter einem Router. Somit muß im Router eine Freigabe erfolgen die vom Port außen auf den SSL-Port 443 des Rechners im Netz verweist und damit eine Verbindung vom abgesicherten Webserver zum Client-Browser des Benutzers verschlüsselt ermöglicht. Diese Freigabe ist hier in meinem Router eingerichtet.
Da mein Internetanschluß hier eine feste IP-Adresse besitzt und mir damit die Notwendigkeit eines DynDNS-Zugriffs erspart, ist der Zugriff um einiges stabiler und leichter.
Browser Zugriff
Wird mit einem Browser auf eine Webseite zugegriffen, die nicht identifiziert werden kann und von der der Browser nicht weiß über welchen Port er zugreifen darf, gibt der Browser eine Fehlermeldung aus.
Hier wurde keine Port-Adresse angegeben. Die Fehlermeldung deutet daraufhin, daß eine Portangabe erforderlich sein kann. Da der Zugriff über die Freigabe des Routers erfolgen muß, ist beim Zugriff immer der Port mit anzugeben, über den die Freigabe erreicht wird.
Zugegriffen werden muß vom Client-Rechner mit einem Browser auf die feste IP-Adresse, die mit Doppelpunkt von der Portangabe getrennt auf die gewünschte Seite verweist.
https://aa.bb.cc.ddd:xxxx/nextcloud
(Dabei ist a – d die IP-Adresse und x die Portangabe)
ist der schematisch dargestellte Zugriff auf die NextCloud Webseite.
Für die Portangabe ist eine Freie Wahl erlaubt. Nur die ersten 1024 Ports sind per Konvention bereits an Applikationen vergeben (z.B. Port 443 für SSL Zugriffe, 21 für FTP, 22 SFTP etc.). Es stehen 216 Ports also 65.536 zur Verfügung. Davon kann einer nach Belieben ausgewählt werden. Damit würde eine Freigabe im Router mit einer (fiktiven) IP-Adresse 128.244.103.57 und dem gewählten Port 59.457 den Durchgang von Port 59.457 auf Port 443 ermöglichen. In einer Fritz!Box der Firma AVM reicht das Auswählen des Dienstes HTTPS um den inneren Port automatisch auf 443 zustellen. Es muß nur noch der äußere Port angegeben werden und die Konfiguration aktiviert. Der Aufruf im Browser wäre dann:
https://128.244.103.57:59457/nextcloud .
Erst durch den expliziten Aufruf über den dezidierten Port wird im Browser, hier explizit durch den Firefox Browser 57.0.3 (64-Bit) dargestellt, eine “Erweitert”-Funktion freigeschaltet, die eine nähere Betrachtung erlaubt.
Hier ergibt sich dann die Möglichkeit die Fehlermeldung zu dominieren und eine Ausnahme hinzuzufügen. Das soll dann auch geschehen, nachdem alle Kriterien überprüft sind.
In der Regel werden solche Internetadressen nicht zufällig gefunden, sondern die gewünschten Benutzer bekommen sie durch den Zertifikatsersteller genannt. Da er beim Generieren des Zertifikats auch den Fingerprint, d.h. die eindeutige Kennung des Zertifikates mit erzeugt hat, ist ihm dieser Fingerprint bekannt. Er wird im besten Fall diesen Fingerprint mit ausliefern bei der Weitergabe der Webadresse, damit ein unsicherer Benutzer beide Werte vergleichen kann und damit weiß, daß er die richtige Seite hat und kein Risiko einer unbekannten Gefährdung eingeht.
Natürlich wird angeraten sich alles genau anzusehen, um keinen Fehler zu begehen. So sollte vor dem herunterladen des Zertifikates über den Button “Ansehen” erst einmal das Zertifikat verglichen werden. Der vom Ersteller mitgesendete Fingerprint würde wohl der SHA1 Abdruck sein, der auch vollkommen ausreicht das Zertifikat als das angekündigte zu identifizieren (SHA1 67:43:3E:C4:CB:E0:27:F0:6C:B7:2A:EB:FB:F3:BE:B9:C6:00:A1:23).
Erst dann sollte das Herunterladen erfolgen, die dauerhafte Speicherung ausgewählt und die Sicherheits-Ausnahmeregel bestätigt werden. Damit ist der Vorgang auch schon abgeschlossen und der Zugriff auf das Portal ist abgesichert
Die Seite baut sich auf und die Eingabe der Benutzerdaten ist möglich. Ein weiterer Indikator der Absicherung ist das Ausbleiben der Warnung einer unsicheren Seite beim Versuch der Eingabe des Paßwortes.
Auch das auf die Verschlüsselung hinweisende grüne Schloß ist vorhanden. Allerdings mit einem gelben Achtung-Zeichen, weil es ein selbst signiertes Zertifikat ist. Hier lassen sich die Zertifikatsinformationen jederzeit auslesen und selbst das Zertifikat kann von hier aus wieder gelöscht werden.
Das Klicken auf das Schloß klappt das nachfolgende Label herunter auf dem noch einmal eine Sicherheitswarnung erscheint.
Mit dem Pfeil nach rechts aber besteht die Möglichkeit die Sicherheitsausnahme des Zertifikats wieder zurückzunehmen und das Zertifikat zu entfernen. Weitere Informationen über die Webseite können abgerufen werden. Sie decken sich im Wesentlichen mit den Zertifikatsdaten, die beim Import schon bekannt waren.
Klickt man “Weitere Informationen” geht ein ähnliches Fenster auf wie bei der Übernahme des Zertifikats. Hier lassen sich auch ähnliche Informationen abrufen, wie Aufruf des Zertifikates, ob die Seite Cookies setzt oder ob für diese Seite Paßwörter gespeichert sind.
Wenn das alles bedacht wurde und die Herkunft des Zertifikates geklärt ist, die Sicherheitsmechanismen akzeptiert wurden, läßt sich mit der Webseite auch in einem Portal ohne Domain hervorragend arbeiten.
Das gelbe Ausrufungszeichen wird nach der Änderung aller URLs auf HTTPS verschwinden.
