![\"logo-lotus-traveler.gif\"](\"http://www.assono.de/blog/images/MLEY-8F6EWB/$File/logo-lotus-traveler.gif\") | In vielen Netzwerken kommt es vor, dass der Lotus Notes Traveler Server nicht direkt aus dem Internet erreichbar ist, sondern von einer Firewall geschützt ist. Oft übernimmt diese Firewall Routingfunktionen und maskiert das Netz nach Außen hin. Dies sind normale Sicherheitsmechanismen, die man ständig antrifft. |
Bei der Verwendung von verschlüsselten Zugriffen auf den Traveler-Server muss man jedoch darauf achten, welcher Server im SSL-Zertifikat eingetragen ist.
In vielen Fällen wird für den Zugriff auf Traveler ein selbst erstelltes Zertifikat genutzt. Wenn eine so verschlüsselte Seite aufgerufen wird, erhält man auf dem Browser eine Meldung darüber, dass das Zertifikat unter Umständen unsicher ist, da es nicht von einer autorisierten Zertifizierungsstelle stammt. Weiterhin wird überprüft, ob sich das Zertifikat an bestimmte für SSL geltende Regeln hält. Diese Prüfungen werden auch auf den Browsern mobiler Geräte durchgeführt. Generell kann man die Sicherheitsbedenken der Browser jedoch ignorieren und Ausnahmen für bestimmte Zertifikate definieren. In diesem Rahmen ist mir ein Problem mit Symbian Telefonen aufgefallen.
In der vorliegenden Umgebung steht der Traveler-Server in einer DMZ, die von einer Firewall geschützt ist. Diese soll den Traveler-Server von Außen erreichbar machen, indem sie eine Portweiterleitung durchführt. Alle Anfrage auf Port 8443 werden auf den Traveler-Server mit Port 443 weitergeleitet.
![\"traveler_dmz_network.png\"](\"http://www.assono.de/blog/images/MLEY-8F6EYM/$File/traveler_dmz_network.png\")
Der Traveler Server sollte von Außen erreichbar sein, indem man
https://firewall.acme.com:8443/servlet/traveler aufruft. Die eingetragene Portweiterleitung schickt die Anfrage dann an
https://traveler.acme.intern:443/servlet/traveler.
Zur Verschlüsselung wurde ein SSL-Zertifikat auf dem Traveler-Server eingerichtet, das (standardmäßig) den Namen des Servers, auf dem das Zertifikat erstellt wird, beinhaltet. Wenn man nun von extern
https://firewall.acme.com:8443 aufruft, bemerkt der Client zum einen, dass das Zertifikat selbst erstellt ist. Zum anderen merkt er an, dass das Zertifikat nicht für den Server ausgestellt ist, den man gerade anfragt. Das widerspricht den SSL-Regeln. Dennoch kann man dieses Zertifikat als Ausnahme definieren und die Verschlüsselung funktioniert.
Bei Symbian Telefonen sieht die Sache anders aus. Um das Gerät automatisch für Traveler zu konfigurieren, ruft man bequemerweise die Traveler-Homepage auf und lädt sich die Konfiguration herunter. Wenn man jedoch mit dem Symbian-Browser auf
https://firewall.acme.com8443/servlet/traveler zugreift bemerkt er, dass das Zertifikat selbst ausgestellt ist und dass es eigentlich für
https://traveler.acme.intern/servlet/traveler ausgestellt ist. Den ersten Fall kann man noch als Ausnahme erlauben. Der zweite Fall missfällt dem Symbian-Browser jedoch so sehr, dass er keine Verbindung zulässt. Ich habe auch keine Möglichkeit gefunden, um ihn da etwas nachsichtiger agieren zu lassen.
Sollte man also Symbian Telefone verschlüsselt mit Traveler verbinden wollen, so ist auf jeden Fall darauf zu achten, dass man die externe URL einträgt. Man erstellt also auf dem Traveler-Server ein SSL-Zertifikat, das für die externe Firewall ausgestellt ist. So ist auch der Zustand für die von extern anfragenden Browser konsistent, selbst wenn es sich nur um eine Portweiterleitung handelt und die Geräte eigentlich mit dem Traveler-Server kommunizieren.
![\"android-logo.jpg\"](\"http://www.assono.de/blog/images/MLEY-8C6CY5/$File/android-logo.jpg\"){kind=logo}