核证机关根证书有效期及续期

Question

2004年，我在Linux上使用OpenSSL和OpenVPN提供的简单管理脚本建立了一个小型认证机构。根据当时发现的指南，我将根CA证书的有效期设置为10年。从那时起，我签署了许多OpenVPN隧道、网站和电子邮件服务器的证书，所有这些证书的有效期都是10年(这可能是错误的，但当时我不太清楚)。

我已经找到了许多关于建立CA的指南，但是关于CA管理的信息非常少，特别是在根CA证书过期时必须做些什么，这将在2014年的某个时候发生。因此，我有以下问题：

• 在根CA证书到期后具有有效期延长的证书将在根CA证书过期后立即失效，还是将继续有效(因为它们是在CA证书有效期内签署的)？
• 需要哪些操作来更新根CA证书并确保其到期时的平稳过渡？
  • 我是否可以用不同的有效期重新签署当前的根CA证书，并将新签署的证书上传到客户端，以便客户端证书仍然有效？
  • 还是需要将所有客户端证书替换为由新根CA证书签名的新证书？

• 何时应该更新根CA证书？接近到期日，还是到期前的合理时间？
• 如果根CA证书的更新成为一项主要工作，我现在还能做什么更好的工作来确保下一次更新时更顺利的过渡(当然，除了将有效期定为100年之外)？

情况稍微复杂一些，因为我对一些客户端的唯一访问是通过使用当前CA证书签名的证书的OpenVPN隧道，所以如果我必须替换所有客户端证书，我将需要将新文件复制到客户端，重新启动隧道，交叉手指，并希望以后会出现。

Answer 1

在根CA上保留相同的私钥允许所有证书继续对新根成功地进行验证；您所需要的只是信任新根。

证书签名关系基于来自私钥的签名；在生成新的公共证书时保留相同的私钥(并隐式地保留相同的公钥)，并根据需要更改新的有效期和任何其他新属性，从而保持信任关系。CRLs也可以从旧证书继续到新证书，就像证书一样，由私钥签名。

那么，让我们验证一下！

创建根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

然后..。成功了吗？

# openssl verify -CAfile newroot.pem -verbose cert.pem
cert.pem: OK

但是..。为什么？它们是不同的文件，对吧？

# sha1sum newroot.pem
62577e00309e5eacf210d0538cd79c3cdc834020  newroot.pem
# sha1sum origroot.pem
c1d65a6cdfa6fc0e0a800be5edd3ab3b603e1899  origroot.pem

是的，但是，这并不意味着新的公钥在加密上与证书上的签名不匹配。不同序列号，相同模数：

# openssl x509 -noout -text -in origroot.pem
        Serial Number:
            c0:67:16:c0:8a:6b:59:1d
...
            RSA Public Key: (1024 bit)
                Modulus (1024 bit):
                    00:bd:56:b5:26:06:c1:f6:4c:f4:7c:14:2c:0d:dd:
                    3c:eb:8f:0a:c0:9d:d8:b4:8c:b5:d9:c7:87:4e:25:
                    8f:7c:92:4d:8f:b3:cc:e9:56:8d:db:f7:fd:d3:57:
                    1f:17:13:25:e7:3f:79:68:9f:b5:20:c9:ef:2f:3d:
                    4b:8d:23:fe:52:98:15:53:3a:91:e1:14:05:a7:7a:
                    9b:20:a9:b2:98:6e:67:36:04:dd:a6:cb:6c:3e:23:
                    6b:73:5b:f1:dd:9e:70:2b:f7:6e:bd:dc:d1:39:98:
                    1f:84:2a:ca:6c:ad:99:8a:fa:05:41:68:f8:e4:10:
                    d7:a3:66:0a:45:bd:0e:cd:9d
# openssl x509 -noout -text -in newroot.pem
        Serial Number:
            9a:a4:7b:e9:2b:0e:2c:32
