* .test域的本地HTTPS证书有问题 [英] Trouble with local HTTPS certificate for *.test domain

问题描述

我通过与通配符证书战斗来度过了美好的一天...

I spent this beautiful day by fighting with wildcard certificates...

如今，无法使用.dev进行本地开发，因此我们正在使用* .test.我需要测试HTTPS，因此创建了通配符证书.

Nowdays, it's not possible to use .dev for local development, so we're using *.test. I need to test HTTPS, so I created wildcard certificate.

自Chrome v58起，"commonName"被忽略，用户应使用SAN来指定域名(有关此主题的更多信息，请参见:

Since Chrome v58 the "commonName" is ignored and user should use SAN for specifying domain names (more on this topic here: https://www.thesslstore.com/blog/security-changes-in-chrome-58/).

无论如何:在我的系统(mac os/Docker/Chrome)上，通配符存在问题-如果我在证书中指定整个域，则可以正常工作(就像something.test一样)-但是当我使用通配符时，Chrome仍然会产生此错误讯息:NET :: ERR_CERT_COMMON_NAME_INVALID

Anyway: on my system (mac os / Docker / Chrome) there is trouble with wildcard - if I specify whole domain in certificate, it works (like something.test) - but when i use wildcard, Chrome still generate this error message: NET::ERR_CERT_COMMON_NAME_INVALID

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

I tried almost everything possible, but no luck :(

更多信息:

• 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

• 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
)

推荐答案

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

您可以将 *.test 用于个人用途.另请参见 RFC 6761专用域名. RFC 6761非常明确，用户软件应该不要对 *.test 的处理方式与任何其他域名都不同，因此不要指望浏览器或其他用户代理做一些特殊的事情表示 *.test .问题出在其他地方.

You are OK to use *.test for personal use. Also see RFC 6761, Special-Use Domain Names. RFC 6761 is very specific that user software should NOT treat *.test differently than any other domain name, so don't expect the browsers or other user agents to do something special for *.test. The problem lies elsewhere.

有两个组织在广泛地绘画，它们发布了运行公共PKI的标准.第一个是CA/浏览器论坛，发布策略之后是浏览器.第二个是IETF，其他用户代理(例如cURL，OpenSSL和Wget)遵循其发布策略.

Painting with a broad brush, there are two organizations that publish standards for running a public PKI. The first is the CA/Browser Forums, and the issuing polices are followed by Browsers. The second is the IETF, and its issuing policies are followed by other user agents like cURL, OpenSSL and Wget.

从浏览器的角度来看， *.test 似乎是品牌顶级域名(即，像 *.google 这样的虚荣域). CA/B 基准要求不允许使用顶级通配符.

From the browsers point of view, *.test appears to be a Brand Top Level Domains (i.e., Vanity Domain like *.google). The CA/B Baseline Requirements do not allow top level wild cards.

相反，IETF禁止通配顶级域名，例如 *.com ， *.net 或 *.test .诸如cURL和Wget之类的用户代理很可能允许通配符 *.test .

In contrast, the IETF does not forbid wildcarding the top level domain like *.com, *.net or *.test. User agents like cURL and Wget will likely allow wildcarding *.test.

这来自CA/B 基准要求文档.自2013年起生效:

This is from the CA/B Baseline Requirements document. It has been in effect since 2013:

授权域名 :

Authorization Domain Name:

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

The Domain Name used to obtain authorization for certificate issuance for a given FQDN. The CA may use the FQDN returned from a DNS CNAME lookup as the FQDN for the purposes of domain validation. If the FQDN contains a wildcard character, then the CA MUST remove all wildcard labels from the left most portion of requested FQDN. The CA may prune zero or more labels from left to right until encountering a Base Domain Name and may use any one of the intermediate values for the purpose of domain validation.

---

如果我在证书中指定整个域，则可以正常工作(例如something.test)

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

If you want a Browser to consume the certificate, then you must use something.test or *.something.test.

或者，使用其他用户代理，例如cURL或Wget.

Or, use a different user agent like cURL or Wget.

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

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

还有

[ subject ]
commonName = *.test

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

The name is invalid because you wildcarded the top level domain and the user agent follows the CA/B issuing policies.

此外，将主机名放置在 CommonName 中已经有多年了.在最近几年中，并没有被禁止.我了解CA/B基准要求很快将被禁止. IETF stll允许它.来自CA/B 基准要求文档:

In addition, putting a hostname in the CommonName has been deprecated for years. For the last several years it has not been forbidden. I understand the CA/B Baseline Requirements will be making it forbidden soon. The IETF stll allows it. This is from the CA/B Baseline Requirements document:

证书字段 :subject:commonName(OID 2.5.4.3)
必需/可选 :已弃用(已淘汰，但并非禁止使用)
内容 :如果存在，则此字段必须包含单个IP地址或标准域名，该值是以下值之一 包含在证书的subjectAltName扩展名中(请参阅 第7.1.4.2.1节).

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 values contained in the Certificate’s subjectAltName extension (see Section7.1.4.2.1).

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

The short of it is, don't put hostname in the CommonName. Put a friendly name there, like Example Widgets, LLC. Put hostnames and other names in the SubjectAltName.

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

I'm aware of certificates that omit the CommonName altogether. See, for example, Crypto++ website. The Crypto++ website tried to have the common name set to "Crypto++" because it is a friendly name, but the issuer feared the the "+" sign would break scripts on occasion. So the field was omitted altogether.

如今，无法使用.dev进行本地开发...

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

以一种病态的方式，这很有趣.我很想了解为什么无法实现这一点，因为对于开发人员网络网段来说，这似乎是一个不错的选择.

That's interesting in a morbid sort of way. I would be interested to learn why it is not possible since it seems like a good choice for dev network segments.

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

For completeness, my home network is *.pvt. I have a CA that issues certificates when needed. I have never had any troubles.

无论如何:在我的系统(mac os/Docker/Chrome)上，通配符有问题

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

有趣的是Docker遇到了麻烦.我希望Docker遵循IETF的发行政策并允许这样做.我不知道他们是否遵循CA/B的发布政策并拒绝了该政策.

It is kind of interesting Docker is having trouble with it. I expected Docker to follow the IETF issuing policies and allow it. I was not aware they were following CA/B issuing policies and rejecting it.

Docker可能正在使用强化安装运行并拒绝它. TimRühsen的GitHub提供了 libpsl .我相信libpsl会拒绝顶级域上的通配符.

Docker may be running with a hardened installation and rejecting it. Tim Rühsen has a GitHub that provides libpsl. I believe libpsl will reject a wildcard on the top level domain.

这篇关于* .test域的本地HTTPS证书有问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！