Si desea cambiar el certificado que se utiliza en función de la cual se realiza la conexión, tendrá que configurar una SSLContext
para hacerlo, como se describe en esta respuesta: https://stackoverflow.com/a/3713147/372643
Por lo que yo sé, Eje 2 usa Apache HttpClient 3.x, por lo que deberá seguir su configuración de SSLContext
(y X509KeyManager
si es necesario). La manera más fácil podría ser configurar el manejador de protocolo global https
de Apache HttpClient con su SSLContext
, configurado con un X509KeyManager
configurado para elegir el certificado del cliente como lo requiera (a través de chooseClientAlias
).
Si los emisores y la Socket
conectada (probablemente la dirección remota) no son suficientes para decidir qué certificado elegir, puede que necesite implementar una lógica más compleja que casi inevitablemente requerirá una sincronización cuidadosa con el resto de su aplicación.
EDITAR:
Una vez que usted ha construido su SSLContext
y X509KeyManager
, es necesario pasarlos a Apache HttpClient 3.x. Para esto, puede construir su propio SecureProtocolSocketFactory, que construirá el socket desde este SSLContext
(a través de un SSLSocketFactory
, vea SSLContext
métodos). Hay ejemplos en el Apache HttpClient 3.x SSL guide. Evite EasySSLProtocolSocketFactory
, ya que no comprobará ningún certificado de servidor (lo que permite ataques MITM). También puedes probar this implementation.
Tenga en cuenta que en realidad sólo necesita para personalizar su X509KeyManager
, puede inicializar su SSLContext
(a través de init
) con null
para los otros parámetros a tener los valores por defecto (en particular, las configuraciones de seguridad por defecto).
Entonces, "instalar" esta SecureProtocolSocketFactory
a nivel mundial para Apache HttpClient 3.x utilizando algo como esto:
Protocol.registerProtocol("https", new Protocol("https",
(ProtocolSocketFactory)secureProtocolSocketFactory, 443));
¿Esto tiene en cuenta que se necesita el certificado actual para recuperar un mensaje con el nuevo certificado? Además, el cliente WS debe poder reemplazar el certificado en el almacén de claves porque no puede vivir fuera del almacén de claves y permanecer accesible a java. – Alfabravo