我发现了很多有关建立CA的指南，但是关于其管理的信息很少，尤其是关于根CA证书过期时必须做的事情，这会在一段时间内发生在2014年。所以我有以下问题：
根CA证书到期后具有有效期的证书将在证书到期后立即失效，或者它们继续有效（因为它们是在CA证书的有效期内签名的）？
需要执行哪些操作来更新根CA证书并确保在其有效期内顺利过渡？
我可以以某种不同的有效期重新签署当前的根CA证书，然后上传新的-签署给客户的证书，以便使客户证书保持有效？
还是我需要用新的根CA证书签名的新证书替换所有客户证书？
根CA证书是否需要更新？
如果要更新根CA证书成为一项主要工作，那么我现在可以做些什么呢？有效期为100年，当然）？
由于我对某些客户端的唯一访问是通过使用当前CA证书签名的证书的OpenVPN隧道，因此情况变得有些复杂，因此，如果我必须替换所有客户端证书，则需要将新文件发送给客户端，重新启动隧道，用手指指望以后再出现。
#1 楼
在根CA上保留相同的私钥可以使所有证书继续针对新的根成功验证。您所需要做的就是信任新的根。证书签名关系基于私钥的签名；在生成新的公共证书，保持新的有效期以及根据需要更改任何其他新属性的同时，保持相同的私钥（以及隐含的相同的公钥），可以保持信任关系。 CRL也可以从旧证书延续到新证书，就像由私钥签名的证书一样。
因此，让我们进行验证！
< br根CA：
openssl req -new -x509 -keyout root.key -out origroot.pem -days 3650 -nodes
从中生成子证书：
openssl genrsa -out cert.key 1024
openssl req -new -key cert.key -out cert.csr
签名子证书：
openssl x509 -req -in cert.csr -CA origroot.pem -CAkey root.key -create_serial -out cert.pem
rm cert.csr
全部设置在那里，正常的证书关系。让我们来验证信任：
# openssl verify -CAfile origroot.pem -verbose cert.pem
cert.pem: OK
好吧，现在我们说已经过去了10年。让我们从相同的根私钥中生成一个新的公共证书。
..为什么？它们是不同的文件，对吗？
openssl req -new -key root.key -out newcsr.csr
openssl x509 -req -days 3650 -in newcsr.csr -signkey root.key -out newroot.pem
rm newcsr.csr
是的，但这并不意味着新的公钥在密码上与证书上的签名不匹配。不同的序列号，相同的模数： />启动一个Apache实例，然后进行调试（debian文件结构，根据需要进行调整）：
在443上侦听-请记住，在生成和签名
VirtualHost时，甚至根本不存在newroot.pem根证书。 > # openssl verify -CAfile newroot.pem -verbose cert.pem
cert.pem: OK
好的，使用MS的加密API的浏览器怎么样？首先要信任根，然后使用新根的序列号就可以了，一切都很好：
而且，我们仍然应该使用旧根。在以下位置切换Apache的配置：
# sha1sum newroot.pem
62577e00309e5eacf210d0538cd79c3cdc834020 newroot.pem
# sha1sum origroot.pem
c1d65a6cdfa6fc0e0a800be5edd3ab3b603e1899 origroot.pem
对Apache进行完全重新启动，重新加载不会正确切换证书。 />
并且，通过MS crypto API浏览器，Apache提供了旧的根目录，但是新的根目录仍在计算机的受信任根存储区中。即使Apache提供了不同的链（旧根），它也会自动找到它并针对受信任的（新）根验证证书。在从受信任的根目录中剥离了新的根目录并添加了原始的根证书之后，一切就好了：续订时保留相同的私钥，交换新的受信任的根，它几乎就可以正常工作。祝你好运！
#2 楼
我已经注意到原始CA密钥的更新证书中可能缺少CA扩展名。和ca.crt被假定为原始CA密钥和证书）：openssl x509 -x509toreq -in ca.crt -signkey ca.key -out renewedselfsignedca.csr
echo -e "[ v3_ca ]\nbasicConstraints= CA:TRUE\nsubjectKeyIdentifier= hash\nauthorityKeyIdentifier= keyid:always,issuer:always\n" > renewedselfsignedca.conf
openssl x509 -req -days 1095 -in renewedselfsignedca.csr -signkey ca.key -out renewedselfsignedca.crt -extfile ./renewedselfsignedca.conf -extensions v3_ca
评论
这是非常有用的补充。如果您在原始根CA上有任意设置，那么实际有效的答案对我来说就不会产生足够兼容的证书。
– Theuni
2014年12月2日于17:06
其次，非常有帮助。另一个补充：像Scott Presnell在接受的答案的注释中一样，我还必须手动指定更新证书的十六进制序列号，以使其与旧证书相匹配。这意味着在后面的x509命令中添加-set_serial 0xdeadbeefabba（不是真正的序列号:)）。只有这样，我的客户证书才可以针对更新的CA证书进行成功验证。
– JK Laiho
15年5月19日在13:27
此方法比以前的证书保留相同的信息，因此更容易。
–lepe
16年11月4日在6:30
我已经为此解决方案加上-set_serial创建了脚本-请参阅我的答案
– Wolfgang Fahl
17年6月30日在17:33
在将这个问题花了将近一天的时间之后，这个答案为我节省了很多工作。
– Onitlikesonic
17年11月24日在12:58
#3 楼
延长根有效期的基本模式（您需要公用X.509和关联的私钥）：从公用X.509和私钥生成CSR：
openssl x509 -x509toreq -in XXX.crt -signkey XXX.key -out XXX.csr
用私钥重新签名CSR：
openssl x509 -in XXX.csr -out XXX.crt -signkey XXX.key -req -days 365
评论
这些命令对我有效，运行本地/自签名CA，而最重要的答案失败，因为无法在openssl验证期间验证第一个证书。
–重新删除
20-11-30在12:34
#4 楼
@Bianconiglio加-set_serial为我工作。我的服务器仅是Intranet，因此我不必担心有什么副作用，现在我有时间来研究“适当的”解决方案。
我使用了以下可配置脚本。只需设置变量CACRT，CAKEY和NEWCA。
# WF 2017-06-30
# https://serverfault.com/a/501513/162693
CACRT=SnakeOilCA.crt
CAKEY=SnakeOilCA.key
NEWCA=SnakeOilCA2017
serial=`openssl x509 -in $CACRT -serial -noout | cut -f2 -d=`
echo $serial
openssl x509 -x509toreq -in $CACRT -signkey $CAKEY -out $NEWCA.csr
echo -e "[ v3_ca ]\nbasicConstraints= CA:TRUE\nsubjectKeyIdentifier= hash\nauthorityKeyIdentifier= keyid:always,issuer:always\n" > $NEWCA.conf
openssl x509 -req -days 3650 -in $NEWCA.csr -set_serial 0x$serial -signkey $CAKEY -out $NEWCA.crt -extfile ./$NEWCA.conf -extensions v3_ca
openssl x509 -in $NEWCA.crt -enddate -serial -noout
#5 楼
当您的根证书过期时，与您签署的证书也将过期。您将必须生成一个新的根证书并用它签名新证书。如果您不想每隔几年重复一次此过程，唯一的实际选择是将根证书的有效日期延长大约十年或二十年：我为自己使用而生成的根定为二十年。 />您不能“续订”根证书。您所能做的就是生成一个新的根。
在您的旧根到期之前至少一两年内生成一个新的根，这样您就可以有时间在不出错的情况下进行转换。这样一来，您始终可以暂时切换回旧的证书，直到解决新的证书所遇到的麻烦。进行实验，以便在使用客户的机器之前准确了解您必须做什么。
评论
该答复似乎表明可以通过重新使用根证书密钥来更新根证书。但是我怀疑这与从头开始没有什么不同，因为新证书将具有不同的签名，因此不会验证现有的客户端证书。
–雷米·空白
2011年9月4日上午11:47
是的，您可以延长有效期...并且比重新创建所有的pki，客户端证书并重新信任新的根目录要少...
–ggrandes
13年1月22日在16:25
颁发新的最终实体证书的部分不一定正确。这取决于在下级CA和最终实体证书中如何表示授权密钥标识符（AKID）。如果AKID基于{专有名称，序列号}，则将实现连续性。另请参阅RFC 4518，Internet X.509公钥基础结构：认证路径构建。
–user145545
16-3-31在21:59
#6 楼
我们遇到了同样的问题，这就是我们的情况，因为Debian服务器已经过时，而openSSL出现了这个问题：可用于Debian 6的最新版本的OpenSSL带来了此问题。
2018年1月23日之后创建的所有证书均产生有效期：1901年！
解决方案是更新OpenSSL。您可以再次为客户端创建配置文件（带有证书）。
评论
无论如何，如果您只是要重用相同的私钥，那么创建新的根证书有什么意义呢？如果您一遍又一遍地这样做，那么即使有证书的到期日期又有什么意义呢？我认为根到期是用来迫使管理员创建一个新的（很可能是更强壮的）私钥，它对于试图破解密钥的不断发展的计算机来说更加安全。 20年前制作的40位密钥不够安全
– jvhashe
2013年8月22日19:00
@jvhashe如果根证书的加密强度不再足够，则无论其到期日期如何，都应删除它。如果您要生成自己的根，没有什么可以阻止您将其设置为在不再存在于地球上的数百年后过期。到期与根证书几乎没有关系-对于子证书，到期也与加密强度无关（询问准备在十月撤销所有1024位证书的CA）-有关更多信息，请参见此处。
– Shane Madden
13年8月23日在1:19
除上述内容外，我发现序列号也必须相同才能使用此方法。
–斯科特·普雷斯内尔
2014年8月25日14:44
-set_serial 01-WTF ???您不能重复使用序列号。您甚至还参考了RFC 4158，Internet X.509公钥基础结构：认证路径构建吗？还是只是在进行过程中进行化妆？您不知道用户代理开始构建路径时给他们带来的问题。
–user145545
16-11-10在18:09
@jww你读了答案吗？这只是加密技术起作用的事实的证明。实际上，该命令只是生成一个测试证书，我们可以稍后对它进行验证，以测试新旧根证书之间的关系。如果有人直接使用这些命令，我当然希望会发生问题，他们会意识到，在盲目运行某个东西之前（或逃避在实验室中是否可以接受01的问题），他们需要注意该东西的上下文。
– Shane Madden
16年10月10日在18:18