☰

Проблемы с подключением браузера Chrome на Mac к Apache 2.4 на Centos по безопасному протоколу SSL/TLS

tag-icon • tag-icon google-chrome security apache-http-server ssl certificate
Проблемы с подключением браузера Chrome на Mac к Apache 2.4 на Centos по безопасному протоколу SSL/TLS

Мы управляем несколькими сайтами, которые используют веб-приложение Leaf. Наша конфигурация работает на Centos 7.9 с .NET Web API и Apache 2.4.

Система используется только сотрудниками, имеющими доступ к нашей Интранет. Она использует самоподписанный институциональный корневой сертификат, промежуточный сертификат и сертификат сервера, подписанный (выданный) промежуточным сертификатом. opensslпоказывает цепочку:

$ 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

Я запутал название нашего учреждения, но все остальное оставил без изменений.

Chrome запущен на Mac и настроен на использование корневого сертификата в приложении Keychain Access на Mac. Это обеспечивает безопасные, приватные соединения для производственного развертывания Leaf.

Я настраиваю клон виртуальной машины производственной системы. Мы создали новый закрытый ключ и сертификат сервера, подписанный промежуточным сертификатом. httpd.confбыл изменен для нового доменного имени. Сертификат сервера, закрытый ключ и промежуточный сертификат были сохранены на сервере, и эти атрибуты httpd теперь указывают на них:

  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"

Доменное имя сервера, кажется, проверяется. Обфусцированное, это omop-leaf-temp.hpc.our_domain. Это имя используется для 1) URL-адреса https-запроса, 2) сообщения об ошибке, сообщаемого Chrome, и 3) CNв SSLCertificateFile. Это подтверждается

$ 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

Однако экземпляр Chrome, который получает защищенные соединения с производственной системой, не может сделать этого в клоне виртуальной машины: Chrome не может установить безопасное соединение с сервером в клоне виртуальной машины

"PEM-кодированная цепочка" идентифицирует 3 сертификата. По порядку, это SSLCertificateFile, SSLCertificateChainFile, и наш самоподписанный корневой сертификат, который Chrome получает через Keychain Access (я полагаю). Мне это кажется нормальным.

httpdне сообщает об ошибках в журналах (включая error_log, leaf_access_log, и ), когда Chrome пытается установить leaf_ssl_error_logсоединение .LogLevelwarn

Я в недоумении. Почему Chrome сообщает об этом Your connection is not privateи NET::ERR_CERT_COMMON_NAME_INVALIDкогда CN правильный и цепочка сертификатов хорошая? Что я могу сделать для дальнейшего исследования и устранения этой проблемы?

Спасибо

решение1

Общее название выглядит неправильно:

./omop-leaf-temp_xxxx.cer| grep CN= | grep omop Тема: C=US, ST=xxx, L=xxx, O=Наша система, OU=xxx, CN= "

но "-hpc.our_domain/emailAddress=leaf-support@x" довольно сильно отличается от "omop-leaf-temp.hpc.our_domain"

решение2

Сертификат сервера должен иметь расширение SubjectAlternativeName (SAN), содержащее имя сервера, как указал @dave_thompson_085.

Это позволяет Chrome (версия 102.0.5005.115) и Safari (версия 15.0) устанавливать безопасные соединения с сервером.

Сертификат был создан с использованием

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

с этим файлом конфигурации

[ 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

Я настоятельно призываю разработчиков кода, который оценивает, установил ли клиент безопасное соединение, предоставить четкую ошибку, указывающую на то, что сертификат должен иметь SAN, а не неверную ошибку ERR_CERT_COMMON_NAME_INVALID.

Связанный контент