google-chrome - *.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 做一些特别的事情。问题出在别处。

粗略地说，有两个组织发布了运行公共(public) 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 年起生效:

Authorization Domain Name:

The Domain Name used to obtain authorization for certificate issuancefor a given FQDN. The CA may use the FQDN returned from a DNS CNAMElookup as the FQDN for the purposes of domain validation. If the FQDNcontains a wildcard character, then the CA MUST remove all wildcardlabels from the left most portion of requested FQDN. The CA may prunezero or more labels from left to right until encountering a BaseDomain Name and may use any one of the intermediate values for thepurpose of domain validation.

---

if I specify whole domain in certificate, it works (like something.test)

如果您想让浏览器使用证书，那么您必须使用something.test 或*.something.test。

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

---

but when i use wildcard, Chrome still generate this error message: NET::ERR_CERT_COMMON_NAME_INVALID

和

[ subject ]
commonName = *.test

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

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

Certificate Field: subject:commonName (OID 2.5.4.3)
Required/Optional: Deprecated (Discouraged, but not prohibited)
Contents: If present, this field MUST contain a single IP address or Fully-Qualified Domain Name that is one of the valuescontained in the Certificate’s subjectAltName extension (seeSection7.1.4.2.1).

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

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

---

Nowdays, it's not possible to use .dev for local development...

这在某种病态方面很有趣。我很想知道为什么它不可能，因为它似乎是开发网段的不错选择。

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

---

Anyway: on my system (mac os / Docker / Chrome) there is trouble with wildcard

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

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