*.test 域的本地 HTTPS 证书问题

Question

我在与通配符证书斗争中度过了美好的一天......

现在，无法使用 .dev 进行本地开发，所以我们使用 *.test。我需要测试 HTTPS，所以我创建了通配符证书。

自 Chrome v58 起，“commonName”被忽略，用户应使用 SAN 来指定域名（更多关于此主题的信息：https://www.thesslstore.com/blog/security-changes-in-chrome-58/）。

无论如何：在我的系统（mac os / Docker / Chrome）上，通配符有问题 - 如果我在证书中指定整个域，它可以工作（比如 something.test） - 但是当我使用通配符时，Chrome 仍然会产生这个错误消息：NET::ERR_CERT_COMMON_NAME_INVALID

我几乎尝试了所有可能的方法，但没有运气:(

更多信息：

• http://grokify.github.io/security/wildcard-subject-alternative-name-ssl-tls-certificates/
• https://www.openssl.org/docs/man1.0.2/apps/x509v3_config.html#Subject-Alternative-Name
• https://medium.com/carwow-product-engineering/chrome-58-and-self-signed-ssl-certificate-c28a874d80fa
• https://github.com/webpack/webpack-dev-server/issues/854

我的 bash 脚本：

openssl req \
-x509 \
-nodes \
-new \
-newkey rsa:2048 \
-keyout test.key \
-out test.crt \
-sha256 \
-days 3650 \
-config <(cat <<EOF

[ req ]
prompt = no
distinguished_name = subject
x509_extensions    = x509_ext

[ subject ]
commonName = *.test

[ x509_ext ]
subjectAltName = @alternate_names

[ alternate_names ]
DNS.1 = *.test
DNS.2 = test

EOF
)

Answer 1

[ alternate_names ]
DNS.1 = *.test
DNS.2 = test

您可以将 *.test 用于个人用途。另见RFC 6761, Special-Use Domain Names。 RFC 6761 非常明确，用户软件应该不对待 *.test 不同于任何其他域名，所以不要指望浏览器或其他用户代理做一些特别的事情对于*.test。问题出在其他地方。

粗略地说，有两个组织发布了运行公共 PKI 的标准。首先是CA/Browser Forums，发布策略之后是Browsers。第二个是 IETF，它的发布策略被 cURL、OpenSSL 和 Wget 等其他用户代理遵循。

从浏览器的角度来看，*.test 似乎是 Brand Top Level Domains（即，像 *.google 这样的虚荣域）。 CA/B Baseline Requirements 不允许顶级通配符。

相比之下，IETF 不禁止通配顶级域，如 *.com、*.net 或 *.test。 cURL 和 Wget 等用户代理可能会允许使用通配符*.test。

这是来自 CA/B Baseline Requirements document。自 2013 年起生效：

授权域名：

用于获得证书颁发授权的域名 对于给定的 FQDN。 CA 可以使用从 DNS CNAME 返回的 FQDN 查找为 FQDN 以进行域验证。如果 FQDN 包含通配符，则 CA 必须删除所有通配符 请求的 FQDN 最左侧的标签。 CA 可能会修剪 从左到右零个或多个标签，直到遇到 Base 域名，并且可以使用任何一个中间值作为 域验证的目的。

---

如果我在证书中指定整个域，它可以工作（如something.test）

如果您希望浏览器使用证书，则必须使用something.test 或*.something.test。

或者，使用不同的用户代理，例如 cURL 或 Wget。

---

但当我使用通配符时，Chrome 仍会生成此错误消息：NET::ERR_CERT_COMMON_NAME_INVALID

和

[ subject ]
commonName = *.test

名称无效，因为您对顶级域进行了通配符，并且用户代理遵循 CA/B 颁发策略。

此外，将主机名放在 CommonName 中已被弃用多年。在过去的几年里，它并没有被禁止。我了解 CA/B 基线要求将很快禁止它。 IETF stll 允许它。这是来自 CA/B Baseline Requirements document:

证书字段：主题：commonName (OID 2.5.4.3)
必需/可选：已弃用（不鼓励，但不禁止）
内容：如果存在，此字段必须包含单个 IP 地址或作为值之一的完全限定域名 包含在证书的 subjectAltName 扩展中（请参阅 第 7.1.4.2.1 节）。

简而言之，不要将主机名放在 CommonName 中。在此处输入一个友好的名称，例如 Example Widgets, LLC。将主机名和其他名称放入 SubjectAltName。

我知道证书完全省略了 CommonName。例如，参见Crypto++ website。 Crypto++ 网站试图将通用名称设置为 "Crypto++"，因为它是一个友好的名称，但发行者担心 "+" 符号有时会破坏脚本.所以这个字段被完全省略了。

---

现在，无法使用 .dev 进行本地开发...

这在某种程度上很有趣。我很想知道为什么这是不可能的，因为它似乎是开发网络段的一个不错的选择。

为了完整起见，我的家庭网络是 *.pvt。我有一个在需要时颁发证书的 CA。我从来没有遇到过任何麻烦。

---

无论如何：在我的系统（mac os / Docker / Chrome）上，通配符有问题

有趣的是，Docker 遇到了麻烦。我希望 Docker 遵循 IETF 发布政策并允许它。我不知道他们遵循 CA/B 发布政策并拒绝了它。

Docker 可能正在运行强化安装并拒绝它。 Tim Rühsen 有一个提供libpsl 的 GitHub。我相信 libpsl 会拒绝顶级域上的通配符。