我为公司内部的几个服务创建了一个自签名根证书颁发机构，这些服务都是我自己配置的（大部分通过 HTTPS 提供）。然后我为这些服务创建了证书，并由该 CA 签名。
现在我想向根 CA 添加 x509 扩展（CRL 分发点），但不使该 CA 颁发的现有服务器证书无效。这可能吗？
我的直觉是“是”，因为据我所知，访问相应的私钥是必要的和足以对证书身份拥有“完全的权限”。也就是说，除非在生成证书时将某种随机数与公钥一起纳入证书中（很可能）。
我对 SSL 证书管理还不太熟悉，但我（认为）了解标准信任链的基础知识。我还熟悉其他 PKI 加密的基本使用：我管理 SSH 密钥并使用 GPG 进行签名和加密。我学的是计算机科学，但在密码学方面我只是一个自学成才的业余爱好者。
我从未为原始 IIRC 制作过 CSR（我认为它是 的直接输出openssl req -new -x509）。当然，我仍然拥有原始 CA 的私钥，使用它我能够将原始证书“反转”为证书签名请求：
openssl x509 -x509toreq -in MyCA.pem -out MyCA.csr -signkey private/MyCA.key
我希望这可以有效地“提取”上面提到的随机数，并允许我重新创建证书，但这次使用字段crlDistributionPoints，因此所有使用原始 CA 签名的证书仍然会针对这个新的 CA 进行验证，但客户端会从字段中指定的 HTTP URL 检索我的（当前为空的）CRL 文件。
所以我制作了一个扩展配置文件ext.conf：
[ cert_ext ]
subjectKeyIdentifier=hash
crlDistributionPoints=URI:http://security.mycompany.co.za/root.crl
我从 CSR 生成了新版本的根 CA：
openssl x509 -extfile ./ext.conf -extensions cert_ext -req -signkey private/MyCA.key -in MyCA.csr -out MyNewCA.pem
现在当我使用openssl x509 -text -in MyNewCA.pem | less
我可以看到 CRL 扩展部分：
X509v3 extensions:
X509v3 Subject Key Identifier:
82:D0:01:03:49:FF:30:16:FA:DC:0A:1E:C1:8C:3D:66:A1:78:FF:F8
X509v3 CRL Distribution Points:
Full Name:
URI:http://security.mycompany.co.za/root.crl`
但可惜的是！我之前签署的证书不再能通过这个证书验证：
openssl verify -verbose -CAfile MyCA.pem git.pem
git.pem: OK
openssl verify -verbose -CAfile MyNewCA.pem git.pem
git.pem: <redacted DN>
error 20 at 0 depth lookup:unable to get local issuer certificate
我主要想了解证书的工作原理和工作原理。但我也希望找到导致这个问题的解决方案，所以这里也有一些背景信息。
我是如何陷入这种困境的：一旦我的 CA 通过 Explorer RMB → 在 Windows 上安装证书 GUI 进行安装，或者在 Debian 和 Ubuntu 上/usr/local/share/ca-certificates进行安装update-ca-certificates，内部服务的 HTTPS 就可以很好地工作。但我最近遇到了一个例外：Windows 上的 Git，特别是如果安装以使用 Windows 安全通道作为 SSL 后端。这显然默认坚持 SSL 证书中必须有一个 CRL 字段。
因此，我猜测这确实是 Windows 安全通道问题，因为我不断遇到的错误消息似乎完全是 Microsoft 特有的：fatal: unable to access 'https://[email protected]/gitblit/r/secret_project.git/': schannel: next InitializeSecurityContext failed: Unknown error (0x80092012) - The revocation function was unable to check revocation for the certificate.
如果我使用 OpenSSL 安装 Git，并手动将我的 CA 连接到 git.http.sslcainfo 指向的文件上，那么它就可以工作，但我担心，如果我的用户觉得这个过程比点击“简单”的 Windows 证书安装程序 GUI 更费力，他们会倾向于拒绝 SSL 身份验证。
答案1
只要满足以下条件，两份证书即视为相同：主题名称和公钥的证书匹配。
因此，您需要做的就是重新使用密钥并确保新证书中的主题名称与旧证书相同。之后，您可以更改任何其他字段和/或扩展，生成的证书将被视为相同。
例如，创建您的 OpenSSL 配置文件：
[ req ]
prompt = no
string_mask = default
distinguished_name = x509_distinguished_name
x509_extensions = x509_ext
[ x509_distinguished_name ]
# Note that the following are in 'reverse order' to what you'd expect to see.
# Adjust for your setup:
countryName = za
organizationName = My Company
organizationalUnitName = Security
commonName = My Root CA
[ x509_ext ]
basicConstraints = critical,CA:true
keyUsage = critical, keyCertSign, cRLSign
subjectKeyIdentifier = hash
crlDistributionPoints = URI:http://security.mycompany.co.za/root.crl
并将其另存为例如rootca.cnf。确保的元素[req_distinguished_name]与原始根 CA 证书中的元素相同（这是相同的主题名称部分）。
接下来运行：
openssl req -new -x509 -key rootca.key -out MyNewCA.pem -config rootca.cnf
其中rootca.key，原始证书中使用的私钥（这是相同的公钥/私钥部分）。
这将创建MyNewCA.pem，您可以使用以下方法进行检查：
$ openssl x509 -noout -text -in MyNewCA.pem
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 17564687072266118846 (0xf3c24dd49d5166be)
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=za, O=My Company, OU=Security, CN=My Root CA
Validity
Not Before: Jul 15 05:05:54 2017 GMT
Not After : Aug 14 05:05:54 2017 GMT
Subject: C=za, O=My Company, OU=Security, CN=My Root CA
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:c8:3d:32:8a:56:31:f6:27:1a:ce:9e:b2:1d:fb:
ce:9f:ce:5b:42:25:aa:fe:8b:f4:34:32:ac:b3:02:
50:71:f8:c3:43:0c:c7:2c:9f:fe:48:1b:c6:c0:e7:
d6:44:a9:e7:d7:a0:7e:58:f4:b6:38:61:7e:d0:af:
0f:56:21:e7:49:7a:66:13:f5:7a:fe:3d:ab:65:f8:
01:eb:52:a7:3b:ae:a0:cf:50:57:b9:e0:09:0b:1f:
90:14:fb:18:56:1d:57:99:a9:76:a2:63:d1:c2:d3:
a3:f4:3a:ff:91:0d:ee:8d:44:13:58:00:09:93:da:
e8:6a:fd:64:5f:c3:42:8e:2a:49:6e:0d:73:b7:b9:
d4:6c:c6:ce:30:c5:82:24:a5:00:37:17:a0:1d:f1:
c9:e9:e3:18:48:22:4f:33:96:a7:3c:a9:31:f1:3f:
14:40:6a:74:e8:78:82:45:04:d4:4b:56:0b:cd:be:
48:8d:03:fb:39:70:0b:91:99:70:06:bd:5e:8b:f2:
d1:f4:6f:fc:ce:e7:f8:3c:0a:20:ea:35:b8:5f:2f:
ee:8d:ff:d3:93:85:6b:fb:71:db:1b:e6:e9:1d:a7:
f8:e4:ae:f4:71:fe:35:a7:89:24:af:69:a4:34:3b:
14:66:05:02:5e:2a:1d:ac:e0:d2:48:6c:13:4e:75:
58:93
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints: critical
CA:TRUE
X509v3 Key Usage: critical
Certificate Sign, CRL Sign
X509v3 Subject Key Identifier:
3B:45:93:3A:2A:BC:39:29:36:13:6C:BD:B6:B4:31:C7:E7:BB:32:73
X509v3 CRL Distribution Points:
Full Name:
URI:http://security.mycompany.co.za/root.crl
Signature Algorithm: sha256WithRSAEncryption
4d:96:d4:03:4f:e3:7c:26:be:59:f8:23:87:60:f7:4c:d3:a1:
1c:77:a1:14:e3:e7:da:c8:2a:a3:1b:06:2a:4d:55:1c:83:26:
73:46:0d:8a:e4:b7:d1:1e:38:cc:78:90:00:01:b3:8e:f9:3c:
62:be:04:09:90:4e:22:87:b1:aa:bd:f9:73:bd:a7:76:ad:d5:
ae:2d:7a:1c:1e:1a:67:c8:57:4c:f9:6d:8b:62:d6:e5:ea:e0:
40:5c:12:28:7e:ea:f0:0c:d6:cd:f4:1d:d5:56:09:ad:43:b4:
eb:8c:68:ce:56:a2:a8:ae:a4:d5:35:bb:58:b8:ed:82:82:b5:
ef:cb:e2:6d:76:61:ed:ee:a5:1f:68:95:07:ed:5b:f0:65:92:
d2:dc:1d:c6:fa:7f:e0:c9:38:c2:c6:6f:03:38:e7:3a:b0:24:
06:e0:bc:07:dd:e7:a0:dc:74:09:e5:37:7b:66:e1:6f:47:4c:
71:ff:02:48:7f:d4:4f:ce:cb:91:e9:ee:cd:b6:f1:0a:03:19:
3e:19:05:7d:8f:48:e7:f1:cc:07:37:3d:91:3c:6f:54:71:3c:
a2:6c:55:c3:03:c1:7f:eb:9e:70:f1:8f:a1:fb:62:33:8b:86:
2c:79:bc:76:e2:01:9a:68:df:af:40:a1:b2:9c:f6:a1:e1:6e:
2a:dd:1a:d6
使用这个新证书代替原证书。
您可以更改其他字段和扩展，例如证书的有效期，但请记住，您实际上不应该basicConstraints = critical,CA:true对根 CA 证书有任何限制（除此以外）。
经过进一步考虑，您的问题可能只是因为您的替换根 CA 证书没有扩展basicConstraint名keyUsage。您可能值得尝试将这两个扩展名添加到您的ext.conf第一个证书中，然后使用您发布的方法测试生成的新根 CA 证书-x509toreq。