Frage an x509certificate, ssl, ssl-certificate, android – Fehler: Name wird für selbstsignierte SSL-Zertifikate unter Android nicht verarbeitet

2

Ich versuche, mit dem integrierten Browser von Android 2.3.4 aus auf meine durch SSL geschützte Webanwendung zuzugreifen.

Das Serverzertifikat ist ein selbstsigniertes Zertifikat, das ich mit erstellt habeMAKECERT und auf dem Server installiert. Wenn ich versuche, auf die Seite zuzugreifen, wird vom Browser eine Fehlermeldung angezeigtThe name of the site does not match name on the certificate.

Ich habe überprüft und die Serveradresse entspricht genau dem allgemeinen Namen meines Zertifikats (es ist eigentlich nur eine IP-Adresse).

Die Nachricht wird nicht angezeigt, wenn ich versuche, auf dem Android-Gerät auf andere Websites zuzugreifen, die mit nicht selbstsignierten Zertifikaten geschützt sind.

Wenn ich mit IE oder Chrome auf einem Desktop auf dieselbe Seite zugreife - abgesehen von der Meldung der Signaturautorität -, werden keine Warnungen angezeigt. Sobald ich das Zertifikat in der vertrauenswürdigen Stammzertifizierungsstelle installiert habe, wird das Zertifikat vom Browser problemlos akzeptiert.

Sollte ich davon ausgehen, dass die Nachricht tatsächlich eine Ablehnung des von Android selbst signierten Zertifikats ist?

Ich bin ein bisschen verwirrt darüber.

Ich habe versucht, das Zertifikat im Speicher für Anmeldeinformationen zu installieren, aber das verbessert die Situation nicht. und jetzt habe ich keine ahnung, was ich als nächstes versuchen könnte.

Fragen sind: Gibt es eine bestimmte Sache, die ich befolgen sollte, um ein selbstsigniertes Zertifikat zu erstellen, das für Android akzeptabel ist? Hat es jemand geschafft, die von Android selbst signierten Zertifikate ohne diese Warnung zu akzeptieren?

Was könnte ich noch versuchen?

-AKTUALISIEREN- Brunos Antwort hat mich in die richtige Richtung gelenkt, und ich konnte einen Schritt nach vorne machen: Ich habe das Zertifikat neu erstellt und SAN hinzugefügt (musste aufgeben)MAKECERT zumOpenSSL, dort folgenAnweisungen von Andy Arismendi).

Jetzt ist die Nachricht weg, aber ich bin in dem bereits besprochenen Problem "Zertifizierungsautorität nicht vertrauenswürdig" blockiertin diesem SO PostDeshalb arbeite ich immer noch daran, eine endgültige Lösung für mein Problem zu finden - es wird keine Warnung im Android-Browser angezeigt.

Deine Antwort

3   die antwort
1

Erstens ist der Speicher für Anmeldeinformationen auf Android 2.x nur für die VPN- und WiFi-Anwendungen vorgesehen, der Browser sieht ihn nicht. Sie können kein eigenes Zertifikat im vertrauenswürdigen Zertifikatspeicher installieren (es sei denn, Sie haben ein gerootetes Gerät).

Haben Sie eine öffentliche oder eine lokale IP-Adresse für unsere Webanwendung, auf die Sie über WLAN zugreifen? Möglicherweise möchten Sie sich die logcat-Ausgabe ansehen. Möglicherweise gibt es einige Warnungen, die Ihnen dort einen Hinweis geben. Versuchen Sie es auch mit einem anderen Gerät und / oder dem Emulator (andere Android-Version, falls möglich) und vergleichen Sie Nachrichten / Verhalten.

0

Daher arbeite ich immer noch daran, eine endgültige Lösung für mein Problem zu finden - es wird keine Warnung im Android-Browser angezeigt

