Thanks. I had the same issue. The BKS format didn't work but the PKCS12
format did.
On Tuesday, August 20, 2013 6:34:50 AM UTC-7, VirtualTam wrote:
>
> Hi!
> We had a similar issue when porting a library to Android (4.1), but didn't
> manage to get a BKS KeyStore working; though the client certificate was
> properly loaded, it wasn't given during the server handshake, which
> resulted in a handshake failure...
> The issue may be that the BKS keystore has been created in an unsupported
> format (apparently, the version of the BouncyCastle Provider used to create
> the keystore matters).
> After messing with BouncyCastle and my Java environment, I finally went on
> using a PKCS#12 keystore, which works like a charm!
>
> Here is the command I used to convert the keystore from JKS to PKCS#12
> (adapt the paths/filenames to your configuration):
>
> PATH/TO/keytool -importkeystore -v -noprompt
> -srckeystore SRC.jks -srcstoretype JKS -srcstorepass PASSWORD
> -destkeystore DST.p12 -deststoretype PKCS12 -deststorepass PASSWORD
>
> If you're running Windows, the path to keytool does certainly look like this:
> C:\"Program Files\Java\jre7\bin"\keytool.exe
>
> And here is the SSL/TLS context initialisation:
> String KEYSTORE_PASSWORD = "p@55w0rd"
> KeyStore keyStore = KeyStore.getInstance( "PKCS12" );
> keyStore.load(new FileInputStream(new File(keystorePath)),
> KEYSTORE_PASSWORD.toCharArray());
>
>
> KeyManagerFactory keyManagerFactory =
> KeyManagerFactory.getInstance(KeyManagerFactory.getDefaultAlgorithm());
> keyManagerFactory.init(keyStore, KEYSTORE_PASSWORD.toCharArray());
>
> SSLContext sslContext = SSLContext.getInstance("TLS");
> sslContext.init( keyManagerFactory.getKeyManagers(), null, new
> SecureRandom() );
>
> Le jeudi 4 octobre 2012 07:23:22 UTC+2, Brian Carlstrom a écrit :
>
> On Wed, Oct 3, 2012 at 9:58 PM, Marco Serioli <[email protected]> wrote:
> > I think that in your prepareConnection you should call:
> >
> >
> ((HttpsURLConnection)httpUrlConnection).setSSLSocketFactory(getSSLSocketFactory());
>
>
> >
> > where getSSLSocketFactory() looks something like this:
> >
> > private SSLSocketFactory getSSLSocketFactory() throws KeyStoreException,
> > KeyManagementException, NoSuchAlgorithmException, CertificateException,
> > IOException, UnrecoverableKeyException, NoSuchProviderException{
> > final InputStream trustStoreLocation =
> > mContext.getResources().openRawResource(R.raw.server);
> > final String trustStorePassword = "pwd";
> > final InputStream keyStoreLocation =
> > mContext.getResources().openRawResource(R.raw.client);
> > final String keyStorePassword = "pwd";
> > final KeyStore trustStore = KeyStore.getInstance("BKS");
> > trustStore.load(trustStoreLocation, trustStorePassword.toCharArray());
> > final KeyStore keyStore = KeyStore.getInstance("BKS");
> > keyStore.load(keyStoreLocation, keyStorePassword.toCharArray());
>
> Instead of using a BKS file a resource, you could include the
> X509Certificate as a PEM or DER encoded file and then use
> CertificateFactory.getInstance("X.509") to load it from a resource,
> then create a KeyStore from that on the file. or just embed the PEM as
> a java.lang.String or DER as a byte[].
>
> >
> > final TrustManagerFactory tmf =
> >
> TrustManagerFactory.getInstance(TrustManagerFactory.getDefaultAlgorithm());
> > tmf.init(trustStore);
> >
> > final KeyManagerFactory kmf =
> > KeyManagerFactory.getInstance(KeyManagerFactory.getDefaultAlgorithm());
> > kmf.init(keyStore, keyStorePassword.toCharArray());
> >
> > final SSLContext sslCtx = SSLContext.getInstance("TLS");
> > sslCtx.init(kmf.getKeyManagers(), tmf.getTrustManagers(), new
> > SecureRandom());
> > return sslCtx.getSocketFactory();
> > }
> >
> > In this case you have to use same password for certificate/keystore!!!
> I'm
> > using also client authentication.. if you don't use it I think you can
> pass
> > null as TrustManager:
> >
> > sslCtx.init(kmf.getKeyManagers(), null, new SecureRandom());
>
> just to clarify, this is backwards. TrustManger is for establishing
> server trust, KeyManager is source of private keys for identifying
> yourself to the peer. so if not using client certificates, leave out
> the KeyManager.
>
> I try to mention this in the docs:
>
> http://developer.android.com/reference/javax/net/ssl/HttpsURLConnection.html
>
> >
> > So when you instantiate the RestTemplateObject:
> >
> > restTemplate = new RestTemplate(new
> MyClientHttpRequestFactory(context));
> >
> > Hope it helps!
> > Bye
> > Marco
> >
> > 2012/10/3 Brian Carlstrom <[email protected]>
> >>
> >> Anand,
> >>
> >> We have some doc here:
> >>
> >>
> http://developer.android.com/reference/javax/net/ssl/HttpsURLConnection.html
> >>
> >> the main thing is to make a custom TrustManager that trusts your
> >> self-signed cert. you seem to just be disabling hostname verification
> >> which is unnecessary if your cert's CN value matches your server
> >> hostname (and a bit dangerous in general)
> >>
> >> -bri
> >>
> >> On Wed, Oct 3, 2012 at 11:22 AM, Anand <[email protected]> wrote:
> >> > Hi Brian/Marco,
> >> >
> >> > I am looking do to a similar thing for our Android application.
> Access a
> >> > server that has a self signed certificate with Android Rest Template,
> on
> >> > Android 2.3. I tried to using the similar code that Marco used. This
> >> > however
> >> > does not do the job for me. Any suggestions would be really
> appreciated
> >> > because I am stuck.
> >> >
> >> > public class NullHostNameVerifier implements HostnameVerifier {
> >> >
> >> > public boolean verify(String hostname, SSLSession session) {
> >> > return true;
> >> > }
> >> > }
> >> >
> >> > public class MySimpleClientHttpRequestFactory extends
> >> > SimpleClientHttpRequestFactory {
> >> >
> >> > private final HostnameVerifier verifier;
> >> >
> >> > public MySimpleClientHttpRequestFactory(HostnameVerifier verifier)
> {
> >> > this.verifier = verifier;
> >> > }
> >> >
> >> > @Override
> >> > protected void prepareConnection(HttpURLConnection connection,
> String
> >> > httpMethod) throws IOException {
> >> > if (connection instanceof HttpsURLConnection) {
> >> > ((HttpsURLConnection)
> connection).setHostnameVerifier(verifier);
> >> > }
> >> > super.prepareConnection(connection, httpMethod);
> >> > }
> >> >
> >> > }
> >> >
> >> > HostnameVerifier nullVerifier = new NullHostNameVerifier();
> >> > requestFactory = new MySimpleClientHttpRequestFactory(nullVerifier);
> >> > }
> >> >
> >> >
> >> > RestTemplate restTemplate = new RestTemplate(requestFactory);
> >> > restTemplate.setRequestFactory(requestFactory);
> >> >
> >> >
> >> >
> >> >
> >> > On Friday, August 31, 2012 3:20:47 PM UTC-5, Brian Carlstrom wrote:
> >> >>
> >> >> I believe it will work with different store and key passwords if you
> >> >> supply the key password as the second argument to
> >> >> KeyManagerFactory.init, instead of the store password as you are
> doing
> >> >> here:
> >> >>
> >> >> kmf.init(keyStore, keyStorePassword.toCharArray())
> >> >>
> >> >> you already have supplied to the keyStorePassword when creating the
> >> >> keyStore, so its already decrypted, you need to give the second
> >> >> password to decrypt the individual key entry. note if you give
> >> >> different passwords to different keys, it has to be the password
> >> >> needed by the key returned by chooseClientAlias
> >> >>
> >> >> -bri
> >> >>
> >> >> On Fri, Aug 31, 2012 at 1:10 PM, Marco Serioli <[email protected]>
> >> >> wrote:
> >> >> > I've tried some test case and I found that I have problems when I
> try
> >> >> > to
> >> >> > generate certificates with keypass != storepass.
> >> >> >
> >> >> > In the first attempt I've made, I've used default SSL provider
> with
> >> >> > keypass
> >> >> > != storepass and I get:
> >> >> >
> >> >> >
> >> >> > error:140943F2:SSL routines:SSL3_READ_BYTES:sslv3 alert unexpected
> >> >> > message
> >> >> > (external/openssl/ssl/s3_pkt.c:1232 0x19bf40:0x00000003); nested
> >> >> > exception
> >> >> > is javax.net.ssl.SSLProtocolException: SSL handshake terminated:
> >> >> > ssl=0x182c70: Failure in SSL library, usually a protocol error
> >> >> >
> >> >> >
> >> >> > In the second attempt I've used HarmonyJSSE with keypass !=
> storepass
> >> >> > and I
> >> >> > get:
> >> >> > at java.lang.Thread.run(Thread.java:1020)
> >> >> >
> >> >> >
> >> >> > In third attempt I have tried to create new certificates, and
> >> >> > casually I
> >> >> > have used keypass == storepass with HarmonyJSSE. It gives me:
> >> >> >
> >> >> > I/O error: Fatal alert received bad_certificate; nested exception
> is
> >> >> > javax.net.ssl.SSLException: Fatal alert received bad_certificate
> >> >> >
> >> >> >
> >> >> > In the last attempt, using keypass == storepass and removing
> >> >> > HarmonyJSSE
> >> >> > it
> >> >> > works!
> >> >> >
> >> >> > I've also find in tomcat 6 documentation:
> >> >> >
> >> >> > Note: your private key password and keystore password should be
> the
> >> >> > same. If
> >> >> > they differ, you will get an error along the lines of
> >> >> > java.io.IOException:
> >> >> > Cannot recover key, as documented in Bugzilla issue 38217, which
> >> >> > contains
> >> >> > further references for this issue.
> >> >> >
> >> >> >
> >> >> > Thank you for helping me!!
> >> >> > you've been very kind
> >> >> >
> >> >> > 2012/8/31 Brian Carlstrom <[email protected]>
> >> >> >>
> >> >> >> That is good to hear. There have been some client cert fixes for
> the
> >> >> >> non-default provider post 4.1, so I'm not entirely surprised it
> is
> >> >> >> not
> >> >> >> working.
> >> >> >>
> >> >> >> -bri
> >> >> >>
> >> >> >>
> >> >> >> On Fri, Aug 31, 2012 at 2:41 AM, Marco Serioli <[email protected]>
>
> >> >> >> wrote:
> >> >> >>>
> >> >> >>> Using default provider... it works :D
> >> >> >>>
> >> >> >>>
> >> >> >>> 2012/8/29 Brian Carlstrom <[email protected]>
> >> >> >>>>
> >> >> >>>> In wireshark, I select the first packet, right click, "Decode
> >> >> >>>> As..."
> >> >> >>>> select "Transport" tab and "SSL" from the list
> >> >> >>>>
> >> >> >>>> then looking at the Protocol SSL and SSLv3 packets, i'll focus
> on
> >> >> >>>> the
> >> >> >>>> ones that might help identify the issue (there is some
> description
> >> >> >>>> of
> >> >> >>>> all
> >> >> >>>> this that might be helpful at
> >> >> >>>> http://en.wikipedia.org/wiki/Transport_Layer_Security)
> >> >> >>>>
> >> >> >>>> #4 is Client Hello from client to server
> >> >> >>>>
> >> >> >>>> #7 has 4 things from server to client
> >> >> >>>> Server Hello
> >> >> >>>> Certificate
> >> >> >>>> Certificate Request
> >> >> >>>> Server Hello Done
> >> >> >>>>
> >> >> >>>> select #7 and expanding the Secure Socket Layer messages at the
> >> >> >>>> bottom,
> >> >> >>>> you can see the Certificate Request contains the info being
> passed
> >> >> >>>> to
> >> >> >>>> the
> >> >> >>>> KeyManager include the types of RSA and RSA and same issuer
> >> >> >>>> repeated
> >> >> >>>> twice
> >> >> >>>>
> >> >> >>>> #10 has 3 things from client to server
> >> >> >>>> Certificate
> >> >> >>>> Client Key Exchange
> >> >> >>>> Certificate verify.
> >> >> >>>>
> >> >> >>>> selecting #10 and expanding the Certificate (that is the client
> >> >> >>>> certificate being sent to the server), we see it is certificate
> >> >> >>>> with
> >> >> >>>> Common
> >> >> >>>> Name (CN) as "MT Tablet Client"
> >> >> >>>>
> >> >> >>>> #12 is Change Cipher Spec from client to server
> >> >> >>>>
> >> >> >>>> #14 is Encrypted Handshake Message from client to server
> >> >> >>>>
> >> >> >>>> #16 is a fatal Alert about a Bad Certificate from the server to
> >> >> >>>> the
> >> >> >>>> client. that is resulting in your "Fatal alert received
> >> >> >>>> bad_certificate;
> >> >> >>>> nested exception is javax.net.ssl.SSLException: Fatal alert
> >> >> >>>> received
> >> >> >>>> bad_certificate". The server doesn't like what you sent. maybe
> >> >> >>>> because you
> >> >> >>>> aren't sending a certificate chain by returning a result from
> >> >> >>>> getCertificateChain above? But if I recall correctly, these
> were
> >> >> >>>> self
> >> >> >>>> signed, so there would be no chain.
> >> >> >>>>
> >> >> >>>> In any case, the " "Fatal alert received bad_certificate;
> nested
> >> >> >>>> exception is javax.net.ssl.SSLException: Fatal alert received
> >> >> >>>> bad_certificate"." is from the HarmonyJSSE provider, I'd try
> going
> >> >> >>>> back to
> >> >> >>>> the default provider to see what happens. I'd also do a similar
> >> >> >>>> tcpdump and
> >> >> >>>> compare with what is being sent in the chrome case, since
> clearly
> >> >> >>>> it
> >> >> >>>> is
> >> >> >>>> something it doesn't like about the "Certificate" message being
> >> >> >>>> sent
> >> >> >>>> from
> >> >> >>>> the client to the server.
> >> >> >>>>
> >> >> >>>> -bri
> >> >> >>>>
> >> >> >>>>
> >> >> >>>>
> >> >> >>>>
> >> >> >>>> On Wed, Aug 29, 2012 at 2:44 AM, Marco Serioli <
> [email protected]>
> >> >> >>>> wrote:
> >> >> >>>>>
> >> >> >>>>> Here is the dump!
> >> >> >>>>>
> >> >> >>>>> Thank you!
> >> >> >>>>> Marco
> >> >> >>>>>
> >> >> >>>>>
> >> >> >>>>> 2012/8/28 Brian Carlstrom <[email protected]>
> >> >> >>>>>>
> >> >> >>>>>> feel free to attach the tcpdump and I can summarize what it
> >> >> >>>>>> contains.
> >> >> >>>>>>
> >> >> >>>>>> -bri
> >> >> >>>>>>
> >> >> >>>>>> On Tue, Aug 28, 2012 at 1:00 AM, Marco Serioli
> >> >> >>>>>> <[email protected]>
> >> >> >>>>>> wrote:
> >> >> >>>>>> > Thank you for quick replies!
> >> >> >>>>>> >
> >> >> >>>>>> > I have the tcpdump of connection, now I just have to figure
> >> >> >>>>>> > out
> >> >> >>>>>> > how
> >> >> >>>>>> > to
> >> >> >>>>>> > interpret it :)
> >> >> >>>>>> >
> >> >> >>>>>> > But I do not understand why with chrome client
> authentication
> >> >> >>>>>> > works,
> >> >> >>>>>> > while
> >> >> >>>>>> > with Android not!
> >> >> >>>>>> >
> >> >> >>>>>> > 2012/8/27 Brian Carlstrom <[email protected]>
> >> >> >>>>>> >>
> >> >> >>>>>> >> I think the "bad_certificate" is just the server telling
> you
> >> >> >>>>>> >> it
> >> >> >>>>>> >> doesn't like your certificate. It seems odd that the
> client
> >> >> >>>>>> >> certificate is self signed. the server is presumably
> trying
> >> >> >>>>>> >> to
> >> >> >>>>>> >> confirm
> >> >> >>>>>> >> that the client certificate is trusted by it's trust
> manager,
> >> >> >>>>>> >> but
> >> >> >>>>>> >> does
> >> >> >>>>>> >> it really have the client's certificate in it's trust
> >> >> >>>>>> >> manager's
> >> >> >>>>>> >> key
> >> >> >>>>>> >> store? usually you would have one or more trusted CA issue
> >> >> >>>>>> >> both
> >> >> >>>>>> >> the
> >> >> >>>>>> >> client and server certs and just trust the CAs on both
> sides.
> >> >> >>>>>> >>
> >> >> >>>>>> >> if you want to confirm this really is just a "bad
> >> >> >>>>>> >> certificate"
> >> >> >>>>>> >> message
> >> >> >>>>>> >> from the server, you can use tcpdump. I realize I forgot
> to
> >> >> >>>>>> >> include
> >> >> >>>>>> >> the instructions before, so I'll append some notes before.
> I
> >> >> >>>>>> >> did
> >> >> >>>>>> >> check
> >> >> >>>>>> >> and it is in the emulator.
> >> >> >>>>>> >>
> >> >> >>>>>> >> -bri
> >> >> >>>>>> >>
> >> >> >>>>>> >> TCPDUMP
> >> >> >>>>>> >> - To start capturing to tcpdump.pck (interrupt when done)
> >> >> >>>>>> >> adb remount
> >> >> >>>>>> >> adb shell tcpdump -s 0 -w /sdcard/tcpdump.pck
> >> >> >>>>>> >> - add "host foo" after options for host filtering
> >> >> >>>>>> >> - To pull from device to host and examine with wireshark
> UI
> >> >> >>>>>> >> tool
> >> >> >>>>>> >> adb pull /sdcard/tcpdump.pck /tmp/tcpdump.pck
> >> >> >>>>>> >> wireshark /tmp/tcpdump.pck
> >> >> >>>>>> >>
> >> >> >>>>>> >>
> >> >> >>>>>> >> On Mon, Aug 27, 2012 at 2:52 AM, Marco Serioli
> >> >> >>>>>> >> <[email protected]>
> >> >> >>>>>> >> wrote:
> >> >> >>>>>> >> > Now I have followed this tutorial for generate
> clientAuth
> >> >> >>>>>> >> > keys:
> >> >> >>>>>> >> >
> >> >> >>>>>> >> >
> >> >> >>>>>> >> >
> >> >> >>>>>> >> >
> >> >> >>>>>> >> >
> >> >> >>>>>> >> >
> http://www.maximporges.com/2009/11/18/configuring-tomcat-ssl-clientserver-authentication/
>
> >> >> >>>>>> >> >
> >> >> >>>>>> >> > The only difference is that I don't use the same store
> for
> >> >> >>>>>> >> > both
> >> >> >>>>>> >> > key and
> >> >> >>>>>> >> > trust store.
> >> >> >>>>>> >> >
> >> >> >>>>>> >> > Now, with this new certificate alias isn't null, I got
> >> >> >>>>>> >> > "clientkey" as
> >> >> >>>>>> >> > alias.
> >> >> >>>>>> >> >
> >> >> >>>>>> >> > Executing your method I got the following log:
> >> >> >>>>>> >> >
> >> >> >>>>>> >> > alias=clientkey
> >> >> >>>>>> >> > privatekey=RSA
> >> >> >>>>>> >> > cert subject=CN=MT Tablet Client, OU=IT, O=CPMAPAVE,
> >> >> >>>>>> >> > L=Bienno,
> >> >> >>>>>> >> > ST=BS,
> >> >> >>>>>> >> > C=IT
> >> >> >>>>>> >> > cert issuer =CN=MT Tablet Client, OU=IT, O=CPMAPAVE,
> >> >> >>>>>> >> > L=Bienno,
> >> >> >>>>>> >> > ST=BS,
> >> >> >>>>>> >> > C=IT
> >> >> >>>>>> >> > --------------------------------
> >> >> >>>>>> >> > alias=servercert
> >> >> >>>>>> >> > cert subject=CN=MT Tablet Server, OU=IT, O=CPMAPAVE,
> >> >> >>>>>> >> > L=Bienno,
> >> >> >>>>>> >> > ST=BS,
> >> >> >>>>>> >> > C=IT
> >> >> >>>>>> >> > cert issuer =CN=MT Tablet Server, OU=IT, O=CPMAPAVE,
> >> >> >>>>>> >> > L=Bienno,
> >> >> >>>>>> >> > ST=BS,
> >> >> >>>>>> >> > C=IT
> >> >> >>>>>> >> >
> >> >> >>>>>> >> >
> >> >> >>>>>> >> > But now I got I/O error: Fatal alert received
> >> >> >>>>>> >> > bad_certificate;
> >> >> >>>>>> >> > nested
> >> >> >>>>>> >> > exception is javax.net.ssl.SSLException: Fatal alert
> >> >> >>>>>> >> > received
> >> >> >>>>>> >> > bad_certificate
> >> >> >>>>>> >> >
> >> >> >>>>>> >> >
> >> >> >>>>>> >> >
> >> >> >>>>>> >> >
> >> >> >>>>>> >> > 2012/8/27 Brian Carlstrom <[email protected]>
> >> >> >>>>>> >> >>
> >> >> >>>>>> >> >> I would use something like this to dump information
> from
> >> >> >>>>>> >> >> your
> >> >> >>>>>> >> >> KeyStore
> >> >> >>>>>> >> >> instance. you could also just print the toString of the
> >> >> >>>>>> >> >> certs
> >> >> >>>>>> >> >> for more
> >> >> >>>>>> >> >> general info, or just the "getSigAlgName" to see what
> >> >> >>>>>> >> >> algorithm
> >> >> >>>>>> >> >> was
> >> >> >>>>>> >> >> used.
> >> >> >>>>>> >> >>
> >> >> >>>>>> >> >> -bri
> >> >> >>>>>> >> >>
> >> >> >>>>>> >> >> Enumeration<String> e = keyStore.aliases();
> >> >> >>>>>> >> >> while (e.hasMoreElements()) {
> >> >> >>>>>> >> >> String alias = e.nextElement();
> >> >> >>>>>> >> >>
> >> >> >>>>>> >> >> System.out.println("--------------------------------");
> >> >> >>>>>> >> >> System.out.println("alias=" + alias);
> >> >> >>>>>> >> >> if (keyStore.entryInstanceOf(alias,
> >> >> >>>>>> >> >> KeyStore.PrivateKeyEntry.class)) {
> >> >> >>>>>> >> >> System.out.println("privatekey=" +
> >> >> >>>>>> >> >> keyStore.getKey(alias,
> keyStorePassword).getAlgorithm());
> >> >> >>>>>> >> >> for (Certificate certificate :
> >> >> >>>>>> >> >> keyStore.getCertificateChain(alias)) {
> >> >> >>>>>> >> >> X509Certificate cert =
> >> >> >>>>>> >> >> (X509Certificate)
> >> >> >>>>>> >> >> certificate;
> >> >> >>>>>> >> >> System.out.println("cert subject="
> +
> >> >> >>>>>> >> >> cert.getSubjectX500Principal());
> >> >> >>>>>> >> >> System.out.println("cert issuer ="
> +
> >> >> >>>>>> >> >> cert.getIssuerX500Principal());
> >> >> >>>>>> >> >> }
> >> >> >>>>>> >> >> } else if (keyStore.entryInstanceOf(alias,
> >> >> >>>>>> >> >> KeyStore.SecretKeyEntry.class)) {
> >> >> >>>>>> >> >> System.out.println("secretkey=" +
> >> >> >>>>>> >> >> keyStore.getKey(alias,
> keyStorePassword).getAlgorithm());
> >> >> >>>>>> >> >> } else if (keyStore.entryInstanceOf(alias,
> >> >> >>>>>> >> >> KeyStore.TrustedCertificateEntry.class)) {
> >> >> >>>>>> >> >> Certificate certificate =
> >> >> >>>>>> >> >> keyStore.getCertificate(alias);
> >> >> >>>>>> >> >> X509Certificate cert =
> (X509Certificate)
> >> >> >>>>>> >> >> certificate;
> >> >> >>>>>> >> >> System.out.println("cert subject=" +
> >> >> >>>>>> >> >> cert.getSubjectX500Principal());
> >> >> >>>>>> >> >> System.out.println("cert issuer =" +
> >> >> >>>>>> >> >> cert.getIssuerX500Principal());
> >> >> >>>>>> >> >> }
> >> >> >>>>>> >> >> }
> >> >> >>>>>> >> >>
> >> >> >>>>>> >> >>
> >> >> >>>>>> >> >> On Sun, Aug 26, 2012 at 11:38 PM, Marco Serioli
> >> >> >>>>>> >> >> <[email protected]>
> >> >> >>>>>> >> >> wrote:
> >> >> >>>>>> >> >> > Yes, chooseClientAlias returned null!
> >> >> >>>>>> >> >> >
> >> >> >>>>>> >> >> > I think that may be a problem with my certificate.
> >> >> >>>>>> >> >> >
> >> >> >>>>>> >> >> > I check it and let you know!
> >> >> >>>>>> >> >> > Marco
> >> >> >>>>>> >> >> >
> >> >> >>>>>> >> >> >
> >> >> >>>>>> >> >> > 2012/8/24 Brian Carlstrom <[email protected]>
> >> >> >>>>>> >> >> >>
> >> >> >>>>>> >> >> >> yes, basically during the handshake if a client cert
> is
> >> >> >>>>>> >> >> >> requested,
> >> >> >>>>>> >> >> >> the
> >> >> >>>>>> >> >> >> chooseClientAlias is called to select one. the
> selected
> >> >> >>>>>> >> >> >> key
> >> >> >>>>>> >> >> >> is
> >> >> >>>>>> >> >> >> specified by the returned String alias. Then it
> calls
> >> >> >>>>>> >> >> >> back
> >> >> >>>>>> >> >> >> with that
> >> >> >>>>>> >> >> >> alias to lookup the private key and certs. Since you
> >> >> >>>>>> >> >> >> are
> >> >> >>>>>> >> >> >> receiving a
> >> >> >>>>>> >> >> >> null in getPrivateKey, that seems to imply that
> >> >> >>>>>> >> >> >> chooseClientAlias
> >> >> >>>>>> >> >> >> returned null. Can you confirm that?
> >> >> >>>>>> >> >> >>
> >> >> >>>>>> >> >> >> So the next question is why it can't choose one. the
> >> >> >>>>>> >> >> >> arguments are
> >> >> >>>>>> >> >> >> used to filter the KeyStore contents. so it will
> look
> >> >> >>>>>> >> >> >> for
> >> >> >>>>>> >> >> >> an
> >> >> >>>>>> >> >> >> RSA or
> >> >> >>>>>> >> >> >> DSA cert, issued by one of the specified issuers. I
> >> >> >>>>>> >> >> >> will
> >> >> >>>>>> >> >> >> say
> >> >> >>>>>> >> >> >> that
> >> >> >>>>>> >> >> >> the
> >> >> >>>>>> >> >> >> issuers list is concerning. typically servers don't
> >> >> >>>>>> >> >> >> actually
> >> >> >>>>>> >> >> >> send
> >> >> >>>>>> >> >> >> that
> >> >> >>>>>> >> >> >> and if the server is sending something bogus, it
> might
> >> >> >>>>>> >> >> >> be
> >> >> >>>>>> >> >> >> over
> >> >> >>>>>> >> >> >> constraining the chooseClientAlias function.
> However,
> >> >> >>>>>> >> >> >> you
> >> >> >>>>>> >> >> >> can
> >> >> >>>>>> >> >> >> of
> >> >> >>>>>> >> >> >> course workaround by having your proxy implement
> your
> >> >> >>>>>> >> >> >> own
> >> >> >>>>>> >
>
> ...
--
You received this message because you are subscribed to the Google Groups
"Android Security Discussions" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/android-security-discuss.
For more options, visit https://groups.google.com/d/optout.
