NET::ERR_CERT_COMMON_NAME_INVALID 與雲前端

Question

我有一個 S3 托管的 static 網站和一個 Cloud Front 發行版。 Route 53 中有一條指向 Cloud Front 分布的 A 記錄。 當我創建發行版時，我接受了證書的默認設置。 也就是說，我沒有輸入證書 ID 或請求證書。 當我嘗試使用 Chrome 瀏覽該站點時，我得到 .NET::ERR_CERT_COMMON_NAME_INVALID。

如何查看或修改默認證書的通用名稱？ 它不會出現在證書管理器中。

Answer 1

這不是編程或開發，可能需要刪除，但是：

1. 按要求回答：

   對於 curl 的大多數版本（但不是 Microsoft 在 Windows 上提供的 curl.exe，它使用 schannel） curl -v https://host將顯示（服務器/葉）證書的主題和一些其他屬性； CN= 部分是 CommonName。 幾乎所有 Linux 和大多數其他 Unix 都會預裝合適的 curl； 在 Windows 上，您可以找到並安裝 Windows 的非 schannel 版本（這可能不像我年輕時那么容易），或者使用 WSL（它為您提供 Linux 版本）。

   如果你有 OpenSSL， echo Q | openssl s_client -connect host:443 echo Q | openssl s_client -connect host:443 （對於低於 1.1.1 的版本，您可能需要添加-servername host ）將顯示鏈中所有證書的主題和頒發者名稱（已驗證，可能與 CA 中發送的不同） ) 但不是葉子）； 您需要“0 s:”行，或者Server certificate / subject=向下一兩頁。 同樣，幾乎所有的 Linux 和 Unix 都有 OpenSSL； 對於 Windows，您可以從http://www.slproweb.com/products/Win32OpenSSL.html獲取端口或再次使用 WSL。 （而不是echo Q |您可以在 Unix 上使用</dev/null或在 Windows 上使用<NUL 。）

   如果你有 Java， keytool -printcert -sslserver host顯示很多關於證書鏈的信息； 第一行Certificate #0 / ===== / Owner:是你想要的。 15 或 20 年前，當 Java 被認為是未來的潮流時，它幾乎無處不在； 今天不是那么多。 我不會為此安裝 Java，但如果您出於任何更好的原因想要它，請安裝 go。

2. 但你不想。

   Chrome 中的錯誤代碼非常具有誤導性。 幾十年前，在 Subject 中使用（並驗證）CommonName 作為服務器主機名是標准的或至少是通常的約定。 大約從 2010 年開始，所有公共 CA 以及大多數其他 CA 都轉而使用SubjectAlternativeName aka SAN擴展。 最初，如果 SAN 不存在，瀏覽器會繼續接受 CommonName，但自 2017 年左右起，Chrome只使用 SAN，再也不會查看 CommonName。 因此，該錯誤代碼現在實際上意味着SAN不匹配或丟失； CommonName 很可能是正確的，即使修復錯誤也不會修復 Chrome 錯誤。

3. 那么如何修復 CloudFront 中的 SAN？ 我幫不上忙。

Answer 2

Cloud Front 中有一個設置，您可以在其中放入 SAN - 它稱為“備用域名”。

我不得不檢查證書，看看它沒有 mydomain.com 作為備用名稱——它只有雲前端分發的域名。