La falla del apretón de manos pudo haber ocurrido debido a varias razones:
- Conjuntos de cifrado incompatibles en uso por el cliente y el servidor. Esto requeriría que el cliente use (o habilite) un conjunto de cifrado compatible con el servidor.
- Versiones incompatibles de SSL en uso (el servidor puede aceptar solo TLS v1, mientras que el cliente solo puede usar SSL v3). Nuevamente, el cliente podría tener que asegurarse de que usa una versión compatible del protocolo SSL / TLS.
- Ruta de confianza incompleta para el certificado del servidor; El cliente probablemente no confíe en el certificado del servidor. Esto generalmente daría como resultado un error más detallado, pero es bastante posible. Por lo general, la solución es importar el certificado de CA del servidor en el almacén de confianza del cliente.
- El certificado se emite para un dominio diferente. Nuevamente, esto habría resultado en un mensaje más detallado, pero expondré la solución aquí en caso de que esta sea la causa. La resolución en este caso sería hacer que el servidor (no parece ser suyo) use el certificado correcto.
Como la falla subyacente no se puede identificar, es mejor activar el -Djavax.net.debug=allindicador para habilitar la depuración de la conexión SSL establecida. Con la depuración activada, puede determinar qué actividad en el protocolo de enlace ha fallado.
Actualizar
Según los detalles ahora disponibles, parece que el problema se debe a una ruta de confianza de certificado incompleta entre el certificado emitido al servidor y una CA raíz. En la mayoría de los casos, esto se debe a que el certificado de la CA raíz está ausente en el almacén de confianza, lo que lleva a la situación en la que no puede existir una ruta de confianza del certificado; el cliente no confía esencialmente en el certificado. Los navegadores pueden presentar una advertencia para que los usuarios puedan ignorar esto, pero no es el mismo caso para los clientes SSL (como la clase HttpsURLConnection , o cualquier biblioteca de Cliente HTTP como Apache HttpComponents Client ).
La mayoría de estas clases / bibliotecas de clientes dependerían del almacén de confianza utilizado por la JVM para la validación del certificado. En la mayoría de los casos, este será el cacertsarchivo en el directorio JRE_HOME / lib / security. Si la ubicación del almacén de confianza se ha especificado utilizando la propiedad del sistema JVM javax.net.ssl.trustStore, entonces el almacén en esa ruta suele ser el utilizado por la biblioteca del cliente. Si tiene dudas, eche un vistazo a su Merchantclase y descubra la clase / biblioteca que está utilizando para establecer la conexión.
Agregar el certificado del servidor que emite CA a este almacén de confianza debería resolver el problema. Puede consultar mi respuesta en una pregunta relacionada sobre cómo obtener herramientas para este propósito, pero la utilidad Java keytool es suficiente para este propósito.
Advertencia : El almacén de confianza es esencialmente la lista de todas las CA en las que confía. Si coloca un certificado que no pertenece a una CA en la que no confía, las conexiones SSL / TLS a los sitios que tienen certificados emitidos por esa entidad se pueden descifrar si la clave privada está disponible.
Actualización n. ° 2: comprensión del resultado de la traza JSSE
El almacén de claves y los almacenes de confianza utilizados por la JVM generalmente se enumeran al principio, algo así como lo siguiente:
keyStore is :
keyStore type is : jks
keyStore provider is :
init keystore
init keymanager of type SunX509
trustStore is: C:\Java\jdk1.6.0_21\jre\lib\security\cacerts
trustStore type is : jks
trustStore provider is :
Si se usa el almacén de confianza incorrecto, deberá volver a importar el certificado del servidor al correcto o volver a configurar el servidor para usar el que figura en la lista (no se recomienda si tiene varias JVM, y todas se usan para diferentes necesidades).
Si desea verificar si la lista de certificados de confianza contiene los certificados requeridos, entonces hay una sección para el mismo, que comienza como:
adding as trusted cert:
Subject: CN=blah, O=blah, C=blah
Issuer: CN=biggerblah, O=biggerblah, C=biggerblah
Algorithm: RSA; Serial number: yadda
Valid from SomeDate until SomeDate
Deberá buscar si la CA del servidor es un tema.
El proceso de reconocimiento tendrá algunas entradas destacadas (necesitará conocer SSL para comprenderlas en detalle, pero con el fin de depurar el problema actual, será suficiente saber que generalmente se informa un fallo de reconocimiento de manos en ServerHello.
1. ClientHello
Se informará una serie de entradas cuando se inicie la conexión. El primer mensaje enviado por el cliente en una configuración de conexión SSL / TLS es el mensaje ClientHello, que generalmente se informa en los registros como:
*** ClientHello, TLSv1
RandomCookie: GMT: 1291302508 bytes = { some byte array }
Session ID: {}
Cipher Suites: [SSL_RSA_WITH_RC4_128_MD5, SSL_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, SSL_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_DES_CBC_SHA, SSL_DHE_RSA_WITH_DES_CBC_SHA, SSL_DHE_DSS_WITH_DES_CBC_SHA, SSL_RSA_EXPORT_WITH_RC4_40_MD5, SSL_RSA_EXPORT_WITH_DES40_CBC_SHA, SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA, SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA]
Compression Methods: { 0 }
***
Tenga en cuenta los conjuntos de cifrado utilizados. Esto podría tener que estar de acuerdo con la entrada en su archivo merchant.properties, ya que la biblioteca del banco podría emplear la misma convención. Si la convención utilizada es diferente, no hay motivo de preocupación, ya que ServerHello lo indicará si el conjunto de cifrado es incompatible.
2. ServerHello
El servidor responde con un ServerHello, que indicará si la configuración de la conexión puede continuar. Las entradas en los registros suelen ser del siguiente tipo:
*** ServerHello, TLSv1
RandomCookie: GMT: 1291302499 bytes = { some byte array}
Cipher Suite: SSL_RSA_WITH_RC4_128_SHA
Compression Method: 0
***
Tenga en cuenta la suite de cifrado que ha elegido; Esta es la mejor suite disponible tanto para el servidor como para el cliente. Por lo general, el conjunto de cifrado no se especifica si hay un error. El certificado del servidor (y opcionalmente toda la cadena) es enviado por el servidor, y se encuentra en las entradas como:
*** Certificate chain
chain [0] = [
[
Version: V3
Subject: CN=server, O=server's org, L=server's location, ST =Server's state, C=Server's country
Signature Algorithm: SHA1withRSA, OID = some identifer
.... the rest of the certificate
***
Si la verificación del certificado se realizó correctamente, encontrará una entrada similar a:
Found trusted certificate:
[
[
Version: V1
Subject: OU=Server's CA, O="Server's CA's company name", C=CA's country
Signature Algorithm: SHA1withRSA, OID = some identifier
Uno de los pasos anteriores no habría tenido éxito, lo que resultaría en la falla de apretón de manos, ya que el apretón de manos generalmente se completa en esta etapa (en realidad no, pero las etapas posteriores del apretón de manos generalmente no causan una falla del apretón de manos). Deberá averiguar qué paso ha fallado y publicar el mensaje apropiado como una actualización de la pregunta (a menos que ya haya entendido el mensaje y sepa qué hacer para resolverlo).