Das Notes Forum
Lotus Notes / Domino Sonstiges => Companion Products => Thema gestartet von: Driri am 24.08.11 - 15:42:02
-
Hallo,
ich probiere gerade, auf unserem produktiven Traveler-Server das erste Nokia-Endgerät (E72) anzubinden. Auf unserem Testserver funktioniert das problemlos, auf dem Produktivserver erhalte ich als Fehlermeldung am Client "Verbindungsfehler zum Server <yxz>, Port 443".
Für den Testbenutzer habe ich bereits ein Android-Smartphone am Server registriert, der Zugriff für den Benutzer ist also generell vorhanden und korrekt eingerichtet.
Folgende Dinge habe ich schon erfolglos probiert :
- Port 80 am Server aufgemacht und am Client auf HTTP umgestellt -> Fehlermeldung : Unbekannter Fehler (504)
- Bei Nokia die Security Enablement heruntergeladen und auf dem E72 installiert
- Über den Browser versucht, auf den Server zuzugreifen. Das funktioniert aber weder über HTTP, noch über HTTPS. Auf einem Android-Smartphone funktioniert das sofort.
- INI-Parameter mit denen des Testserver verglichen -> stimmen überein
- NTSConfig.xml mit der des Testserver verglichen -> stimmen überein
- NTSConfig.xml auf Parameter zur Einschränkung der Devicetypen geprüft -> ohne Ergebnis, d.h. es gibt dort keine Einschränkung
- Als Test ein Nokia E52 installiert und den Zugriff via Traveler getestet -> selbes Fehlerbild
Jetzt gehen mir die Ideen aus. Hat noch jemand einen Tipp ?
-
- Über den Browser versucht, auf den Server zuzugreifen. Das funktioniert aber weder über HTTP, noch über HTTPS. Auf einem Android-Smartphone funktioniert das sofort.
da würde ich ansetzten. Anderes Netztwerk (Sim)? Fehlendes VPN? Firewall-Regel, die das Netz blockt?
-
Das ist es ja, ich kann mir das nicht erklären. Ich habe im Android-Phone die selbe SIM-Karte benutzt. VPN wird nicht genutzt.
Firewall könnte ich die Kollegen mal interviewen, aber kann man an einer Firewall gerätespezifisch blocken ?
-
Kommts Du mit dem E72 auf andere Seiten (sowohl ext. als auch intern)?
-
Ja, das funktioniert.
Ich vermute auch irgendwie ein Problem mit dem Server. Denn mit dem Testserver funktioniert es auf Anhieb.
-
Kriegst du das Loginfenster?
Mal mit IP versucht?
-
Über die IP kommt die selbe Fehlermeldung.
Was meinst Du mit Loginfenster ? Wenn ich den Traveler-Client nach der Installation starte, muß ich ja eh Server, Benutzername und Kennwort eingeben.
Oder meinst Du im Browser ? Via Browser komme ich gar nicht auf den Server. Da bekomme ich immer eine Zeitüberschreitung.
Ich interviewe jetzt erstmal die Firewall-Kollegen. Das habe ich gestern nicht mehr geschafft.
-
Ja, ich meinte den Browser. Frag mal die Firewaller, ob überhaupt ein Request ankommt.
Wichtig ist, dass zumindest die Seite kommt, vorher würde ich am Travler Client nicht suchen.
-
HTTP war an der Firewall gesperrt. Das soll normalerweise auch so sein, weil wir nur HTTPS verwenden wollen.
Nachdem wir Port 80 mal testweise freigegeben hatten, konnte ich mich vom E72 aus zumindest via HTTP auf der Traveler-Homepage anmelden.
Die HTTPS-Verbindung klappt aber immer noch nicht. Wir vermuten, daß das ein Problem mit dem SSL-Zertifikat auf dem Gerät ist.
Jetzt muß ich mir nur überlegen, wie ich da weiter vorgehe. Vermutlich werde ich da vor meinem Urlaub nicht mehr zu kommen. Also bitte nicht wundern, wenn ich nicht mehr auf Antworten hier reagiere.
Vielen Dank auf jeden Fall schon mal für die bisherigen Ratschläge :)
-
Bin wieder da und fleißig am Testen.
Ich habe jetzt mal das Root CA installiert, das das E72 vorher nicht hatte. Ergebnis bleibt aber identisch.
Mittlerweile habe ich so den Verdacht, daß das SSL-Zertifikat einfach nicht vernünftig auf dem Symbian-Phone läuft. Laut Nokia sind Wildcard-Zertifikate zwar seit Symbian 9.2 supportet, aber ich habe auch von anderer Stelle gehört, daß es immer mal wieder Probleme mit verschiedenen Zertifkaten gibt.
Jetzt muß ich mir nur überlegen, was ich noch testen kann. Ich kann ja schlecht am produktiven Server das SSL-Zertifikat austauschen. Nachher fliegen mir dann noch die produktiven Geräte um die Ohren.
Weiß jemand, ob es kostenlose SSL-Zertifkate gibt (von mir aus auch stark zeitlich begrenzt), die mit Symbian laufen und die man mal am Testsystem einspielen könnte ?
-
ich probiere gerade, auf unserem produktiven Traveler-Server das erste Nokia-Endgerät (E72) anzubinden. Auf unserem Testserver funktioniert das problemlos, auf dem Produktivserver erhalte ich als Fehlermeldung am Client "Verbindungsfehler zum Server <yxz>, Port 443".
Für den Testbenutzer habe ich bereits ein Android-Smartphone am Server registriert, der Zugriff für den Benutzer ist also generell vorhanden und korrekt eingerichtet.
Fehler deutet auf Verbindungsprobleme hin.
Lösung:
Step 1 - Try to access the server using a web browser on different device or system that has full connectivity.
Step 2 - try to access the server using PocketIE on the device. If the server seems to be online, make sure you can login using the same userid/password that is on the device. Finally, if that works try to soft reset the device.
An der Firewall muss der Port 8642 geöffnet.
Port 8642 is only needed if you have a pre-8.5.2 Windows Mobile or Nokia client. Otherwise, the port is unused and can be ignored or disabled.
Alle Infos hierzu stehen auf "Lotus Notes Traveler 8.5.2 Second Edition August 2010 (http://infolib.lotus.com/resources/domino/traveler/8.5.2/doc/TR852ACD001/en_us/NotesTravelerAria.html)"
Interessant bei Zugriffsproblemen sind auch die HTTP Methods.
HTTP methods used by Traveler devices
Traveler devices require the usage of the following HTTP methods:
Apple: GET, POST, OPTIONS
Windows Mobile and Nokia S60: GET, POST
Android (support introduced in Traveler 8.5.2.1): GET, POST, HEAD
These HTTP methods must be allowed to traverse the network path between the Traveler devices and Traveler server for successful account setup and synchronization.
Weitere Infos hierzu unter Apple device users unable to complete Traveler profile setup or account validation (https://www-304.ibm.com/support/docview.wss?uid=swg21410603)
-
Hallo Martin,
danke für die Antworten.
An der Firewall muss der Port 8642 geöffnet.
Server und Client laufen auf mind. 8.5.2.2. Daher ist der Port auch nicht freigeschaltet.
Vor allem funktioniert es ja mit Android-Devices und mit den Symbian-Devices funktioniert es auch, sobald ich von HTTPS auf HTTP wechsele.
Das spricht auch gegen einen Fehler in der Konfiguration der HTTP Methods. Ich habe das trotzdem noch mal gerade geprüft und die Konfiguration ist hier korrekt.
-
Ingo, ich verstehe folgende Info ...
Port 8642 is only needed if you have a pre-8.5.2 Windows Mobile or Nokia client.
...so, dass Nokia Clients den Port benötigen, auch wenn der Traveler 8.5.2.2 ist.
-
Das interpretierst Du falsch.
Den Port brauchst Du nur, wenn der Traveler Client am Nokia älter als 8.5.2 ist.
Bei meinem Nokia E71 ist am Server nur der 443er Port offen.
-
Hallo
ich kann Martin nur bestätigen:
Das interpretierst Du falsch.
Den Port brauchst Du nur, wenn der Traveler Client am Nokia älter als 8.5.2 ist.
Bei meinem Nokia E71 ist am Server nur der 443er Port offen.
+1
Gruß aus Nürnberg
Werner
PS: habe auch ohne 8642 und MIT E71 hier laufen.
-
Fast alle Android Geräte, wie z.B. der Aldi Lifetab oder Android Smartphones
können mit dem Standard-Browser gegen Domino-Server (8.5.3 FP2)
mit SSL einfach kein POST absetzen,
z.B. beim Absenden einer Form oder bereits beim Login (Session Authentication)
Das Problem geistert auch schon seit ca. 1 Jahr in allen möglichen Foren rum,
jedoch leider ohne Lösung.
Schaltet man an der Datenbank die SSL-Pflicht aus, läuft alles prima.
POST funktioniert.
Schaltet man es wieder ein, kommt auf der Console der Fehler
HTTP Web Server: Invalid POST Request Exception [/names.nsf?Login] Anonymous
Es kommen wahrscheinlich keine oder falsch verschlüsselte Daten an.
Generell geht aber auch das SSL, denn wenn man nur "browst",
also Ansichten aufmacht, Docs öffnet, etc. also GET absetzt
funktioniert alles.
Was ist an einem SSL POST so anders als an einem SSL GET,
beim so einem Android Standard Browser ( 4.0.4) ???
Macht man einen Android Firefox auf die Dinger, klappts auch wieder,
aber das kann ja nicht die Lösung sein.
Genauso wie die Windows Phones. Da geht auch alles.
Gibt es für den Android Standard-Browser auch so eine Art Firebug,
um zu sehen, was der so versucht an den Domino zu senden ?
Für jede Hilfe sehr dankbar...
Gruß,
Uwe
-
Das klingt exakt danach und interessant.
Was macht dieses ICS genau ?
http://forums.androidcentral.com/motorola-xoom/67403-webmail-blocked-xoom-5.html#anb
-
Man müsste mal einen Man in The Middle Proxy aufsetzen um die Klartextdaten zu sehen, das könnte mit "Cain & Abel" ohne größerem Aufwand funktionieren:
http://www.oxid.it/ca_um/topics/apr-https.htm
(Achtung: Am Android Gerät muss wahrscheinlich ein Zertifikat installiert werden, welches man nachher wieder löschen sollte)
Gruß
Roland
-
ICS = Ice Cream Sandwich = Android 4.0
Btw : Ihr schweift etwas vom eigentlichen Thema meines Threads ab. Besser wäre es, dafür einen neuen Thread zu öffnen.
-
Ich kann dir hierzu noch einen Tipp geben:
Weiß jemand, ob es kostenlose SSL-Zertifkate gibt (von mir aus auch stark zeitlich begrenzt), die mit Symbian laufen und die man mal am Testsystem einspielen könnte ?
https://www.startssl.com/
- es gehen keine Wildcard-Zertifikate (in der kostenlosen Version)
- Habe damit mal einen apache-server ssl beigebracht.
- Nachdem ich am Server mein eigenes UND die Root/Intermediate CAs installiert hatte, wurden diese auch von jedem (neueren) Browser akzeptiert.
Ein Zugriff über IP wird vermutlich nicht funktionieren, da Zertifikate für eine Domain ausgestellt werden
Könnte es evtl sein, dass euer DNS auf IPv6 auflöst und das Nokia versucht auf diese zu connecten?
Gruß
Roland
-
Sorry Ingo,
ich dachte, es ist vielleicht das gleiche Problem, das Du oben beschrieben hattest.
Und hoffte, ihr seid vielleicht schon etwas weiter gekommen in der Zwischenzeit.
Ich hab auch nix gegen einen neuen Thread, weiß aber nicht, wie das geht.
Einige meinen, es liegt am SSL Zertifikat...
aber kann ein Zertifikat gleichzeitig mit GET funktionieren und mit POST nicht ?
Alle GET Handshakes serverseitig sind völlig ok - auch das Tablet meldet ein grünes einwandfreies Zertifikat.
Wir sehen über die htthr.logs auch ziemlich genau, was da am Server ankommt, es fehlen die POST Daten und einige Sachen sind kryptisch.
Kann es vielleicht auch ein Firewalll Problem sein, dass ein SSL POST vom Android außer der Methode POST noch ein OPTIONS oder so fordert, der gesperrt ist ?
-
Unterschied SSL GET und SSL POST...
Ein GET unter SSL wird ja (eigentlich) per (einfacher) URL Zeile
offen vom Android an den Domino Server gesendet.
Erst der Rückgabe-Content vom Domino Server zum Browser wird verschlüsselt übertragen.
Es VERschlüsselt also der Domino und der Android ENTschlüsselt.
Beim SSL POST wird aber bereits der Dstenstrom ZUM Server verschlüsselt.
Hier VERschlüsselt also das Android und der Domino ENTschlüsselt.
Kann das der Unterscheid sein,
warum SSL GETs problemlos laufen und POSTs nicht funktionieren.
-
Ich habe von IBM folgende Antwort auf den Fehler
While trying to access iNotes from default Android browser the error occours:
"Error 500 "HTTP Web Server: Invalid POST Request Exception"
Domino console log says "HTTP Web Server: Invalid POST
Request Exception [/names.nsf?Login] Anonymous"
erhalten:
Found Lotus Notes SPR # BSCT8X7BDY
"Error 500 "HTTP Web Server: Invalid POST Request Exception"
Should be fixed in 8.5.3 FP3
Workaround: Use another browser from AppStore. ::)
-
Sorry, aber das hat so gar nichts mit dem eigentlichen Thema des Threads zu tun ;)
-
pardon Driri
Nichtsdestotrotz ein kleines Update hier:
Mit 8.5.3 FP3 sind nun SSL Posts möglich,
wenn (!)
wenn man die "ndolextn" als DSAPI filter file names im Serverdokument mitlädt.
Sonst nicht.
Da muß erst mal einer drauf kommen - wir haben es durch absoluten Zufall entdeckt.
ABER:
Ein Login, also eine Authentifizierung mit SSL ist immer noch nicht möglich,
heißt, der Login Dialog unter SSL hängt immer noch
bringt aber nun einen anderen Fehler:
500 INTERNAL ERROR
Ohne SSL kann man sich einloggen -
und kann dann sogar jetzt mit SSL posten...
Wie immer, das ganze - die typische Notes-Krankheit - immer nutzbar bis 90% - und damit praktisch unbrauchbar.
Workaround:
Einen "Login-Umweg" anbieten/gehen
über eine Hilfs-Datenbank, die keinen SSL Zwang hat,
sich dort einloggen
und zurück zur eigentlichen SSL Datenbank.
Notes eben.
Wir suchen aufs äußerste, ob es nicht doch eine Einstellung gibt, die auch das SSL Login ermöglicht...
Gruß,
Uwe
-
Und es geschehen doch noch Wunder.
IBM hat mit FP4 für Domino 8.5.3 das Login und Post Problem für Android gefixt.
Ab sofort kann man sich problemlos mit Android per SSL einloggen und ebenso posten.
Interessant auch,
weil IBM das ganze bisher immer offiziell als Android-Problem beschrieben hat.
Gruß,
Uwe
-
Danke für den Hinweis.
Das FP4 hat mein Problem auch gelöst. Entwickle gerade eine XPages-Anwendung die den gleichen Fehler meldete "Invalid POST Request Exception" mit einem Android-Browser.
Und es geschehen doch noch Wunder.
IBM hat mit FP4 für Domino 8.5.3 das Login und Post Problem für Android gefixt.
Ab sofort kann man sich problemlos mit Android per SSL einloggen und ebenso posten.
Interessant auch,
weil IBM das ganze bisher immer offiziell als Android-Problem beschrieben hat.
Gruß,
Uwe