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 作为备用名称——它只有云前端分发的域名。