He habilitado https en tomcat y tengo un certificado autofirmado para la autenticación del servidor. Creé un cliente http utilizando Apache httpClient. Establecí un administrador de confianza cargando el certificado del servidor. El cliente http puede conectarse con el servidor sin problemas. Para ver lo que está pasando He activado la depuración:Uso de httpclient de Apache para https
System.setProperty("javax.net.debug", "ssl");
vi lo siguiente, que no puedo entender en absoluto:
***
adding as trusted cert:
Subject: CN=Me, OU=MyHouse, O=Home, L=X, ST=X, C=BB
Issuer: CN=Me, OU=MyHouse, O=Home, L=X, ST=X, C=BB
Algorithm: RSA; Serial number: 0x4d72356b
Valid from Sat Mar 05 15:06:51 EET 2011 until Fri Jun 03 16:06:51 EEST 2011
mi certificado se muestra y se añade al almacén de confianza (como yo lo veo) . Entonces:
trigger seeding of SecureRandom
done seeding SecureRandom
Aquí es la parte de las trazas de depuración que no entiendo:
trustStore is: C:\Program Files\Java\jre6\lib\security\cacerts
trustStore type is : jks
trustStore provider is :
init truststore
adding as trusted cert:
Subject: CN=SwissSign Platinum CA - G2, O=SwissSign AG, C=CH
Issuer: CN=SwissSign Platinum CA - G2, O=SwissSign AG, C=CH
Algorithm: RSA; Serial number: 0x4eb200670c035d4f
Valid from Wed Oct 25 11:36:00 EEST 2006 until Sat Oct 25 11:36:00 EEST 2036
adding as trusted cert:
Subject: [email protected], CN=http://www.valicert.com/, OU=ValiCert Class 1 Policy Validation Authority, O="ValiCert, Inc.", L=ValiCert Validation Network
Issuer: [email protected], CN=http://www.valicert.com/, OU=ValiCert Class 1 Policy Validation Authority, O="ValiCert, Inc.", L=ValiCert Validation Network
Algorithm: RSA; Serial number: 0x1
Valid from Sat Jun 26 01:23:48 EEST 1999 until Wed Jun 26 01:23:48 EEST 2019
Parece que también utiliza el almacén de confianza de Java por defecto! Mi pregunta es por qué sucede esto?
En mi código especifico explícitamente un trust-store específico para usar (a través de truststoremanagers). Esperaba que solo esto fuera usado. Parece que tanto mi almacén de confianza como el valor predeterminado de java se están utilizando. ¿Es así como se supone que debe funcionar?
ACTUALIZACIÓN:
He intentado lo siguiente:
System.out.println("TMF No:"+tmf.getTrustManagers().length);
System.out.println("Class is "+tmf.getTrustManagers()[0].getClass().getName());
pensé que debería ver 2 gerentes de confianza, ya que 2 de claves (la mía y por defecto de Java parecen utilizarse).
¡Pero el resultado fue solo 1 administrador de confianza!
TMF No:1
Class is com.sun.net.ssl.internal.ssl.X509TrustManagerImpl
Update2: Como se puede ver en el código abajo especifico mi keystore.My expectativa es que sólo esto se debe utilizar (no esta y cacert así)
HttpClient client = new DefaultHttpClient();
SSLContext sslContext = SSLContext.getInstance("TLS");
TrustManagerFactory tmf = TrustManagerFactory.getInstance(TrustManagerFactory.getDefaultAlgorithm());
KeyStore ks = KeyStore.getInstance("JKS");
File trustFile = new File("clientTrustStore.jks");
ks.load(new FileInputStream(trustFile), null);
tmf.init(ks);
sslContext.init(null, tmf.getTrustManagers(),null);
SSLSocketFactory sf = new SSLSocketFactory(sslContext);
sf.setHostnameVerifier(SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER);
Scheme scheme = new Scheme("https", sf, 443);
client.getConnectionManager().getSchemeRegistry().register(scheme);
httpGet = new HttpGet("https://localhost:8443/myApp");
HttpResponse httpResponse = client.execute(httpGet);
¿El no tiene sentido para mí.
Esta es una buena prueba.Gracias por su ayuda – Cratylus
Hola Oleg, estoy enfrentando un problema similar, pero solo cuando estoy enviando una solicitud POST y no a través de GET. ¿Alguna idea? – Abhishek
Entonces, ¿hay algún error en este lugar que podamos rastrear para encontrar una solución? – pulkitsinghal