我也遇到了同样的问题：我已将证书安装到Windows的Trusted Root Authorities存储中，但Chrome仍然拒绝证书，错误为ERR_CERT_COMMON_NAME_INVALID。请注意，当证书未正确安装在存储中时，错误为ERR_CERT_AUTHORITY_INVALID。

正如错误名称、此注释和此问题所暗示的，问题在于证书中声明的域名。当生成证书时提示输入“CommonName”时，我必须输入用于访问站点的域名（在我的情况下是localhost）。我使用重新启动了Chromechrome://restart它终于对这个新证书感到满意。

更新日期：2020年4月23日

铬团队推荐

https://www.chromium.org/Home/chromium-security/deprecating-powerful-features-on-insecure-origins#TOC-测试强大功能

快速超级简单解决方案

有一个秘密的绕过短语，可以在错误页面中输入，让Chrome不顾安全错误继续运行：这是不安全的（在早期版本的Chrome中，键入baddidea，甚至更早版本的危险）。除非你完全明白为什么需要它，否则不要使用它！

资料来源：

https://chromium.googlesource.com/chromium/src/+/d8fc089b62cd4f8d907acff6fb3f5ff58f168697%5E%21/

（注意，window.atob（'dGhpc2lzdW5zYWZl'）解析为此isnsafe）

源的最新版本为@https://chromium.googlesource.com/chromium/src/+/refs/heads/master/components/security_interentials/corebrowser/resources/intertial_large.js和window.atob函数可以在js控制台中执行。

有关Chrome团队为何更改旁路短语（第一次）的背景信息：

https://bugs.chromium.org/p/chromium/issues/detail?id=581189

如果所有其他方法都失败（解决方案1）

对于快速一次性，如果“无论如何继续”选项不可用，或者旁路短语也不起作用，这个黑客很好：

通过启用此标志，允许来自本地主机的证书错误（注意，更改标志值后，Chrome需要重新启动）：chrome://flags/#allow-不安全的本地主机（并投票赞成答案https://stackoverflow.com/a/31900210/430128作者@Chris）如果要连接的站点是localhost，那么就完成了。否则，设置TCP隧道以在本地侦听端口8090，并连接到端口443上的broken-remote-site.com，确保已安装socat并在终端窗口中运行以下内容：socat tcp侦听：8090，reuseddr，fork tcp：断开远程站点.com:443去https://localhost:8090在浏览器中。

如果所有其他方法都失败（解决方案#2）

类似于“如果所有其他都失败（解决方案#1）”，这里我们使用ngok为本地服务配置代理。因为您可以通过TLS访问ngrok http隧道（在这种情况下，它由ngrok使用有效证书终止），也可以通过非TLS端点访问，所以浏览器不会抱怨证书无效。

下载并安装ngrok，然后通过ngrok.io公开它：

ngrok http https://localhost

ngok将启动并为您提供一个可以连接到的主机名，所有请求都将通过隧道传输回本地计算机。

对于测试环境

在启动chrome时，可以使用--ignore证书错误作为命令行参数（在Ubuntu上使用28.0.1500.52版本）。

这将导致它忽略错误并在没有警告的情况下连接。如果您已经运行了一个版本的chrome，则需要在从命令行重新启动之前关闭它，否则它将打开一个新窗口，但忽略参数。

我将Intellij配置为在进行调试时以这种方式启动chrome，因为测试服务器从来没有有效的证书。

不过，我不建议像这样正常浏览，因为证书检查是一项重要的安全功能，但这可能对某些人有所帮助。

截至2020年3月，在使用Chrome81的MacOSCatalina上，一旦您使用openssl创建了一个有效的证书，上述情况就会发生变化。

首先，我使用Safari浏览了我的网站，并单击了警告页面底部的链接，该链接允许我无论如何访问该网站。这将证书添加到我的Mac Keychain（即Keychain.app）。Safari将允许我查看该页面。Chrome显示证书是可信的，但不允许我查看该页面。我继续收到CERTIFICATE_INVALID错误。

在Keychain中，选择左下角窗格中的“所有项目”。然后搜索本地主机DNS名称（即myhost.example.com）。

双击证书。它将打开证书的编辑对话框。

将“使用此证书时”更改为“始终信任”

这完全违反直觉，因为SSL已经设置为Always Trust，可能是Safari在添加证书时设置的。Chrome只有在我将其全局更改为“始终信任”后才开始工作。当我把它换回来时，它停止了工作。

在这里，我的WINDOWS解决方案可能适用于LINUX

Git有openssl

C： \Program Files\Git\usr\bin\openssl.exe。

导航到C:\Program Files\Git\user\bin\，但最好添加到PATH

为证书创建文件夹创建文件req.cnf像我的公司一样改变价值观不要删除subjectAltName=@alt_names[备选名称]DNS.1=本地主机Chrome抱怨

C=CA CA是两个字母国家代码CA=加拿大、美国。。。ST=ON是安大略省

请求cnf

[req]
distinguished_name = req_distinguished_name
x509_extensions = v3_req
prompt = no
[req_distinguished_name]
C = CA
ST = ON
L = Toronto
O = MyCompany
OU = MyDivision
CN = localhost
[v3_req]
keyUsage = critical, digitalSignature, keyAgreement
extendedKeyUsage = serverAuth
subjectAltName = @alt_names
[alt_names]
DNS.1 = localhost 
DNS.2 = www.mydomainname.com
DNS.3 = mydomainname.com

在CMD中创建证书

 openssl req -x509 -nodes -days 365 -newkey rsa:2048  -keyout server.key -out server.crt -config req.cnf -sha256

 cat server.crt server.key > server.pem

覆盖dev证书

 yourproject\node_modules\webpack-dev-server\ssl   with the **server.pem**

在chrome设置->管理证书

将server.crt导入到受信任的认证授权重新启动chrome

在package.json中

 "scripts": {
    "start": "set HTTPS=true&&react-scripts start",

Chrome 58+更新（发布于2017-04-19）

从Chrome 58开始，仅使用commonName识别主机的功能被删除。证书现在必须使用subjectAltName来标识其主机。请参阅此处的进一步讨论和此处的bug跟踪器。在过去，subjectAltName仅用于多主机证书，因此一些内部CA工具不包括这些证书。

如果您的自签名证书在过去运行良好，但突然开始在Chrome 58中生成错误，这就是原因。

因此，无论您使用什么方法来生成自签名证书（或由自签名CA签名的证书），请确保服务器的证书包含具有正确DNS和/或IP条目的subjectAltName，即使它仅适用于单个主机。

对于openssl，这意味着您的openssl配置（Ubuntu上的/etc/ssl/openssl.cnf）对于单个主机应该具有类似于以下内容的内容：

[v3_ca]   # and/or [v3_req], if you are generating a CSR
subjectAltName = DNS:example.com

或对于多个主机：

[v3_ca]   # and/or [v3_req], if you are generating a CSR
subjectAltName = DNS:example.com, DNS:host1.example.com, DNS:*.host2.example.com, IP:10.1.2.3

在Chrome的证书查看器（已移动到F12下的“安全”选项卡）中，您应该看到它列在“扩展名”下作为证书主题替代名称：