内部网络 CA：“无效的通用名称”或无效的证书（Internet Explorer 和 Windows 的证书 mmc 管理单元除外）

Question

我们在混合 Windows / Linux 环境中运行由 Ubuntu 16.04 服务器和用于内部资源的 OpenSSL 后端提供支持的内部证书颁发机构。

该 CA 与一些内部网站一起使用，试图为内部网站、软件部署等提供有效、可信的站点证书。我们有一个问题。

CA 根证书由 GPO 推送到我们所有的 Windows 系统，或者手动安装。但是，该 CA 签署的每个证书最终都会出现一些问题 - Chrome 和 Firefox 都表明该证书的通用名称无效，而其他实用程序（例如此处的 XMPP 服务器）无法验证该证书，即使 CA 证书在信托商店。

只有 Internet Explorer 遵守该证书。不幸的是，我们是一个 Chrome 和 Firefox 的房子，所以使用 IE 来处理所有事情将是一个问题。

有没有人想出一个解决方案来制作 OpenSSL CA 证书及其签发的证书的签名证书在 Chrome 和 Firefox 上没有“无效的通用名称”错误，从而允许将内部证书视为“有效”？

Answer 1

我实际上找到了核心问题，并进行了大量搜索。终于在StackOverflow上找到了答案，结合我对证书本身的实际数据的调查openssl req -text -noout -verify -in CSR.csr，以及读取CSR中的数据，openssl x509 -in certificate.crt -text -noout对生成的证书进行剖析，对比两者，指出了核心问题。

显然，OpenSSL 忽略了我们的配置文件中与 V3 扩展相关的部分，并且不会执行 v3 扩展，除非您在实际的 CA 签名步骤中正确地告诉它...

这是传递给openssl req命令的配置文件数据：

[ req ]
default_bits = 4096
prompt = no
default_md = sha256
distinguished_name = dn
req_extensions = v3_req

[ dn ]
C=US
ST=Pennsylvania
L=Somewhere
O=No Man's Land
OU=Internal
CN = chat.foo.bar.baz

[ v3_req ]
keyUsage = keyEncipherment, dataEncipherment
extendedKeyUsage=serverAuth
subjectAltName = @alt_names

[alt_names]
DNS.1   = chat.foo.bar.baz
DNS.2   = chat
DNS.3   = 10.1.2.151

以下标准调用不以某种方式尊重 v3 扩展：

openssl req -new -sha256 -out cert.csr -key cert.key -config csrgen.cnf

...然而，这个确实有效：

openssl req -new -sha256 -out cert.csr -key cert.key -config csrgen.cnf -extensions v3_req

...当使用 CA签署证书时，我们必须使用类似的东西，从我们存储所有站点证书的地方执行此操作（包括 CSR 和密钥，用于首先生成证书 - CA 证书和键位于/certauthority/...我们系统的单独部分）：

openssl x509 -req -days 3650 -in ./cert.csr -CA /certauthority/certs/cacert.pem -CAkey /certauthority/private/cakey.pem -CAserial /certauthority/CA/serial -CAcreateserial -out certificate.crt -extfile csrgen.cnf -extensions v3_req

此命令正确地将 v3 扩展名放入证书中，否则以某种方式忽略文件中的实际扩展名。这反过来又解决了 CN 和 SAN 问题，现在系统将证书返回为对内部站点和（大多数）内部服务“有效”。