![Mac 上的 Chrome 瀏覽器無法透過 SSL/TLS 安全連線到 Centos 上的 Apache 2.4](https://rvso.com/image/1672340/Mac%20%E4%B8%8A%E7%9A%84%20Chrome%20%E7%80%8F%E8%A6%BD%E5%99%A8%E7%84%A1%E6%B3%95%E9%80%8F%E9%81%8E%20SSL%2FTLS%20%E5%AE%89%E5%85%A8%E9%80%A3%E7%B7%9A%E5%88%B0%20Centos%20%E4%B8%8A%E7%9A%84%20Apache%202.4.png)
我們經營多個運行 Leaf Web 應用程式的網站。我們的配置在 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 上運行,並配置為使用 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) https 請求的 URL,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 執行個體無法在虛擬機器複製中執行此操作:
「PEM 編碼鏈」標識 3 個憑證。按順序,它們是SSLCertificateFile
、SSLCertificateChainFile
和 Chrome 透過 Keychain Access 取得的自簽名根憑證(我猜是這樣)。這對我來說似乎很好。
httpd
當 Chrome 嘗試連線時,不會在日誌中報告錯誤(包括error_log
、leaf_access_log
和)。是。leaf_ssl_error_log
LogLevel
warn
我很困惑。為什麼 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
。