Da schauen wir doch mal mit Android 2.2. Das Zertifikat läuft auf CN=elearning.uni-hannover.de und hat ein SubjectAltName=DNS:www.elearning.uni-hannover.de. Der Browser ist so modern, dass er den SubjectAlternativeName intepretieren kann: Beim Betreten der Webseite kommt keine Fehlermeldung. Probiert man das ganze mit einem alten Browser oder z. B. lynx, bekommt man dort schon einen
|
Source code
|
1
|
SSL error:host(www.elearning.uni-hannover.de)!=cert(elearning.uni-hannover.de)
|
Die Buttons kommen von studip-web1.elearning.uni-hannover.de. Da ist das Zertifikat auch ok. Passt alles mit CN=studip-web1.elearning.uni-hannover.de.
Da ist wohl der Fehler: Beim Klick auf herunterlanden wird eine Adresse der Art https://www.elearning.uni-hannover.de/download/force_download/0/ce87e380e7b... geöffnet. Doch schaut man per tcpdump zu oder die Zieladresse nach dem redirect oder rewrite an (Android: langklick, siehe Kopfzeile), so findet man eine Adresse auf einem anderen Server, nämlich
https://studip-web2.elearning.uni-hannover.de/.
Für https://studip-web2.elearning.uni-hannover.de/ existiert kein gültiges Zertifikat, wie einem auch jeder moderne Browser auf dem PC/Mac sagt, denn das verwendete Zertifikat gilt nur für www.elearning.uni~ und für elearning.uni~, denn es ist das selbe Zertifikat wie das erste. Klar, dass es dann einen SSL-Fehler gibt.
Es ist also kein Fehler im Android-Browser, sondern viel mehr dass Opera dieses Mismatch nicht bemängelt oder durch den Redirect erst gar nicht merkt!
Ergo: Pro Android Browser, böse böse Opera!
=> Es ist also etwas, dass die Betreiber vom Stud.IP fixen sollten.
Wer nicht folgenden konnte, dem empfehle ich die Lehrveranstaltung Security Engineering
und nun die Theorie für unwissende: Der Server behauptet in einer SSL-gesicherten Session er sei studip-web2.uni, zeigt aber den Studie-Ausweis von elearning.uni. Dumm gelaufen, sagt da der Browser-Türsteher.