Certificate-Pinning | Certificate Pinning implementation in Android | TLS library

The handshake issue is due to Jamendo API using an old deprecated TLS protocol version (1.0) and not support newer protocol versions:
* https://github.com/square/okhttp/issues/4670 * https://medium.com/square-corner-blog/okhttp-3-13-requires-android-5-818bb78d07ce

Side-notes: I would definitely opt against a custom TrustManager implementation, this would only make sense e.g. if your endpoint is using a self-signed certificate. As a basic check i would verify that your Android System TrustStore is working by trying to open the Jamendo URL directly on the phone/emulator browser to see if you get any issues? Pinning provides additional protection but does not resolve basic handshake issue you are seeing.

Here is an implementation using official okhttp3 sample code. It is possible to create a trusted OkHttpClient using a custom certificate. I've put the .cer certificate in res/raw then read it in using the trustedCertificatesInputStream() method.

SslStream will never send the whole chain (except for self-issued certificates). The convention is to send everything except for the root, because the other side either already has and trusts the root or doesn't have (thus/or doesn't trust the root), and either way it was a waste of bandwidth.

But SslStream can only send the intermediates when it understands the intermediates.

Yes, if you do not use Application Authenticity you can remove these files. However, can you say why you'd want to do that ?

When a CA is compromised, the attacker has the CA's private key. Then the attacker has the same power as a trusted CA, meaning that he can issue certificates for any domains. If this happens, without public key pinning (HPKP), all sites are immediately vulnerable to MITM attacks by this attacker, until clients distrust the compromised CA.

HPKP tries to mitigate this issue by allowing site operations to designate which root CA or which leaf certificate's public keys you want browsers to trust. For instance, if you pin Let's Encrypt and GlobalSign's root certificates, then a compromise of any other CA won't affect you at all.

To answer your questions:

1) No, not symmetric keys. It is the private key of the CA, used for signing not encrypting, that gets compromised.

2) It doesn't matter, because the site is not compromised; only the CA is compromised. In other words, the attacker doesn't have the private keys of your site. If he wants to attack, he will have to present a different public key that he generates himself.

I hope this answer helps to clarify.

Firstly validation of the SSL Certificate is one of the basic approaches that could be provided by the developer to provide secure connection between application and server.

Nice statements to read OWASP.

1)Usage of the Transport Layer Security in the application with iOS 8 will enchant you're app with secure connection between application and server. This could be reached by providing of the SSL pinning.

2)Self-signed certificate:

In cryptography and computer security, a self-signed certificate is an identity certificate that is signed by the same entity whose identity it certifies.

As possible to conclude you going to signed certificate by you're self.The main disadvantage is in possibility of the Man-in-the-middle attack because of the Self-signed certificates cannot be revoked.

If the aim is to provide secure connection try not to use some third parties I think you understand why.

My way is usage of the SSL pining and OpenSSL