Thank you for your response.
I noticed server misconfiguration later on yesterday.
Amusingly:
* Opera, IE and Chrome show the page as trusted
* Firefox reports error:
o xdm.telefonica.es:8096 uses an invalid security certificate.
The certificate is not trusted because no issuer chain was provided.
(Error code: sec_error_unknown_issuer)
I guess this is because the three have built in trust to intermediate
certificate (VeriSign Class 3 International Server CA - G3). In case of
FF as far as I can see it trusts only root certificates and requires
full chain to be properly provided.
Thanks again. I hope it resolves my problem.
BR,
polishcode
On 2011-11-20 05:21, Brian Carlstrom wrote:
The server is misconfigured:
$ openssl s_client -connect xdm.telefonica.es:8096
<http://xdm.telefonica.es:8096>
---
Certificate chain
0 s:/C=ES/ST=Madrid/L=Madrid/O=TELEFONICA MOVILES ESPANA
SA./OU=Desarrollo de Servicios/CN=xdm.telefonica.es
<http://xdm.telefonica.es>
i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use
at https://www.verisign.com/rpa (c)10/CN=VeriSign Class 3
International Server CA - G3
1 s:/O=VeriSign Trust Network/OU=VeriSign, Inc./OU=VeriSign
International Server CA - Class 3/OU=www.verisign.com/CPS
<http://www.verisign.com/CPS> Incorp.by Ref. LIABILITY LTD.(c)97 VeriSign
i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification
Authority
---
the issuer (i:) of a certificate should match the subject (s:) of the
next CA in the chain (in fact this is where the chaining metaphor
comes from because you are chaining from one cert to the next . to see
what I mean, compare with:
$ openssl s_client -connect www.android.com:443
<http://www.android.com:443>
---
Certificate chain
0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.google.com
<http://google.com>
i:/C=US/O=Google Inc/CN=Google Internet Authority
1 s:/C=US/O=Google Inc/CN=Google Internet Authority
i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority
---
Note where the C=US/O=Google Inc/CN=Google Internet Authority values
line up. To be clear, just having match names is insufficient, to
validate trust the signature of cert /n/ is validated against the
public key in cert /n+1/.
On Sat, Nov 19, 2011 at 4:16 AM, polishcode <[email protected]
<mailto:[email protected]>> wrote:
1. attach custom keystore to my application (as raw resource)
containing 0: certificate?
1. it would be troublesome, as 0: is issued for few months
only and the application would need updating on clients'
devices
yeah, this would be bad for the reasons you suggestion.
1. attach custom keystore to my application (as raw resource)
containing 1: certificate? would it fix my problem? (If yes, I
guess it would be the most preferable one?)
if you did this, you need to find the CA for "VeriSign Class 3
International Server CA - G3" to include since that is the issuer of
#0 but...
1. ask server owner to get new certificate that would be signed
using android-trusted certificate (we cooperate, so I guess it
could be possible)?
...really you need to ask the server owner to fix their cert chain to
remove #1 and replace with the CA with subject "/C=US/O=VeriSign,
Inc./OU=VeriSign Trust Network/OU=Terms of use at
https://www.verisign.com/rpa (c)10/CN=VeriSign Class 3 International
Server CA - G3"
I found the required intermediate CA here:
https://www.verisign.co.jp/repository/intermediate/internationalserverCAg3.html
1. any other approach? - apart from dismissing certificate check,
that is not acceptable
if you have to go the route of embedded in the intermediate CA because
you can't get the server cleaned up, you might also find on 2.3 and
earlier that the default TrustManager may reject the chain because 0
is not issued by 1. the solution there is to clean the chain before
passing it to TrustManager.checkServerTrusted call. in 2.2 we do this
type of cleaning within the default TrustManager for better
interoperability with sites like this.
-bri
--
The best thing about UDP jokes is that I don't care if you get them or not
--
You received this message because you are subscribed to the Google Groups "Android
Security Discussions" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/android-security-discuss?hl=en.
