Poignée de main échec avec Java quand j'essaie de faire un POST

J'essaie de contacter *** et envoyer des données à l'aide de POST.

- Je utiliser jersey-bundle-1.18.jar que j'ai importé dans mon projet Eclipse. C'est mon code:

    Client client = Client.create();
    WebResource webResource = client.resource("https://somesite.com");
    MultivaluedMap<String, String> map = new MultivaluedMapImpl();
    map.putSingle("key_name", API_KEY_NAME);
    map.putSingle("key_value", API_KEY_VALUE);
    map.putSingle("message", "Test");
    map.putSingle("extension", "+0012345678");
    ClientResponse response = webResource.type("application/x-www-form-urlencoded")
                 .post(ClientResponse.class, map); //throws exception here
    return response.toString();

Lorsque j'exécute mon code j'obtiens javax.net.le protocole ssl.SSLHandshakeException. Le certificat utilisé par le site est de StartCom, et je ne pense pas que cette autorité de certification est en Java par défaut de truststore, au moins pas dans la version 6 de Java, selon cette affiche

J'ai couru mon programme avec la JVM drapeau -Djavax.net.debug=tous et c'est ce que j'ai:

trigger seeding of SecureRandom
done seeding SecureRandom
Ignoring unavailable cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
Ignoring unavailable cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA
Ignoring unavailable cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA
Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256
Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
Ignoring unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA256
Ignoring unavailable cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
Ignoring unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
Ignoring unavailable cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA
Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384
Ignoring unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
Ignoring unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256
Ignoring unavailable cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA
Ignoring unavailable cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA
Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_128_CBC_SHA256
Allow unsafe renegotiation: false
Allow legacy hello messages: true
Is initial handshake: true
Is secure renegotiation: false
main, setSoTimeout(0) called
%% No cached client session
*** ClientHello, TLSv1
RandomCookie:  GMT: 1391505439 bytes = { 186, 52, 225, 5, 67, 137, 170, 128, 220, 41, 178, 86, 199, 17, 150, 190, 23, 47, 217, 126, 162, 34, 68, 40, 216, 221, 193, 108 }
Session ID:  {}
Cipher Suites: [TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_RC4_128_SHA, TLS_ECDHE_RSA_WITH_RC4_128_SHA, SSL_RSA_WITH_RC4_128_SHA, TLS_ECDH_ECDSA_WITH_RC4_128_SHA, TLS_ECDH_RSA_WITH_RC4_128_SHA, TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_RC4_128_MD5, TLS_EMPTY_RENEGOTIATION_INFO_SCSV]
Compression Methods:  { 0 }
Extension elliptic_curves, curve names: {secp256r1, sect163k1, sect163r2, secp192r1, secp224r1, sect233k1, sect233r1, sect283k1, sect283r1, secp384r1, sect409k1, sect409r1, secp521r1, sect571k1, sect571r1, secp160k1, secp160r1, secp160r2, sect163r1, secp192k1, sect193r1, sect193r2, secp224k1, sect239k1, secp256k1}
Extension ec_point_formats, formats: [uncompressed]
Extension server_name, server_name: [host_name: ***]
***
[write] MD5 and SHA1 hashes:  len = 176
0000: 01 00 00 AC 03 01 53 F1   B0 1F BA 34 E1 05 43 89  ......S....4..C.
0010: AA 80 DC 29 B2 56 C7 11   96 BE 17 2F D9 7E A2 22  ...).V...../..."
0020: 44 28 D8 DD C1 6C 00 00   2A C0 09 C0 13 00 2F C0  D(...l..*...../.
0030: 04 C0 0E 00 33 00 32 C0   07 C0 11 00 05 C0 02 C0  ....3.2.........
0040: 0C C0 08 C0 12 00 0A C0   03 C0 0D 00 16 00 13 00  ................
0050: 04 00 FF 01 00 00 59 00   0A 00 34 00 32 00 17 00  ......Y...4.2...
0060: 01 00 03 00 13 00 15 00   06 00 07 00 09 00 0A 00  ................
0070: 18 00 0B 00 0C 00 19 00   0D 00 0E 00 0F 00 10 00  ................
0080: 11 00 02 00 12 00 04 00   05 00 14 00 08 00 16 00  ................
main, WRITE: TLSv1 Handshake, length = 176
[Raw write]: length = 181
0000: 16 03 01 00 B0 01 00 00   AC 03 01 53 F1 B0 1F BA  ...........S....
0010: 34 E1 05 43 89 AA 80 DC   29 B2 56 C7 11 96 BE 17  4..C....).V.....
0020: 2F D9 7E A2 22 44 28 D8   DD C1 6C 00 00 2A C0 09  /..."D(...l..*..
0030: C0 13 00 2F C0 04 C0 0E   00 33 00 32 C0 07 C0 11  .../.....3.2....
0040: 00 05 C0 02 C0 0C C0 08   C0 12 00 0A C0 03 C0 0D  ................
0050: 00 16 00 13 00 04 00 FF   01 00 00 59 00 0A 00 34  ...........Y...4
0060: 00 32 00 17 00 01 00 03   00 13 00 15 00 06 00 07  .2..............
0070: 00 09 00 0A 00 18 00 0B   00 0C 00 19 00 0D 00 0E  ................
0080: 00 0F 00 10 00 11 00 02   00 12 00 04 00 05 00 14  ................
0090: 00 08 00 16 00 0B 00 02   01 00 00 00 00 17 00 15  ................
[Raw read]: length = 5
0000: 15 03 01 00 02                                     .....
[Raw read]: length = 2
0000: 02 28                                              .(
main, READ: TLSv1 Alert, length = 2
main, RECV TLSv1 ALERT:  fatal, handshake_failure
main, called closeSocket()
main, handling exception: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
main, called close()
main, called closeInternal(true)
Exception in thread "main" com.sun.jersey.api.client.ClientHandlerException: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure

Quel est le problème et comment puis-je le faire fonctionner?

EDIT: Comme mentionné ci-dessous, j'ai téléchargé Java Cryptography Extension (JCE) Force Illimitée de la Compétence de la Politique de Fichiers, mais pour Java 7, puisque c'est la version de Java que j'utilise et copié les fichiers jar /lib/security selon les instructions.

J'ai couru le programme de nouveau, et est resté coincé à une autre exception. J'ai copié un couple de lignes à partir de l'Éclipse de la console:

%% Invalidé: [Session-1, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA] principal,
ENVOYER TLSv1 ALERTE: fatal, description = certificate_unknown principal,
ÉCRIRE: TLSv1 Alerte, longueur = 2 [Raw écrire]: longueur = 7 0000: 15 03 01
00 02 02 2E ....... principal, appelé
closeSocket() principal, la manipulation d'exception:
javax.net.le protocole ssl.SSLHandshakeException:
soleil.de sécurité.programme de validation.ValidatorException: PKIX chemin d'accès du bâtiment a échoué:
soleil.de sécurité.fournisseur de.certpath.SunCertPathBuilderException: impossible de
trouver la validité de la certification chemin demandé cible

Cette fois, il semble que le certificat StartCom en Java truststore est absent à la dernière. Je suis sûr que c'est possible de surmonter ce problème, mais depuis que j'ai envisager de déployer mon code dans un fichier jar qui peut être utilisé par d'autres personnes, je ne pense pas que c'est une solution possible pour permettre aux personnes de remplacer leur entreprise criminelle commune, la Politique de fichiers afin d'utiliser ma bibliothèque.

J'ai été un peu interloqué quand je l'ai rencontré pour la première fois cette erreur parce que j'avais effectivement exécutées sur le même code avant avec des résultats satisfaisants, mais quand j'y pense, j'ai utilisé OpenJDK et non Oracle de propriété JDK. Lorsque j'ai utilisé OpenJDK je n'ai pas eu le problème de chiffrement soit. Donc, il me semble que j'ai deux mauvais choix ici:

1). Forcer les utilisateurs à changer leur Kit de Développement Java pour OpenJDK, ou mon service/bibliothèque ne fonctionne pas.