Nikolay Elenkov hat Ihnen erklärt, warum Sie auf Android kein Zertifikat im vertrauenswürdigen Speicher speichern können. Das hat sich in letzter Zeit geändert, hilft aber bei älteren Android-Clients nicht. Eine kurze Übersicht über den Schlüsselbund und den Keystore von Android finden Sie unterGibt es Speicherplätze für Systemzertifikate auf Android? (Es bezieht sich auf zwei Beiträge von Nikolay).

Da Sie im Android-Browser arbeiten, müssen Sie eine Zertifizierungsstelle verwenden, die bereits im Android Store vorhanden ist. Versuchen Sie, ein Serverzertifikat von einer bereits vertrauenswürdigen Zertifizierungsstelle abzurufenStartCom. StartCom bietet kostenlose Class 1-Zertifikate an, und ihr Stamm ist in den meisten mobilen und Desktop-Browsern als vertrauenswürdig eingestuft. (Beachten Sie, dass bei Bedarf eine Gebühr für den Widerruf erhoben wird.)

Wenn Sie der Vollständigkeit halber den Client selbst geschrieben haben, würden Sie einen benutzerdefinierten Code angebenX509TrustManager und überschreibencheckServerTrusted um Ihr Zertifikat anzunehmen. Es ist keine Interaktion mit einem Keystore, einem Schlüsselbund oder externen Zertifizierungsstellen erforderlich. Sie haben diese Option jedoch nicht, da Sie den Browser nicht geschrieben haben.

4

Ich habe überprüft und die Serveradresse entspricht genau dem allgemeinen Namen meines Zertifikats (es ist eigentlich nur eine IP-Adresse).

Der Host-Name-Verifier von Android ist strikter konformRFC 2818 als einige Browser. Wenn eine IP-Adresse verwendet wird, muss sie gemäß der Spezifikation in einem Eintrag für den alternativen Antragstellernamen von enthalten seinIP Adresse Typ: Nicht in einem SAN-Eintrag vom Typ DNS oder im CN:

Wenn eine subjectAltName-Erweiterung vom Typ dNSName vorhanden ist, MUSS diese als Identität verwendet werden. Andernfalls MUSS das (spezifischste) Feld Common Name im Feld Subject des Zertifikats verwendet werden. Die Verwendung des allgemeinen Namens ist zwar gängige Praxis, jedoch veraltet, und Zertifizierungsstellen werden aufgefordert, stattdessen den dNS-Namen zu verwenden.

[...]

In einigen Fällen wird der URI als IP-Adresse und nicht als Hostname angegeben. In diesem Fall muss die iPAddress subjectAltName im Zertifikat vorhanden sein und genau mit der IP in der URI übereinstimmen.

Am einfachsten wäre es, einen Hostnamen zu verwenden. (Die Verwendung von IP-Adressen in Zertifikaten ist nie wirklich praktisch.) Alternativ können Sie ein Zertifikat mit einem SAN-IP-Adresseintrag generieren. Das könnte Sie auch interessierendiese.)

Wissen Sie, was verwendet wird voncom.android.browser? Handelt es sich um den obigen RFC oder um die Dokumente des CA / Browser-Forums? (Grundlegende Anforderungen für die Ausstellung und Verwaltung von öffentlich vertrauenswürdigen Zertifikaten undRichtlinien für EV SSL-Zertifikate) jww
@noloader, Die CA / Browser-Dokumente und RFC 2818/6125 schließen sich nicht gegenseitig aus. (In den CA / Browser-Dokumenten werden mehr Verfahren zum Ausstellen und Überprüfen eines Zertifikats beschrieben, wohingegen dieser Teil von RFC 2818 aus technischer Sicht eher auf den Abgleich von Namen beschränkt ist.) AFAIK: Die CA / Browser-Grundvoraussetzung macht das SAN für EV-Zertifikate nur noch strenger erforderlich. Ich bin mir nicht sichercom.android.browser, aber es akzeptiert wahrscheinlich auch nicht-EV-Zertifikate (in diesem Fall müssen sie nicht den CA / Browser-Spezifikationen entsprechen), obwohl die EV-Zertifikate, die es verifiziert, sicherlich konform sein müssten (und daher wirklich ein SAN haben). Bruno

Verwandte Fragen