Chromium NET::ERR_CERT_COMMON_NAME_INVALID 是什麼意思？

我試圖弄清楚為什麼 Chromium 對 TLS 證書不滿意，以及如何解決它：

升級並重新啟動 Chromium（現在 58.0.3029.81，在 Debian 測試中執行）後，我無法再訪問我們的內部 GitLab 伺服器（通過綜合包安裝在 Debian Jessie 上）。我得到：

你的連接不是私人的

攻擊者可能試圖從 git.ourdomain.net 竊取您的資訊（例如，密碼、消息或信用卡）。NET::ERR_CERT_COMMON_NAME_INVALID

該證書使用我們的內部 CA 簽名，該 CA 安裝在系統儲存中（通過將其放入/usr/local/share/ca-certificates）。我用 Firefox 52 和openssl s_client -verify 5 -verify_return_error -connect git.ourdomain.net:443; 兩人都很開心。OpenSSL 將鏈顯示為：

Certificate chain
0 s:/C=US/ST=Virginia/L=Sterling/O=«us»/OU=Servers/CN=git.ourdomain.net
  i:/C=US/ST=Virginia/L=Sterling/O=«us»/CN=«us» Certification Authority/emailAddress=ca@ticket.ourdomain.net

OpenSSL 和 Firefox 都顯示強簽名 (SHA-512) 和密碼 (AES-GCM)。證書（根據openssl x509 -text）是 sha512WithRSAEncryption，具有 4096 位 RSA 密鑰。它有一個 Netscape 證書類型的 SSL 客戶端、SSL 伺服器。

注意：«us» 和 ourdomain.net 是編輯；實際輸出有我們的公司名稱«us»和我們的實際域為ourdomain.net。我仔細檢查了所有ourdomain.net 確實匹配。

據我所知，證書沒有任何問題，通用名稱 (git.ourdomain.net) 完全有效並且與 URL 匹配——那麼 Chromium 抱怨什麼？而且，假設這不是一個真正的問題，有沒有辦法覆蓋它？

從Chromium 錯誤 308330看來，他們認為在將主機名與證書公用名匹配時存在錯誤匹配的風險，因此已禁用該功能。Chromium 現在只會匹配 subjectAltName 副檔名。Firefox 進行了類似的更改，但僅限於公共 CA 頒發的較新證書，而不是內部證書。這就是 Firefox 仍然有效的原因。

可以通過設置策略來覆蓋 Chromium 更改，該策略EnableCommonNameFallbackForLocalAnchors可以使用以下/etc/chromium/policies/managed/use-common-names.json內容創建：

{
   "EnableCommonNameFallbackForLocalAnchors": true
}

似乎您必須在創建之後重新啟動 Chromium。

引用自：https://unix.stackexchange.com/questions/362469