Um das was es tatsächlich geht, ist die bewusste Wahl seitens der Server-Betreiber einer ganz bestimmten RootCA als Aussteller eines Server-Zertifikats für einen Threema-Server, welcher integral wichtig für die Nutzung der Threema App ist. Das hat erstmal überhaupt nichts mit dem Betriebssystem oder gar der Betriebssystem-Version zu tun, das betrifft nämlich alle Plattformen und alle Versionen.
Hier würde eine Info-Seite von Threema weiterhelfen, auf welcher die Namen und Bezugsquellen (download-URLs) aller erforderlichen RootCA-Zertifikate für alle system-relevanten Threema-Server aufgezählt sind. Eine Info-Seite auf welcher darüberhinaus zukünftige neue RootCA-Zertifikate mit einem halben Jahr Vorlauf angekündigt werden, bevor ein Zertifikat unter so einer anderen neuen RootCA von Threema erworben und auf einem Threema-Server installiert wird.
Zusätzlich braucht es halt noch eine klare und verständliche direkte Fehlermeldung aus der Threema-App, welche auf das aufgetretene und für die App sauber erkennbare Problem hinweist -- statt aktuell einer sehr langen Sanduhr-Anzeige und am Ende eine nichtssagende irreführende Fehlermeldung.
Beiträge von MartinR
-
-
Update: Während der Bilder Up&Download Donnerstag Abend nach Installation des self-signed Sectigo Root E46 (ECDSA) wieder sauber funktioniert hat, ging Bild Up&Download heute (Samstag) abend wegen irgendeiner Server-seitigen Konfigurations-Änderung schon wieder nicht mehr (Upload- bzw. Download- bleibt einfach hängen, und bricht erst nach sehr langer Zeit von allein ab).
(ich hatte zu Beginn das falsche neue Sectigo Root R46 (RSA) verlinkt, dabei geht es um die Sectigo Root E46 (ECDSA).
Die gute Nachricht: Nach dem LÖSCHEN des von mir am Donnerstag abend manuell hinzugefügten self-signed RootCA-Zertifikats Sectigo Root E46 (ECDSA) aus Android 11 Einstellungen, funktioniert der Up&Download von Bildern im Threema-Chat wieder ... und es wird jetzt vermutlich auch mit noch älteren Androids wieder funktionieren, welche genau dasselbe Problem gehabt haben müssen.
So sah die Zertifikatskette des Threema-Servers am Donnerstag abend aus
1.Subject: CN=*.threema.ch, O=Threema GmbH, SP=Schwyz, C=CH
Issuer: CN=Sectigo Public Server Authentication CA OV E36, O=Sectigo Limited, C=GB
2.Subject: CN=Sectigo Public Server Authentication CA OV E36, O=Sectigo Limited, C=GB
Issuer: CN=Sectigo Public Server Authentication Root E46, O=Sectigo Limited, C=GB
3.Subject: CN=Sectigo Public Server Authentication Root E46, O=Sectigo Limited, C=GB
Issuer: CN=Sectigo Public Server Authentication Root E46, O=Sectigo Limited, C=GB
Heute abend schickt der Threema-Server dagegen eine andere Kette (s.u.), d.h. der Server-Admin hat seinen Fehler korrigiert, denn der Threema-Server nutzt jetzt die von Sectigo für Abwärtskompatibilität bereitgestellten Cross-CA-Zertifikate bis zu einer alten Comodo RootCA:
1.Subject: CN=*.threema.ch, O=Threema GmbH, SP=Schwyz, C=CH
Issuer: CN=Sectigo Public Server Authentication CA OV E36, O=Sectigo Limited, C=GB
2.Subject: CN=Sectigo Public Server Authentication CA OV E36, O=Sectigo Limited, C=GB
Issuer: CN=Sectigo Public Server Authentication Root E46, O=Sectigo Limited, C=GB
3.Subject: CN=Sectigo Public Server Authentication Root E46, O=Sectigo Limited, C=GB
Issuer: CN=USERTrust ECC Certification Authority, O=The USERTRUST Network, L=Jersey City, SP=New Jersey, C=US
4.Subject: CN=USERTrust ECC Certification Authority, O=The USERTRUST Network, L=Jersey City, SP=New Jersey, C=US
Issuer: CN=AAA Certificate Services, O=Comodo CA Limited, L=Salford, SP=Greater Manchester, C=GB
Auf dem Android11 Gerät Herstellerseitig vorinstalliert ist das Sectigo self-signed Root-Zertifikat "USERTrust ECC CertificationAuthority" unter dem Namen "The USERTRUST Network", als auch das alte Comodo Root-Zertifikat "AAA Certificate Services".
Warum die Anwesenheit des self-signed Sectigo Root E46 Zertifikats im Android 11 Zertifikatsspeicher (Benutzer) die Zertifikatskettenverifikation scheitern lässt bei der neuen, abwärtskompatiblen Zertifikatskette, ist mir schleierhaft. Das läßt sich eigentlich nur durch eine fehlerhafte PKIX-Implementierung in der von Threema benutzen TLS-Implementierung erklären. (d.h. warum stolpert sie über das self-signed Sectigo E46 im Zertifikatsspeicher (Benutzer) aber stolpert nicht über das self-signed USERTrust ECC Certification Authority im Zertifikatsspeicher (System) ???)
Übrigens ist das Threema Logfile überhaupt keine Hilfe bei der Fehlersuche. Weder werden da die hostnamen genannt, zu denen eine Verbindung versucht wird, noch wird der Fehler genannt, warum die Verbindung nicht aufgebaut werden kann.
Im vorliegenden Falle eines Zertifikats-Verifikationsfehler muss die Threema App in weniger als einer Sekunde alles bereits wissen:
(a) zu welchem Threema-Server konnte keine TLS-gesicherte Verbindung aufgebaut werden
(b) wegen welchem Fehler aus der lokalen TLS-Implementierung ist der Verbindungsaufbau final gescheitert: Zertifikatsketten-Verifikationsfehler(c) an welchem CA-Zertifikat (Issuer) die Kette endet und die Verbindung zu bekannten TrustAnchors fehlt
(d) dass die Ursache dieses Zertifikatsketten-Verifikationsfehlers meistens ein server-seitiger Administrations-Fehler ist, der nur durch Server-Seitige Konfigurationsänderung effektiv für alle korrigiert werden kann (workarounds auf einzelnen Clients durch einem technisch versierten Nutzer wären möglich, aber nur wenn die Threema App die Information (b) und (c) auch aushändigt.
(e) dass Wiederholungsversuche innerhalb der nächsten Minute mit einer Wahrscheinlichkeit von 99.9% nutzlos sind und mit genau demselben Fehler enden werden.
Selbst wenn die Threema-App zur Sicherheit zwei Verbindungsversuche unternimmt, werden die in zusammen weniger als einer Sekunde auf genau dieselbe Art Scheitern, das Verhalten der Threem-App (keinerlei brauchbare Fehlermeldung, Sanduhr > 20 sekunden scheint mir irgendwie etwas peinlich in so einer klaren Situation.