3

I am trying to access my web application protected by SSL from an Android 2.3.4 using the built-in browser.

The server certificate is a self-signed certificate I created using MAKECERT and installed on the server. When I try to access the page, I get an error message from the browser stating The name of the site does not match name on the certificate.

I have verified and the server address is exactly maching the Common Name of my certificate (it is actually just an IP address).

The message does not pop up when I try to access, on the Android device, other websites secured with not self signed certificates.

If I access the same page using IE or Chrome on a desktop - apart for the signing authority message - I get no warnings and, once I have installed the certificate in the Trusted Root CA, the certificate is smoothly accepted by the browser.

Should I take it that the message is actually a rejection of self signed certificate by Android?

I am a bit puzzled at this.

I tried to install the certificate in the Credential Storage but that does not improve the situation. and now I have no clue what I might try next.

Questions are: Is there any particular thing I should follow creating a self-signed certificate acceptable for Android? has anyone managed to get the self-signed certs accepted by Android without this warning?

What else could I try?

-UPDATE- Bruno's reply steered me in the right direction, so I managed to do one step forward: I remade the certificate adding SAN (had to abandon MAKECERT for OpenSSL, following there instructions from Andy Arismendi).

Now the message has gone but I am blocked in the 'certification autority not trusted' issue already discussed in this SO post, so I am still working to find a final solution to my issue - not having any warning popping up on the Android browser.

Community
  • 1
  • 1
eddo
  • 2,094
  • 1
  • 25
  • 31

3 Answers3

4

I have verified and the server address is exactly maching the Common Name of my certificate (it is actually just an IP address).

Android's host name verifier is more strictly compliant with RFC 2818 than some browsers. According to the specification, if an IP address is used, it must be in a Subject Alternative Name entry of IP address type: not on a SAN entry of DNS type or in the CN:

If a subjectAltName extension of type dNSName is present, that MUST be used as the identity. Otherwise, the (most specific) Common Name field in the Subject field of the certificate MUST be used. Although the use of the Common Name is existing practice, it is deprecated and Certification Authorities are encouraged to use the dNSName instead.

[...]

In some cases, the URI is specified as an IP address rather than a hostname. In this case, the iPAddress subjectAltName must be present in the certificate and must exactly match the IP in the URI.

The easiest would be to use a host name. (Using IP addresses in certificates is never really practical.) Alternatively, generate a certificate with a SAN IP address entry. (You may be interested in this.)

Community
  • 1
  • 1
Bruno
  • 119,590
  • 31
  • 270
  • 376
  • do you know what is being used by `com.android.browser`? Is it the RFC above, or is it the CA/Browser forums documents? ([Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates](https://cabforum.org/wp-content/uploads/Baseline_Requirements_V1_1_6.pdf) and [EV SSL Certificate Guidelines](https://cabforum.org/wp-content/uploads/EV-SSL-Certificate-Guidelines-Version-1.4.5.pdf)) – jww Feb 20 '14 at 15:28
  • @noloader, The CA/Browser documents and RFC 2818/6125 are not mutually exclusive. (The CA/Browser docs is more about procedures to issue and verify a certificate, whereas this part of RFC 2818 is more limited to name matching, from a technical point of view). AFAIK, The CA/Browser baseline requirement simply makes the SAN more strictly required, for EV certs. Not sure about `com.android.browser`, but it probably accepts non-EV certs too (in which case they don't have to conform to the CA/Browser specs), although EV certs it verify would certainly have to comply (and thus really have a SAN). – Bruno Feb 20 '14 at 16:34
1

First, the credential storage on Android 2.x is only for the VPN and WiFi applications, the browser doesn't see it. You can't install your own certificate in the trusted certificate store (unless you have a rooted device).

Is you our webapp on a public IP address or a local one you are accessing over WiFi? You might want to look at the logcat output, there might be some warnings that will give you a hint there. Also try from another device and/or the emulator (different Android version if possible) and compare messages/behaviour.

Nikolay Elenkov
  • 52,576
  • 10
  • 84
  • 84
0

so I am still working to find a final solution to my issue - not having any warning popping up on the Android browse

Nikolay Elenkov told you why you can't save a certificate to the trusted store on Android. That has changed recently, but does not help with older Android clients. For a brief history of Android's Keychain and Keystore, see Are there any system certificates storages on Android? (it refers to two posts by Nikolay).

Because you are working in the Android browser, you need to use a a CA which is already present in the Android store. To get a server certificate from a CA already trusted, try StartCom. StartCom offers free Class 1 certificates and their root is trusted in most mobile and desktop browsers. (Keep in mind they charge for revocation, if needed).

For completeness, if you wrote the client yourself, then you would provide a custom X509TrustManager and override checkServerTrusted to accept your certificate. It would not require any interaction with a Keystore, Keychain, or external CAs. But you don't have that option because you did not write the browser.

Community
  • 1
  • 1
jww
  • 97,681
  • 90
  • 411
  • 885