Error de certificado del navegador - disc discrepancia, pero solo bajo ciertas condiciones

3

Ok, tengan paciencia conmigo, esto es un poco por ahí, y espero que este sea el lugar correcto para publicar: tengo un cliente que trabaja para una gran empresa y hemos creado una aplicación de heroku para ellos. Puede acceder a la aplicación heroku desde su casa, pero cuando se conecta a la red de su oficina desde la misma computadora portátil, recibe este mensaje de error en la última versión de Chrome cuando visita el sitio: "Este servidor no pudo probar que es foo.bar .com; su certificado de seguridad es de * .herokuapp.com "Le hemos preguntado a Heroku y sienten que el certificado está en orden. El usuario tiene la misma versión exacta de Chrome que estoy usando. No puedo duplicar el error porque no estoy autorizado para conectar la misma red WiFi empresarial a la que se conecta. Sin embargo, puedo conectarme a la red WiFi de ese edificio, pero me imagino que no es una prueba válida, ya que esa red está completamente abierta y es probable que se haya separado de la red de empleados.

¿Alguien tiene alguna teoría sobre cómo una red empresarial podría interferir con la capacidad de un navegador para interpretar un certificado? Cualquier otra idea, por ejemplo. Tal vez hay una herramienta que podemos instalar para diagnosticar? Estamos tratando de encontrar personal de TI interno bien calificado que pueda ayudar, pero esto es difícil de hacer en una gran empresa.

He agregado esta información de diagnóstico que puede ayudar a confirmar lo que está sucediendo aquí.

Cuando ejecuto openssl en las redes "buenas" y en las redes "malas", obtengo un certificado diferente para el certificado "0" (primero) en la cadena, es como si hubiera dos certificados o si de alguna manera malinterpretado los certificados, pero no estamos seguros de cómo se han configurado mal, y por qué funcionaría si ese fuera el caso. ¿Por qué el cliente vería una cadena de certificados diferente solo porque están en una red diferente?

Algunas personas han dicho que esto se debe a un proxy de reescritura de certificados en la red corporativa, pero el cliente me ha dicho que no reescribe el certificado.

La salida de mi comando de diagnóstico:

openssl s_client -showcerts -servername foo.bar.com -connect foo.bar.com:443

Aquí está la salida en la red 'mala' (he redactado datos específicos):

> CONNECTED(00000003) depth=1 /C=US/O=DigiCert
> Inc/OU=www.digicert.com/CN=DigiCert SHA2 High Assurance Server CA
> verify error:num=20:unable to get local issuer certificate verify
> return:0
> --- Certificate chain  0 s:/C=US/ST=California/L=San Francisco/O=Heroku, Inc./CN=*.herokuapp.com    i:/C=US/O=DigiCert
> Inc/OU=www.digicert.com/CN=DigiCert SHA2 High Assurance Server CA
> -----BEGIN CERTIFICATE----- xxxx
> -----END CERTIFICATE-----  1 s:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2 High Assurance Server CA 
>   i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High
> Assurance EV Root CA
> -----BEGIN CERTIFICATE----- xxxx
> -----END CERTIFICATE-----
> --- Server certificate subject=/C=US/ST=California/L=San Francisco/O=Heroku, Inc./CN=*.herokuapp.com issuer=/C=US/O=DigiCert
> Inc/OU=www.digicert.com/CN=DigiCert SHA2 High Assurance Server CA
> --- No client certificate CA names sent
> --- SSL handshake has read 2745 bytes and written 458 bytes
> --- New, TLSv1/SSLv3, Cipher is AES128-SHA Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion:
> NONE SSL-Session:
>     Protocol  : TLSv1
>     Cipher    : AES128-SHA
>     Session-ID: xxx
>     Session-ID-ctx: 
>     Master-Key: xxx
>     Key-Arg   : None
>     Start Time: 1490624709
>     Timeout   : 300 (sec)
>     Verify return code: 0 (ok)
> --- DONE

Aquí está la salida en la red 'buena':

> CONNECTED(00000003) depth=1 /C=US/O=Symantec Corporation/OU=Symantec
> Trust Network/CN=Symantec Class 3 Secure Server CA - G4 verify
> error:num=20:unable to get local issuer certificate verify return:0
> --- Certificate chain  0 s:/C=US/ST=Maryland/L=xxx/O=xxx/OU=Headquarters/CN=foo.bar.com 
>   i:/C=US/O=Symantec Corporation/OU=Symantec Trust Network/CN=Symantec
> Class 3 Secure Server CA - G4
> -----BEGIN CERTIFICATE----- xxx
> -----END CERTIFICATE-----  1 s:/C=US/O=Symantec Corporation/OU=Symantec Trust Network/CN=Symantec Class 3 Secure
> Server CA - G4    i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust
> Network/OU=(c) 2006 VeriSign, Inc. - For authorized use
> only/CN=VeriSign Class 3 Public Primary Certification Authority - G5
> -----BEGIN CERTIFICATE----- xxx
> -----END CERTIFICATE-----
> --- Server certificate subject=/C=US/ST=xxx/L=xxx/O=xxx./OU=Headquarters/CN=foo.bar.com
> issuer=/C=US/O=Symantec Corporation/OU=Symantec Trust
> Network/CN=Symantec Class 3 Secure Server CA - G4
> --- No client certificate CA names sent
> --- SSL handshake has read 3069 bytes and written 458 bytes
> --- New, TLSv1/SSLv3, Cipher is AES256-SHA Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion:
> NONE SSL-Session:
>     Protocol  : TLSv1
>     Cipher    : AES256-SHA
>     Session-ID: xxx
>     Session-ID-ctx: 
>     Master-Key: xxx
>     Key-Arg   : None
>     Start Time: 1490624583
>     Timeout   : 300 (sec)
>     Verify return code: 0 (ok)
> --- DONE
    
pregunta bethesdaboys 09.03.2017 - 18:50
fuente

1 respuesta

1

La compañía está ejecutando un proxy de intercepción de SSL, y el proxy está emitiendo su propio certificado en lugar del certificado oficial herokuapp.com.

Muchas empresas grandes tienen conexiones SSL terminadas en un proxy para que puedan inspeccionar el contenido y asegurarse de que están bien para entrar o salir de la red. Luego el proxy reemplaza el certificado con su propio certificado. Para que esto funcione, cualquier navegador o cliente SSL utilizado en la empresa debe confiar en el certificado que firma el proxy. Me parece que el cliente que está utilizando no tiene el CA de la empresa como una autoridad de certificación confiable.

La solución es agregar el CA de la compañía como una autoridad confiable para su cliente, y usted debe ser bueno. Se supone que Chrome en Windows confía en los certificados del almacén Trusted Root de su máquina, por lo que si la computadora está configurada correctamente para confiar en el proxy, Chrome debería funcionar. Firefox mantiene su propia lista de CA confiables, y el certificado CA de la compañía debe agregarse de alguna manera. Otras aplicaciones y herramientas, como Java, Gradle, Git, etc. También puede depender de un almacén de certificados interno privado y debería configurarse para confiar en su proxy como firmante.

Esta imagen muestra cómo se configura un proxy típico.

    
respondido por el MikeSchem 09.03.2017 - 18:53
fuente

Lea otras preguntas en las etiquetas