关于ssl：为域和子域创建自签名证书 – NET :: ERR_CERT_COMMON_NAME_INVALID

Creating self signed certificate for domain and subdomains - NET::ERR_CERT_COMMON_NAME_INVALID

我按照本教程在Windows上创建签名SSL证书用于开发目的，并且它适用于我的一个域(我使用hosts文件来模拟dns)。然后我发现我有很多子域名，为每个子域名创建证书会很麻烦。所以我尝试在Common字段中使用通配符创建证书，如serverfault的一些答案中所建议的那样。像这样：

1	Common Name: *.myserver.net/CN=myserver.net

但是，在将此证书导入受信任的根证书颁发机构后，Chrome在主域及其所有子域中出现NET::ERR_CERT_COMMON_NAME_INVALID错误，例如：https://sub1.myserver.net和https://myserver.net。

This server could not prove that it is myserver.net; its security certificate
is from *.myserver.net/CN=myserver.net.

This may be caused by a misconfiguration or an attacker intercepting your connection.

Common Name字段中是否有错误导致此错误？

相关讨论

Chrome 58已经放弃了对没有主题备用名称的证书的支持。

继续前进，这可能是您遇到此错误的另一个原因。

相关讨论

解决方法是将您使用的域名添加为"subjectAltName"(X509v3使用者替代名称)。这可以通过更改OpenSSL配置(Linux上的/etc/ssl/openssl.cnf)并将v3_req部分修改为如下所示来完成：

1
2
3
4
5
6
7
8
9
10
11

[ v3_req ]

# Extensions to add to a certificate request

basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
subjectAltName = @alt_names

[alt_names]
DNS.1 = myserver.net
DNS.2 = sub1.myserver.net

有了这个，在生成新证书时不要忘记使用-extensions v3_req开关。 (另请参阅如何使用OpenSSL生成带有SubjectAltName的自签名证书？)

相关讨论

