Hello,

I have to establish ssl connection to https://xdm.telefonica.es:8096/
(on Android 2.2+)
Certificate chain of the server is (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
[...]
Translating it into user-friendly form (CN, serial number):
0: xdm.telefonica.es, 0x64 4E 91 4B 13 33 CF 6C 1C 08 D2 9C 21 E0 C4 75
1: VeriSign Class 3 International Server CA - G3, 0x64 1B E8 20 CE 02 08
13 F3 2D 4D 2D 95 D6 7E 67
2: VeriSign Class 3 Public Primary Certification Authority - G5, 0x18 DA
D1 9E 26 7D E8 BB 4A 21 58 CD CC 6B 3B 4A

I extracted (adb pull /system/etc/security/cacerts.bks 2_3_4cacerts.bks)
cacerts.bks from my 2.3.4 Galaxy SII and listed all root certificates
(keytool -list -v -keystore 2_3_4cacerts.bks -storepass changeit
-storetype BKS -provider
org.bouncycastle.jce.provider.BouncyCastleProvider -providerpath
bcprov-jdk16-146.jar). It turns out that root certificate (2:) is listed
as trusted, but intermediate one (1:) is not on the list. I checked also
Android 3.2: result is the same.

Simple code snippet:
DefaultHttpClient hc = new DefaultHttpClient();
hc.execute(new HttpGet("https://xdm.telefonica.es:8096/"));
returns famous javax.net.ssl.SSLPeerUnverifiedException: No peer
certificate.
For comparison, for uri "https://mail.google.com" result is HTTP/1.1 200 OK.

Which one of the following directions should I take:

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
2. 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?)
3. ask server owner to get new certificate that would be signed using
android-trusted certificate (we cooperate, so I guess it could be
possible)?
4. any other approach? - apart from dismissing certificate check, that
is not acceptable

Thanks in advance,
polishcode


--
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 android-security-discuss@googlegroups.com.
To unsubscribe from this group, send email to android-security-discuss+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-security-discuss?hl=en.

Search Discussions

  • Brian Carlstrom at Nov 20, 2011 at 4:22 am
    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 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 android-security-discuss@googlegroups.com.
    To unsubscribe from this group, send email to android-security-discuss+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/android-security-discuss?hl=en.
  • Polishcode at Nov 20, 2011 at 9:26 pm
    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 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 android-security-discuss@googlegroups.com.
    To unsubscribe from this group, send email to android-security-discuss+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/android-security-discuss?hl=en.
  • Brian Carlstrom at Nov 21, 2011 at 1:57 am

    On Sun, Nov 20, 2011 at 1:26 PM, polishcode wrote:

    I guess this is because the three have built in trust to intermediate
    certificate (VeriSign Class 3 International Server CA - G3).
    No, its most likely because they cache intermediate CAs they have seen from
    other sites in their store. I believe the NSS library which is used by
    Firefox and Chrome on Linux does this. Starting in 3.0 Android will do this
    in memory within a browser session, since some sites have come to expect
    this behavior at least within the same site. for eample,
    https://www.example.com HTML pages might include the full cert chain, but
    pages with resources such as images or javascript will have only the server
    cert, presumably to save the bandwidth of serving the full cert chain.
    However, Android still doesn't permanently save them and is unlikely too
    for the near future.

    -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 android-security-discuss@googlegroups.com.
    To unsubscribe from this group, send email to android-security-discuss+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/android-security-discuss?hl=en.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupandroid-security-discuss @
categoriesandroid
postedNov 19, '11 at 12:17p
activeNov 21, '11 at 1:57a
posts4
users2
websiteandroid.com

2 users in discussion

Brian Carlstrom: 2 posts Polishcode: 2 posts

People

Translate

site design / logo © 2017 Grokbase