☰

Problemas para lograr que el navegador Chrome en una Mac se conecte de forma segura a través de SSL/TLS a Apache 2.4 en Centos

tag-icon • tag-icon google-chrome security apache-http-server ssl certificate
Problemas para lograr que el navegador Chrome en una Mac se conecte de forma segura a través de SSL/TLS a Apache 2.4 en Centos

Operamos varios sitios que ejecutan la aplicación web Leaf. Nuestra configuración se ejecuta en Centos 7.9, con una API web .NET y Apache 2.4.

El sistema es utilizado únicamente por el personal que accede a nuestra Intranet. Utiliza un certificado raíz institucional autofirmado, un certificado intermedio y un certificado de servidor firmado (emitido) por el certificado intermedio. opensslmuestra la cadena:

$ openssl s_client -connect leaf.ourdomain:443 -showcerts -CAfile path_to_root_cert/RootCert.cer 2> /dev/null | egrep "Certificate chain| s:| i:"
Certificate chain
 0 s:/CN=leaf.ourdomain
   i:/DC=org/DC=our_dc/CN=Our system CA
 1 s:/DC=org/DC=our_dc/CN=Our system CA
   i:/CN=Our System

He ofuscado el nombre de nuestra institución, pero dejé todo lo demás igual.

Chrome se ejecuta en una Mac y está configurado para usar el certificado raíz en la aplicación Keychain Access de la Mac. Esto obtiene conexiones privadas y seguras para una implementación de producción de Leaf.

Estoy configurando un clon de VM del sistema de producción. Hemos creado una nueva clave privada y un certificado de servidor firmado por el certificado intermedio. httpd.confha sido modificado para el nuevo nombre de dominio. El certificado del servidor, la clave privada y el certificado intermedio se almacenaron en el servidor y estos atributos httpd ahora apuntan a ellos:

  SSLCertificateFile "/etc/pki/tls/certs/omop-leaf-temp_hpc_our_domain_ssl.cer"
  SSLCertificateKeyFile "/etc/pki/tls/private/omop-leaf-temp_hpc_our_domain_ssl.key"
  SSLCertificateChainFile "/etc/pki/tls/certs/Intermediate.cer"

El nombre de dominio del servidor parece estar verificado. Ofuscado, lo es omop-leaf-temp.hpc.our_domain. Este nombre se utiliza para 1) la URL de la solicitud https, 2) el mensaje de error informado por Chrome y 3) el CNarchivo SSLCertificateFile. Esto es confirmado por

$ openssl x509 -text -in ./omop-leaf-temp_xxxx.cer| grep CN= | grep omop
        Subject: C=US, ST=xxx, L=xxx, O=Our System, OU=xxx, CN=-hpc.our_domain/emailAddress=leaf-support@xxx

Pero la instancia de Chrome que obtiene conexiones seguras al sistema de producción no lo hace en el clon de VM: Chrome no logra establecer una conexión segura con el servidor en el clon de VM

La "cadena codificada PEM" identifica 3 certificados. En orden, son SSLCertificateFile, SSLCertificateChainFiley nuestro certificado raíz autofirmado que Chrome obtiene a través de Acceso a Llaveros (supongo). Esto me parece bien.

httpdno informa errores en los registros (incluidos error_log, leaf_access_logy leaf_ssl_error_log) cuando Chrome intenta conectarse. LogLeveles warn.

Estoy perplejo. ¿Por qué Chrome informa Your connection is not privatey NET::ERR_CERT_COMMON_NAME_INVALIDcuándo el CN ​​tiene razón y la cadena de certificados es buena? ¿Qué puedo hacer para investigar más a fondo y solucionar este problema?

Gracias

Respuesta1

El nombre común parece incorrecto:

./omop-leaf-temp_xxxx.cer| grepCN= | grep omop Asunto: C=US, ST=xxx, L=xxx, O=Nuestro sistema, OU=xxx, CN= "

pero "-hpc.our_domain/emailAddress=leaf-support@x" es bastante diferente a "omop-leaf-temp.hpc.our_domain"

Respuesta2

El certificado del servidor debe tener una extensión SubjectAlternativeName (SAN) que contenga el nombre del servidor, como lo señala @dave_thompson_085.

Esto permite que tanto Chrome (Versión 102.0.5005.115) como Safari (Versión 15.0) establezcan conexiones seguras con el servidor.

El certificado fue creado usando

openssl req \
-newkey rsa:4096 \
-nodes \
-keyout omop-leaf-temp_redacted.key \
-out omop-leaf-temp_redacted.csr \
-config csr_with_san.conf \
-days 730 \
-batch \
-verbose

con este archivo de configuración

[ req ]
default_bits              = 2048
default_md              = sha256
distinguished_name    = req_distinguished_name
req_extensions     = req_ext
prompt = no

[ req_distinguished_name ]
countryName                 = US
stateOrProvinceName       = New York
localityName                  = New York City
organizationName          = redacted
organizationalUnitName  = redacted
commonName                  = omop-leaf-temp.redacted
emailAddress                  = redacted

[ req_ext ]
subjectAltName          = @alt_names

[alt_names]
DNS.1                   = omop-leaf-temp.redacted

Insto a los desarrolladores del código que evalúa si un cliente ha establecido una conexión segura a que proporcionen un error claro que indique que el certificado necesita tener una SAN en lugar de un error incorrecto ERR_CERT_COMMON_NAME_INVALID.

información relacionada