OkHttp javax.net.ssl.SSLPeerUnverifiedException: nombre de host dominio.com no verificado

Llevo días intentando que esto funcione. Estoy tratando de conectarme a mi servidor a través de https con un certificado autofirmado. No creo que haya páginas o ejemplos que no haya leído hasta ahora.

Que he hecho:

1. Creé el almacén de claves bks siguiendo este tutorial: http://blog.crazybob.org/2010/02/android-trusting-ssl-certificates.html

Usa openssl s_client -connect domain.com:443 para obtener el certificado del servidor. Luego crea un almacén de claves bks usando un castillo hinchable.

2. Leer el almacén de claves creado desde la carpeta sin procesar, agregarlo a sslfactory y luego a OkHttpClient. Me gusta esto:

   public ApiService() {
       mClient = new OkHttpClient();
       mClient.setConnectTimeout(TIMEOUT_SECONDS, TimeUnit.SECONDS);
       mClient.setReadTimeout(TIMEOUT_SECONDS, TimeUnit.SECONDS);
       mClient.setCache(getCache());
       mClient.setCertificatePinner(getPinnedCerts());
       mClient.setSslSocketFactory(getSSL());
   }
   
   protected SSLSocketFactory getSSL() {
       try {
           KeyStore trusted = KeyStore.getInstance("BKS");
           InputStream in = Beadict.getAppContext().getResources().openRawResource(R.raw.mytruststore);
           trusted.load(in, "pwd".toCharArray());
           SSLContext sslContext = SSLContext.getInstance("TLS");
           TrustManagerFactory trustManagerFactory = TrustManagerFactory.getInstance(TrustManagerFactory.getDefaultAlgorithm());
           trustManagerFactory.init(trusted);
           sslContext.init(null, trustManagerFactory.getTrustManagers(), null);
           return sslContext.getSocketFactory();
       } catch(Exception e) {
           e.printStackTrace();
       }
       return null;
   }
   
   public CertificatePinner getPinnedCerts() {
       return new CertificatePinner.Builder()
               .add("domain.com", "sha1/theSha=")
               .build();
   }
   

3. Esto por alguna razón esto siempre genera un SSLPeerUnverifiedException con o sin el almacén de claves. Y con o sin el CertificatePinner.

   javax.net.ssl.SSLPeerUnverifiedException: Hostname domain.com not verified: 0         
    W/System.err﹕ certificate: sha1/theSha=
    W/System.err﹕ DN: 1.2.840.113549.1.9.1=#1610696e666f40626561646963742e636f6d,CN=http://domain.com,OU=development,O=domain,L=Valencia,ST=Valencia,C=ES
    W/System.err﹕ subjectAltNames: []
    W/System.err﹕ at com.squareup.okhttp.internal.http.SocketConnector.connectTls(SocketConnector.java:124)
    W/System.err﹕ at com.squareup.okhttp.Connection.connect(Connection.java:143)
    W/System.err﹕ at com.squareup.okhttp.Connection.connectAndSetOwner(Connection.java:185)
    W/System.err﹕ at com.squareup.okhttp.OkHttpClient$1.connectAndSetOwner(OkHttpClient.java:128)
    W/System.err﹕ at com.squareup.okhttp.internal.http.HttpEngine.nextConnection(HttpEngine.java:341)
    W/System.err﹕ at com.squareup.okhttp.internal.http.HttpEngine.connect(HttpEngine.java:330)
    W/System.err﹕ at com.squareup.okhttp.internal.http.HttpEngine.sendRequest(HttpEngine.java:248)
    W/System.err﹕ at com.squareup.okhttp.Call.getResponse(Call.java:273)
    W/System.err﹕ at com.squareup.okhttp.Call$ApplicationInterceptorChain.proceed(Call.java:230)
    W/System.err﹕ at com.squareup.okhttp.Call.getResponseWithInterceptorChain(Call.java:201)
    W/System.err﹕ at com.squareup.okhttp.Call.execute(Call.java:81)
    ...
   

¿Qué estoy haciendo mal?

Tuve el mismo problema; sin embargo, necesitaba que mi aplicación funcionara en varios entornos de ensayo, todos los cuales tenían certificados autofirmados. Para empeorar las cosas, podrían cambiar esos certificados sobre la marcha.

Para solucionar esto, cuando me conectaba solo a la etapa de ensayo, agregué un SSLSocketFactory que confiaba en todos los certificados. Esto solucionó el error de Java, sin embargo, me dejó con la excepción okhttp anotada en este ticket.

Para evitar este error, necesitaba agregar una personalización más a mi okHttpClient. Esto solucionó el error para mí.

okHttpClient.setHostnameVerifier(new HostnameVerifier() {
            @Override
            public boolean verify(String hostname, SSLSession session) {
                return true;
            }
        });

