https-Sicherheit auf dem Hallenboden Zur Absicherung der Browser-Webserver-Kommunikation wird üblicherweise https genutzt. https basiert auf SSL (Secure Sockert Layer). Die Browser-Webserver-Kommunikation im Internet functioniert sehr vereinfacht so: Es ist ein Schlüsselpaar erforderlich. Ein Teil des Schlüssel ist im Server hinterlegt und der andere Teil im Browser fest eingebaut. Sogenannte CA (Certificate Authorities) erstellen die Schlüssel und sorgen dafür, dass die privaten Schlüssel geheim bleiben. Ein CA erstellt ein Schlüssel für eine Domain (z.B. ondics.de), wenn er sich sicher ist, dass die Website „verlässlich“ ist. Das kann die CA prüfen, in dem die öffentliche Website aufgerufen wird.
https im Intranet
Im Intranet sieht die Sache nun etwas anders aus: Der Server ist für die CA nicht erreichbar und damit nicht prüfbar. Also gibt es dafür erstmal kein Zertifikat. Und kein SSL-Schlüsselpaar und keine https-Sicherheit.
Details dazu gibt’s von GlobalSign, einem der größeren CA-Anbieter unter https://www.globalsign.com/en/blog/certificates-for-internal-servers/
Oh, also was tun?
Möglichkeit 1: der interne Domainname heißt gleich wie der externe und es wird ein Wildcard-Zertifikat verwendet. Der interne Server heißt also email.ondics.de und das Zertifikat ist *.ondics.de. Die CA prüft also der Server ondics.de und erteilt das Zertifikat. Bingo! Leider sind interne Domainnamen meist von externen verschieden 🙁
Möglichkeit 2: Der interne Server verwendet ein selbstsigniertes Zertifikat / Schlüsselpaar. Der eine Schlüssel wird fest im Server eingebaut. Wenn der Browser dann die Seite aufruft, kommt eine Warnung „Achtung unsichere Website“ und der Benutzer muss das Zertifikat explizit akzeptieren, wenn er fortfahren will. Bingo! Leider ist das für den Benutzer etwas unangenehm, zumindest das erste Mal, wenn er die Seite aufruft.
Möglichkeit 3: Für reinrassige Microsoft-Installationen mit zentraler Administration der Gruppenrichtlinien gibt es die Möglichkeit, Zertifikate in die Browser per Softwareverteilung zu bringen. Damit kann das selbstsignierte ScaleIT-Zertifikat an alle Anwender verteilt werden, ohne dass ein unsicheres Zertifikat jemals bestätigt werden muss. Aber eben leider nur für Microsoft-Browser in Microsoft-Umgebungen mit Microsoft-Zertifikatsverteil-Verfahren.
Geht doch!
Die Möglichkeit 2 ist aktuell in ScaleIT eingebaut, bzw. genauer: in der ScaleIT Core Enterprise Edition.
Die ScaleIT Core Community Edition verwendet IP-Adressen zum Aufruf der Apps. Damit ist grundsätzlich keine SSL-Absicherung möglich.
Wir sind froh, für das Thema Sicherheit (vorerst) eine recht akzeptable Lösung gefunden zu haben. Wir arbeiten weiter daran und wollen natürlich eine für Benutzer noch angenehmere Variante, ScaleIT-Apps sicher zu verwenden.
Neueste Kommentare