2). Forcer les utilisateurs à remplacer la JCE de la Politique de fichiers de leur JRE et importer le certificat StartCom en Java du fichier de stockage des clés, de l'e.g à l'aide de keytool, ou peut-être je pourrais charger le certificat au cours de l'exécution?

Est un peu cela correct?

EDIT2:

Voici comment j'ai créé mon propre truststore avec les certificats disponibles à http://www.startssl.com/certs/ca-bundle.crt

try {
//Read the certificate bundle from disk
CertificateFactory cf = CertificateFactory.getInstance("X.509");
Certificate ca = cf.generateCertificate(getClass().getResourceAsStream("ca-bundle.crt")); //the file ca-bundle.crt should be in the same folder as your .java files
//Create a KeyStore containing our trusted CAs
KeyStore keyStore = KeyStore.getInstance(KeyStore.getDefaultType());
keyStore.load(null, null);
keyStore.setCertificateEntry("ca", ca);
//Create a TrustStore that trusts the CAs in our KeyStore
TrustManagerFactory tmf = TrustManagerFactory.getInstance(TrustManagerFactory.getDefaultAlgorithm());
tmf.init(keyStore);
//Create an SSLContext that uses our TrustManager
sslContext = SSLContext.getInstance("TLS");
sslContext.init(null, tmf.getTrustManagers(), null);
} catch (CertificateException | KeyStoreException | NoSuchAlgorithmException | KeyManagementException | IOException e) {
e.printStackTrace();
}

Il est désormais possible de communiquer avec le serveur de manière sécurisée. Vous pouvez créer un HttpClient avec votre custom SSLContext comme ceci:

CloseableHttpClient client = HttpClients.custom().setSslcontext(sslContext).build();