DB Navigator: Kein gültiges Zertifikat

davidk

Original poster
Beta Tester
6 Januar 2021
12
Hallo zusammen,

ich habe folgendes Problem: Wenn ich mit der App "DB Navigator" den Buchungsprozess für ein Ticket starte, kommt eine Fehlermeldung, dass kein gültiges Zertifikat vorhanden sei. Das Buchen von Tickets ist aufgrund dieses Problems mit der App nicht möglich. Auf Englisch lautet die komplette Fehlermeldung wie folgt:
There is no valid certificate on the device to establish a secure connection. Please check your system settings or update your operation system.

Gerät: SHIFT6mq
OS: ShiftOS 3.5 L
Root: ja (Magisk)
microG: ja

Das Problem habe ich schon seit vielen Monaten, melde mich jedoch erst jetzt hier im Forum. Ich vermute, dass die Ursache des Problems im System Webview liegt. In ShiftOS kommt "Android System Webview" (com.shiftos.webview) in der Version 94 zum Einsatz. Momentan habe ich nun "Bromite System Webview" in Version 93 installiert (mithilfe des Magisk-Moduls "Webview Manager" von Androidacy), jedoch behebt das das Problem leider auch nicht.

Hat jemand noch weitere Ideen, woran das liegen und was ich ggf. noch ausprobieren könnte?

Gruß David
 
Das Problem habe ich auch. Bin auf ShiftOS 3.3 G release Version. Bin auch gerootet mit Magisk, SafetyNet geht aber durch, außerdem ist das keine typische Meldung für SafetyNet o.Ä. Ansonsten ist alles relativ standard bei mir (bzw. inzwischen habe ich noch das eine oder andere drauf wie LSPosed, aber das Problem gab es schon vorher). Ich hatte die Vermutung, vielleicht liegt es daran, dass ich momentan kein Google-Konto auf dem Handy hinterlegt habe.
 
Der Hinweis, dass es generell am gerooteten Gerät liegen könnte, hat mich nun auf die richtige Spur gebracht... :D
MagiskHide hat zunächst nichts gebracht, der DB Navigator startet dann überhaupt nicht mehr. Anschließend kam ich auf die Idee, AdAway mal zu deaktivieren. Und tatsächlich: Jetzt scheint der Buchungsprozess zu funktionieren! Scheinbar versucht der DB Navigator beim Buchungsprozess etwas herunterzuladen, was von AdAway blockiert wird.

Vermutlich reicht es, wenn bei AdAway für eine spezifische Domain eine Ausnahme hinzugefügt wird. Das muss ich mir bei Gelegenheit mal noch genauer anschauen.
 
Der Hinweis, dass es generell am gerooteten Gerät liegen könnte, hat mich nun auf die richtige Spur gebracht... :D
MagiskHide hat zunächst nichts gebracht, der DB Navigator startet dann überhaupt nicht mehr. Anschließend kam ich auf die Idee, AdAway mal zu deaktivieren. Und tatsächlich: Jetzt scheint der Buchungsprozess zu funktionieren! Scheinbar versucht der DB Navigator beim Buchungsprozess etwas herunterzuladen, was von AdAway blockiert wird.

Vermutlich reicht es, wenn bei AdAway für eine spezifische Domain eine Ausnahme hinzugefügt wird. Das muss ich mir bei Gelegenheit mal noch genauer anschauen.
Super! Würde mich freuen, wenn du uns dann Bescheid gibst, an was es gelegen hat :)
 
Kann meine Erfahrung ergänzen: seit der DB Navigator mehr Tracker beinhaltet und ich diese Tracker mit TrackerControl blockiere, dauert die Buchung ca. 3-4 Minuten. Jede neue Seite des Buchubhsprozesses muss ewig laden und das Ticket erscheint im Anschluss teilweise nicht (gleich) in der Übersicht der gekauften Tickets. Habe der DB geschrieben und würde alle, die ähnliche Probleme mit den Trackern haben bitten der DB ebenfalls ihren Unmut kundzutun!

Kuketz hat sich vor einigen Tagen auch der Sache angenommen.

Hoffen wir es bewegt sich was! :)

PS: nutze auch die L-Version(en)
 
