The server is misconfigured: $ openssl s_client -connect 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 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 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 --- Certificate chain 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.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]> 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 -- 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.
