Trouble getting the Chrome browser on a Mac to connect securely over SSL/TLS to Apache 2.4 on Centos

Question

We operate multiple sites that run the Leaf webapp. Our configuration runs on Centos 7.9, with a .NET Web API and Apache 2.4.

The system is used only by staff who access our Intranet. It uses a self-signed institutional root certificate, an intermediate certificate, and a server certificate signed (issued) by the intermediate certificate. openssl shows the chain:

$ 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

I have obfuscated the name of our institution, but left everything else the same.

Chrome is running on a Mac and configured to use the root certificate in the Mac's Keychain Access app. This obtains secure, private connections for a production deployment of Leaf.

I'm configuring a VM clone of the production system. We've created a new private key and a server certificate signed by the intermediate certificate. httpd.conf has been modified for the new domain name. The server certificate, private key, and intermediate certificate have been stored on the server and these httpd attributes now point to them:

  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"

The server's domain name appears to check out. Obfuscated, it is omop-leaf-temp.hpc.our_domain. This name is used for 1) the URL of the https request, 2) the error message reported by Chrome, and 3) the CN in the SSLCertificateFile. This is confirmed by

$ 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

But the Chrome instance that obtains secure connections to the production system fails to do so in the VM clone:

The "PEM encoded chain" identifies 3 certs. In order, they are SSLCertificateFile, SSLCertificateChainFile, and our self-signed root certificate that Chrome obtains through Keychain Access (I presume). This seems fine to me.

httpd does not report errors in the logs (including error_log, leaf_access_log, and leaf_ssl_error_log) when Chrome attempts a connection. LogLevel is warn.

I am perplexed. Why does Chrome report Your connection is not private and NET::ERR_CERT_COMMON_NAME_INVALID when the CN is right and the certificate chain is good? What can I do to further investigate and fix this problem?

Thanks

Answer 1

The Common Name looks wrong:

./omop-leaf-temp_xxxx.cer| grep CN= | grep omop Subject: C=US, ST=xxx, L=xxx, O=Our System, OU=xxx, CN= "

but "-hpc.our_domain/emailAddress=leaf-support@x" is rather different than "omop-leaf-temp.hpc.our_domain"

Answer 2

The server's cert needs to have a SubjectAlternativeName (SAN) extension that contains the server's name, as pointed out by @dave_thompson_085.

This enables both Chrome (Version 102.0.5005.115) and Safari (Version 15.0) to establish secure connections with the server.

The cert was created using

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

with this config file

[ 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

I urge the developers of the code that evaluates whether a client has established a secure connection to provide a clear error indicating that the cert needs to have a SAN rather than the incorrect error ERR_CERT_COMMON_NAME_INVALID.