Der vorletzte Post in diesem Forum (https://www.computerbase.de/forum/threads/adaway-blockiert-amazon-app.1989051/) hat mich dazu gebracht, zu testen, an welchen Domains es bei mir liegt. Im Screenshot sind die Domains, mit denen es bei mir mir funktioniert, wenn ich sie whiteliste, wobei die Amazon-URL für die Amazon-App ist (und die anderen für die DB app.)
Interessant, bei mir reicht es, wenn ich die unteren beide eintrage.
 
Bei mir stellt sich das etwas anders dar...
Damit der Buchungsvorgang in der DB Navigator-App bei mir funktioniert, muss ich bei der Verwendung von AdAway zusätzlich zu den von Kuketz genannten Verbindungen noch die Folgenden freigeben:
  • st.bahn.de
  • siteintercept.qualtrics.com
  • *-bahn.siteintercept.qualtrics.com
Bei den qualtrics.com-Verbindungen handelt es sich offensichtlich um Tracking, jedoch funktioniert der Buchungsvorgang bei mir nicht, wenn ich diese Verbindungen durch AdAway blockieren lasse.

Bei der Verwendung von NetGuard (und ausgeschaltetem AdAway), wie es auch Kuketz tut, ist die Lage eine andere...
Hier funktioniert der Buchungsvorgang, wenn ich in NetGuard lediglich die von Kuketz beschriebenen Verbindungen freigebe - jedoch mit einer Schwäche: Es gibt während des Buchungsvorangs sehr lange Wartezeiten von 2x ca. 10 Sekunden.

Das unterschiedliche Verhalten zwischen AdAway und NetGuard resultiert wohl aus dem unterschiedlichen Vorgehen der beiden Apps. Bei AdAway wird die Filterung aufgrund des veränderten Hosts-Files durch das Android-System vorgenommen, bei NetGuard von der App selbst (durch ein VPN).
 
Zuletzt bearbeitet:
  • Like
Reaktionen: Tüftler
Bei mir stellt sich das etwas anders dar...
Damit der Buchungsvorgang in der DB Navigator-App bei mir funktioniert, muss ich bei der Verwendung von AdAway zusätzlich zu den von Kuketz genannten Verbindungen noch die Folgenden freigeben:
  • st.bahn.de
  • siteintercept.qualtrics.com
  • *-bahn.siteintercept.qualtrics.com
Bei den qualtrics.com-Verbindungen handelt es sich offensichtlich um Tracking, jedoch funktioniert der Buchungsvorgang bei mir nicht, wenn ich diese Verbindungen durch AdAway blockieren lasse.

Bei der Verwendung von NetGuard (und ausgeschaltetem AdAway), wie es auch Kuketz tut, ist die Lage eine andere...
Hier funktioniert der Buchungsvorgang, wenn ich in NetGuard lediglich die von Kuketz beschriebenen Verbindungen freigebe - jedoch mit einer Schwäche: Es gibt während des Buchungsvorangs sehr lange Wartezeiten von 2x ca. 10 Sekunden.

Das unterschiedliche Verhalten zwischen AdAway und NetGuard resultiert wohl aus dem unterschiedlichen Vorgehen der beiden Apps. Bei AdAway wird die Filterung aufgrund des veränderten Hosts-Files durch das Android-System vorgenommen, bei NetGuard von der App selbst (durch ein VPN).
Interessante Beobachtung! Habe tatsächlich längere Wartezeiten, aber im Prinzip verhält es sich bei mir gleich.
 
Ich wollte mich mal eben bedanken, nun kann ich endlich auch wieder die Bahn App nutzen.

Bei mir war es auf jeden Fall die URL logx.optimizely.com, die ich in AdAware whitelisten musste.

Nun scheint es aber auch ohne whitelisting zu funktionieren, nachdem die App 1 mal Kontakt zum Server hatte...
 
  • Like
Reaktionen: Webbi1264 und danielp
Ich habe kein Shiftphone, sondern ein Samsung Galaxy S9+, Magisk root, LineageOS 19, AdAway, gleiches Problem.
Bei mir hat es gereicht die 8 domains, die Tüftler (bzw. Kuketz) angegeben hat in AdAway als Ausnahme hinzuzufügen, ALLERDINGS musste ich erst einen Systemneustart machen damit es funktioniert hat (für manche vielleicht ein nobrainer), das wollte ich für andere noch ergänzen.