...
            RSA Public Key: (1024 bit)
                Modulus (1024 bit):
                    00:bd:56:b5:26:06:c1:f6:4c:f4:7c:14:2c:0d:dd:
                    3c:eb:8f:0a:c0:9d:d8:b4:8c:b5:d9:c7:87:4e:25:
                    8f:7c:92:4d:8f:b3:cc:e9:56:8d:db:f7:fd:d3:57:
                    1f:17:13:25:e7:3f:79:68:9f:b5:20:c9:ef:2f:3d:
                    4b:8d:23:fe:52:98:15:53:3a:91:e1:14:05:a7:7a:
                    9b:20:a9:b2:98:6e:67:36:04:dd:a6:cb:6c:3e:23:
                    6b:73:5b:f1:dd:9e:70:2b:f7:6e:bd:dc:d1:39:98:
                    1f:84:2a:ca:6c:ad:99:8a:fa:05:41:68:f8:e4:10:
                    d7:a3:66:0a:45:bd:0e:cd:9d

让我们进一步验证它在真实的证书验证中是否有效。

启动一个Apache实例，然后让它运行(debian文件结构，根据需要进行调整)：

# cp cert.pem /etc/ssl/certs/
# cp origroot.pem /etc/ssl/certs/
# cp newroot.pem /etc/ssl/certs/
# cp cert.key /etc/ssl/private/

我们将在侦听443的VirtualHost上设置这些指令--记住，newroot.pem根证书在生成和签名cert.pem时根本不存在。

SSLEngine on
SSLCertificateFile /etc/ssl/certs/cert.pem
SSLCertificateKeyFile /etc/ssl/private/cert.key
SSLCertificateChainFile /etc/ssl/certs/newroot.pem

让我们看看openssl是如何看待它的：

# openssl s_client -showcerts -CAfile newroot.pem -connect localhost:443

Certificate chain
 0 s:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=server.lan
   i:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=root
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
 1 s:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=root
   i:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=root
-----BEGIN CERTIFICATE-----
MIICHzCCAYgCCQCapHvpKw4sMjANBgkqhkiG9w0BAQUFADBUMQswCQYDVQQGEwJB
...
-----END CERTIFICATE-----
(this should match the actual contents of newroot.pem)
...
Verify return code: 0 (ok)

好的，使用MS的加密API的浏览器怎么样？首先要信任根目录，然后使用新根的序列号，这样就很好了：

而且，我们也应该和老的根一起工作。切换Apache的配置：

SSLEngine on
SSLCertificateFile /etc/ssl/certs/cert.pem
SSLCertificateKeyFile /etc/ssl/private/cert.key
SSLCertificateChainFile /etc/ssl/certs/origroot.pem

在Apache上完全重新启动，重新加载将不能正确切换证书。

# openssl s_client -showcerts -CAfile origroot.pem -connect localhost:443

Certificate chain
 0 s:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=server.lan
   i:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=root
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
 1 s:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=root
   i:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=root
-----BEGIN CERTIFICATE-----
MIIC3jCCAkegAwIBAgIJAMBnFsCKa1kdMA0GCSqGSIb3DQEBBQUAMFQxCzAJBgNV
...
-----END CERTIFICATE-----
(this should match the actual contents of origroot.pem)
...
Verify return code: 0 (ok)

而且，使用MS浏览器，Apache呈现的是旧的根，但是新的根仍然在计算机的可信根存储中。它将自动找到它，并根据受信任的(新的)根验证证书，尽管Apache提供了一个不同的链(旧根)。在从受信任的根中剥离新根并添加原始根证书后，一切都很好：

就这样！在更新时保留相同的私钥，在新的受信任的根中交换，而且几乎所有的私钥都能工作。祝好运!

Answer 2

我注意到CA扩展可能在原始CA密钥的更新证书中丢失。这对我来说更合适(它创建了一个./renewedselfsignedca.conf，其中定义了v3 CA扩展，并且假定ca.key和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

Answer 3

扩展根的有效期的基本模式(您需要公共X.509和asociated私钥)：

从公共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