java - CertificateException: no se ha encontrado ningún nombre que coincida con ssl.someUrl.de

plesk

Question

Estoy intentando conectarme a uno de mis servidores a través de ssl, con Java. Probé muchas opciones aquí es mi mejor intento:

Genero un jssecacerts con el script recommendet: http://blogs.oracle.com/andreas/resource/InstallCert.java con el comando: java InstallCert ssl.someUrl.de changeit

después de esto, hice el comando por segunda vez:

Loading KeyStore jssecacerts...
Opening connection to ssl.someUrl.de:443...
Starting SSL handshake...
No errors, certificate is already trusted
Server sent 1 certificate(s):
1 Subject [email protected], CN=plesk, OU=Plesk, O=Parallels, L=Hernd
on, ST=Virginia, C=US
Issuer [email protected], CN=plesk, OU=Plesk, O=Parallels, L=Hernd
on, ST=Virginia, C=US
sha1 f1 0d 2c 54 05 e1 32 19 a0 52 5e e1 81 6c a3 a5 83 0d dd 67
md5 f0 b3 be 5e 5f 6e 90 d1 bc 57 7a b2 81 ce 7d 3d
Enter certificate to add to trusted keystore or ''q'' to quit: [1]

Copié el archivo al directorio predeterminado y cargué el certificado en Java trustStore

System.setProperty("javax.net.ssl.trustStore", "C://Program Files (x86)//Java//jre6//lib//security//jssecacerts");
System.setProperty("javax.net.ssl.trustStorePassword","changeit");

Luego trato de conectar

URL url = new URL("https://ssl.someUrl.de/");
URLConnection conn = url.openConnection();
BufferedReader rd = new BufferedReader(new InputStreamReader(conn.getInputStream()));

Y obtengo el error en la 3ra línea: (No se encontró el nombre que coincida con ssl.someUrl.de)

javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No name matching ssl.someUrl.de found

¿Es esta causa del certificado plesk predeterminado o es algo diferente?

Configuración: JRE 6.20, Netbeans 6.8, Windows7 64bit

Answer 1

Creé un método fixUntrustCertificate (), así que cuando estoy tratando con un dominio que no está en CA de confianza, puede invocar el método antes de la solicitud. Este código funcionará después de java1.4. Este método se aplica a todos los hosts:

public void fixUntrustCertificate() throws KeyManagementException, NoSuchAlgorithmException{
TrustManager[] trustAllCerts = new TrustManager[]{
new X509TrustManager() {
public java.security.cert.X509Certificate[] getAcceptedIssuers() {
return null;
}
public void checkClientTrusted(X509Certificate[] certs, String authType) {
}
public void checkServerTrusted(X509Certificate[] certs, String authType) {
}
}
};
SSLContext sc = SSLContext.getInstance("SSL");
sc.init(null, trustAllCerts, new java.security.SecureRandom());
HttpsURLConnection.setDefaultSSLSocketFactory(sc.getSocketFactory());
HostnameVerifier allHostsValid = new HostnameVerifier() {
public boolean verify(String hostname, SSLSession session) {
return true;
}
};
// set the allTrusting verifier
HttpsURLConnection.setDefaultHostnameVerifier(allHostsValid);
}

Answer 2

El nombre del servidor debe ser el mismo que el nombre / apellido que se da al crear un certificado

Answer 3

En Java 8 puede omitir la comprobación del nombre del servidor con el siguiente código:

HttpsURLConnection.setDefaultHostnameVerifier ((hostname, session) -> true);

Sin embargo, esto debe usarse solo en desarrollo.

Answer 4

He encontrado una buena resolución aquí: mkyong.com/webservices/jax-ws/…

Pero mi problema era un poco diferente y lo resolvió de manera diferente.

El servicio web estaba en el host remoto. Por ejemplo: https://some.remote.host/MyWebService?wsdl

Pero solo estaba disponible por IP para cualquier cliente, pero se creó un certificado para el dominio: some.remote.host (CN = some.remote.host). Y este dominio no se puede resolver por IP porque no se presenta en DNS).

Entonces apareció el mismo problema: si utilizo IP para conectarme al servicio web mediante ssl, no puedo acceder a él porque el certificado CN = algo.remote.host y no es igual al nombre de host que he especificado (es decir, IP de host) .

Lo resolví haciendo coincidir este nombre de host con IP en el archivo / etc / hosts. El problema fue arreglado.

Pero en el caso de que el servicio web esté alojado en el servidor de la aplicación localhost, piense que debería resolverse como se describe en su artículo.

Answer 5

Parece que el certificado del servidor al que intenta conectarse no coincide con su nombre de host.

Cuando un cliente HTTPS se conecta a un servidor, verifica que el nombre de host en el certificado coincida con el nombre de host del servidor. No es suficiente que un certificado sea confiable, también tiene que coincidir con el servidor con el que desea hablar. (Como analogía, incluso si confía en que un pasaporte sea legítimo, igual debe verificar que sea el de la persona con la que desea hablar, no solo el pasaporte en el que confíe que es legítimo).

En HTTP, esto se hace comprobando que:

• el certificado contiene una entrada de nombre alternativo de sujeto de DNS (esto es una extensión estándar) que coincide con el nombre de host;

• en su defecto, el último CN de su nombre distinguido (este es el nombre principal si lo desea) coincide con el nombre de host. (Ver RFC 2818.)

Es difícil decir cuál es el nombre alternativo del sujeto sin tener el certificado (aunque, si se conecta con su navegador y verifica su contenido en más detalles, debería poder verlo). El nombre completo del sujeto parece ser:

[email protected], CN=plesk, OU=Plesk, O=Parallels, L=Herndon, ST=Virginia, C=US

(Por lo tanto, necesitaría ser CN = ssl.someUrl.de en lugar de CN = plesk, si no tiene un nombre alternativo de sujeto con DNS: ssl.someUrl.de ya; supongo que no es así).

Puede omitir la verificación del nombre de host usando HttpsURLConnection.setHostnameVerifier(..) . No debería ser demasiado difícil escribir un HostnameVerifier personalizado que invalide la verificación, aunque sugeriría que lo haga solo cuando el certificado sea el relacionado aquí específicamente. Debería poder obtenerlo utilizando el argumento SSLSession y su método getPeerCertificates ().

(Además, no es necesario que configure las propiedades de javax.net.ssl. * De la forma en que lo ha hecho, ya que de todos modos está utilizando los valores predeterminados).

Alternativamente, si tiene control sobre el servidor al que se está conectando y su certificado, puede crear un certificado que coincida con las reglas de denominación anteriores (CN debería ser suficiente, aunque el nombre alternativo del sujeto sea una mejora). Si un certificado autofirmado es lo suficientemente bueno para lo que usted nombra, asegúrese de que su nombre común (CN) sea el nombre de host con el que está tratando de hablar (no la URL completa, solo el nombre de host).