Finalmente conseguí que esto funcionara con una combinación de múltiples respuestas.

Primero, los certificados se hicieron incorrectamente, no estoy seguro de cómo. Pero al crearlos usando el script en esta respuesta, los hizo funcionar. Lo que se necesitaba era un certificado de servidor y una clave. Entonces el cliente necesitaba otro certificado.

Para usar el certificado en Android, convertí el archivo .pem en un archivo .crt como este:

openssl x509 -outform der -in client.pem  -out client.crt

En Android, agregué el certificado a mi cliente OkHttp de la siguiente manera:

public ApiService() {
    mClient = new OkHttpClient();
    mClient.setConnectTimeout(TIMEOUT_SECONDS, TimeUnit.SECONDS);
    mClient.setReadTimeout(TIMEOUT_SECONDS, TimeUnit.SECONDS);
    mClient.setCache(getCache());
    mClient.setSslSocketFactory(getSSL());
}

protected SSLSocketFactory getSSL() {
    try {
        CertificateFactory cf = CertificateFactory.getInstance("X.509");
        InputStream cert = getAppContext().getResources().openRawResource(R.raw.client);
        Certificate ca = cf.generateCertificate(cert);
        cert.close();

        // creating a KeyStore containing our trusted CAs
        String keyStoreType = KeyStore.getDefaultType();
        KeyStore keyStore = KeyStore.getInstance(keyStoreType);
        keyStore.load(null, null);
        keyStore.setCertificateEntry("ca", ca);

        return new AdditionalKeyStore(keyStore);
    } catch(Exception e) {
        e.printStackTrace();
    }
    return null;
}

La última parte con new AdditionalKeyStore() está tomado de esta respuesta muy bien escrita. Lo que agrega un almacén de claves alternativo.

¡Espero que esto pueda ayudar a alguien más! Esta es la forma más sencilla de hacer que HTTPS funcione con un certificado autofirmado que he encontrado. Otras formas incluyen tener un almacén de claves BouncyCastle que me parece excesivo.

Este problema se resuelve configurando setHostNameVerifier para okHttpBuilder. Asegúrese de que el método de verificación devuelva verdadero.

Muestra:

okHttpClient.setHostnameVerifier(new HostnameVerifier() {
    @Override
    public boolean verify(String hostname, SSLSession session) {
        return true;
    }
});

OkHttpClient.Builder builder = new OkHttpClient.Builder();
    builder.hostnameVerifier(new HostnameVerifier() {
        @Override
        public boolean verify(String hostname, SSLSession session) {
            return true;
        }
    });
OkHttpClient client = builder.build();

Verifique si el nombre CN en el certificado del cliente se agrega al nombre alternativo del Sujeto. yo tuve el mismo problema

Durante la generación del certificado, el subjectAltName debe establecerse si el uri es una ip para no fallar en la validación.

“En algunos casos, el URI se especifica como una dirección IP en lugar de un nombre de host. En este caso, el IPAddress subjectAltName debe estar presente en el certificado y debe coincidir exactamente con la IP en el URI”. RFC (mencionado por Bas en el comentario)

En lugar de jugar con el lado del cliente HostnameVerifier o bien, reiusse el certificado autofirmado (sobre el cual tenemos control) a través de:

openssl req \
-newkey rsa:2048 \
-nodes \
-x509 \
-days 36500 -nodes \
-addext "subjectAltName = IP.1:1.2.3.4" \
-keyout /etc/ssl/private/nginx-selfsigned2.key \
-out /etc/ssl/certs/nginx-selfsigned2.crt

Complemento, si en Android uno también necesita confiar en el certificado:

the crt is pem format and can be imported into android via
<?xml version="1.0" encoding="utf-8"?>
    <base-config cleartextTrafficPermitted="false">
        <trust-anchors>
            <certificates src="@raw/nginx_selfsigned2" />
            <certificates src="system" />
        </trust-anchors>
    </base-config>
</network-security-config>

Por lo tanto, verificamos que el certificado proviene de una fuente confiable y, previamente, mediante la verificación del nombre de host (a través de SAN), nos aseguramos de que el servidor con el que hablamos presente el certificado correcto para su IP.

más aquí: https://developer.android.com/training/articles/security-config
https://developer.android.com/training/articles/security-ssl.html#SelfSigned

si eres usado network_security_config en res/xml para resolver Cleartext HTTP traffic not permitted y cambiaste de dominio/dirección IP recuerda que debes cambiar includeSubdomains valor a la nueva dirección. Esto funcionó para mí.

  <network-security-config>
    <domain-config cleartextTrafficPermitted="true">
      <domain includeSubdomains="true">yourDomain.com</domain>
    </domain-config>
  </network-security-config>