subjectAltName = @alt_names的使用完全解决了我的问题。我以前通过提供CN=*.example.com将DNS身份绑定到我的域名。设置DNS.1 = example.com和DNS.2 = *.example.com就可以了。奇怪的是(对我而言)它一直工作到2017-03-17并且在一天之后停止了(已经运行了一大批Windows udates)。但是在Linux上没有什么可以破坏我，这只是Chrome上的Chrome，Windows。
@bossi：不幸的是我在Chrome / Ubuntu上遇到了这个问题。并且cert不是什么花哨的，单主机，单DN(内部GitLab存储库)。
它工作了一个星期左右，服务器上没有任何变化。其他2台服务器由于大小写不匹配而开始咆哮(cert为大写，Chrome将地址降为小写)
@bossi我打赌你的Windows版本正处于测试阶段，对吗？自Chrome 58以来，Chrome已弃用了不含subjectAltName的证书，目前处于测试阶段。这让我很难，因为我不仅没有看到任何关于它的东西，而且错误名称非常具有误导性(这不是普通的名字，这是无效的！)我是你的反面;它只发生在Linux上，所以我花了几个小时试图修复我当地的证书商店。
@PawelKraszewski听起来你也有同样的问题;你是Chrome 58 beta吗？见上面的说明;现在删除了commonName上的匹配。
@TobyJ 58.0.3029.19 beta (64-bit)它是。我用正确的subjectAltName -s重新生成了证书树，现在一切正常。我同意，错误消息是非常误导的，因为它不是commonName无效。如果消息显示"证书缺少正确的subjectAltName"，那么每个人都会更开心。
@PawelKraszewski这里是开源的力量，我想，我发现Chromium问题，他们讨论过这个，并抱怨错误信息不清楚，所以他们同意让它变得更好(我想这实际上有点困难)从他们检测到错误的位置更改该消息)：bugs.chromium.org/p/chromium/issues/detail?id=308330
@PawelKraszewski除非上下文明确规定了上限，否则我总是选择小写或更低版本的camelCase用于任何配置相关。使用`alt_names不适合你？控制台是否说出更具体的内容？
@TobyJ是的，你是我的亮点，我在Chrome / beta(当前为58.0.3029.19)，Firefox /稳定(52.0.1)在我的Win上。 FF似乎也放弃了对CN领域域名的支持。我猜这个错误信息从历史的角度来看是有意义的，如果一般的改变确实只是从CN字段中的域标识符到subjectAltName，但这种方式现在让人感到困惑。如果它真的是最近的转变，我相信它会得到解决。
@bossi：因为混合大小写的问题是在一个非常敏感的服务器上，我是唯一一个通过浏览器窥视它(这主要是一个无头设备的REST服务器)，我宁可不碰任何东西 - 意识到这个消息关于不匹配是一个合法的，并且证书使用私人CA无论如何。
@PawelKraszewski现在(第59页)当您在错误页面上点击"高级"时，您可以阅读有关它的更多信息，并且有：不正确的subjectAltName。

正如Rahul所说，这是一个常见的Chrome和OSX错误。我过去遇到过类似的问题。事实上，我最终厌倦了在测试本地网站工作时使2 [是的我知道并不多]额外点击。

至于这个问题的可能解决方法[使用Windows]，我会使用许多自签名证书实用程序之一。

推荐步骤：

创建自签名证书

将证书导入Windows证书管理器

在Chrome证书管理器中导入证书
注意：第3步将解决Google解决该问题后遇到的问题...考虑到在可预见的将来没有ETA的时间已经过时。**
< br />尽管我更喜欢使用Chrome进行开发，但最近我发现自己处于Firefox Developer Edition中。哪个没有这个问题。

希望这有帮助:)

相关讨论

创建openssl.conf文件：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

[req]
default_bits = 2048
default_keyfile = oats.key
encrypt_key = no
utf8 = yes
distinguished_name = req_distinguished_name
x509_extensions = v3_req
prompt = no

[req_distinguished_name]
C = US
ST = Cary
L = Cary
O = BigCompany
CN = *.myserver.net

[v3_req]
keyUsage = critical, digitalSignature, keyAgreement
extendedKeyUsage = serverAuth
subjectAltName = @alt_names

[alt_names]
DNS.1 = myserver.net
DNS.2 = *.myserver.net

运行此命令：

1	openssl req -x509 -sha256 -nodes -days 3650 -newkey rsa:2048 -keyout app.key -out app.crt -config openssl.conf

输出文件app.crt和app.key适合我。

相关讨论

您的通配符*.example.com不包含根域example.com，但会涵盖子域中的任何变体，例如www.example.com或test.example.com

首选方法是在Fabian的答案中建立主题备用名称，但请记住，Chrome目前要求将公共名称另外列为主题备用名称之一(正如他在答案中正确演示的那样)。我最近发现了这个问题，因为我有SANs www.example.com和test.example.com的公共名称example.com，但是从Chrome获得了NET::ERR_CERT_COMMON_NAME_INVALID警告。我必须使用example.com生成一个新的证书签名请求作为公共名称和一个SAN。然后Chrome完全信任该证书。不要忘记将根证书导入Chrome，作为识别网站的可信任机构。

相关讨论

我认为这可能是chrome中的一个bug。长期存在类似的问题：
看到这个。

尝试使用其他浏览器。我认为它应该工作正常。

对于遇到此问题且希望接受测试风险的每个人，都有一个解决方案：转到Chrome中的隐身模式，您就可以打开"高级"，然后点击"继续进入some.url"。

如果您需要检查自己维护的某个网站并且只是作为开发人员进行测试(以及当您尚未配置适当的开发证书时)，这将非常有用。

当然，这不是为了使用生产网站的人，这个错误表明网站安全存在问题。

如果你厌倦了这个错误。你可以让Chrome不这样做。我不是说这是最好的方式，只是说它是一种方式。

As a workaround, a Windows registry key can be created to allow Google Chrome to use the commonName of a server certificate to match a hostname if the certificate is missing a subjectAlternativeName extension, as long as it successfully validates and chains to a locally-installed CA certificates.

Data type: Boolean [Windows:REG_DWORD]
Windows registry location: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome
Windows/Mac/Linux/Android preference name: EnableCommonNameFallbackForLocalAnchors
Value: 0x00000001 (Windows), true(Linux), true (Android), (Mac)
To create a Windows registry key, simply follow these steps:

Open Notepad
Copy and paste the following content into notepad
Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome]
"EnableCommonNameFallbackForLocalAnchors"=dword:00000001
Go to File > Save as
Filename: any_filename.reg
Save as type: All Files

Select a preferred location for the file

Click on Save

Double click on the saved file to run

Click on Yes on the Registry Editor warning

在Symantec支持页面上找到此信息：
https://support.symantec.com/en_US/article.TECH240507.html