証明機関のルート証明書の有効期限と更新
2004年に、Linux上のOpenSSLとOpenVPNで提供される簡単な管理スクリプトを使用して、小さな認証局を設定しました。当時見つけたガイドに従って、ルートCA証明書の有効期間を10年に設定しました。それ以来、OpenVPNトンネル、Webサイト、および電子メールサーバーの多くの証明書に署名してきました。これらの証明書の有効期間もすべて10年です（これは間違っている可能性がありますが、当時はよくわかりませんでした）。
CAのセットアップに関する多くのガイドを見つけましたが、その管理、特にルートCA証明書の有効期限が切れたときに何をする必要があるかについての情報はほとんどありません。質問：
- ルートCA証明書の有効期限が切れた後、有効期間が延長された証明書は、後者が期限切れになるとすぐに無効になりますか、それとも（CA証明書の有効期間中に署名されたため）引き続き有効ですか？
- ルートCA証明書を更新し、有効期限が切れてもスムーズに移行できるようにするには、どのような操作が必要ですか？
- どういうわけか現在のルートCA証明書に別の有効期間で再署名し、新しく署名した証明書をクライアントにアップロードして、クライアント証明書を有効なままにできますか？
- または、すべてのクライアント証明書を、新しいルートCA証明書で署名された新しい証明書に置き換える必要がありますか？
- ルートCA証明書はいつ更新する必要がありますか？有効期限が近づいていますか、それとも有効期限までの妥当な時間ですか。
- ルートCA証明書の更新が主要な作業になる場合、次の更新時にスムーズに移行できるようにするには、どうすればよいですか（もちろん、有効期間を100年に設定する前に）。
一部のクライアントへの唯一のアクセスは、現在のCA証明書によって署名された証明書を使用するOpenVPNトンネルを経由するため、状況が少し複雑になるため、すべてのクライアント証明書を置き換える必要がある場合は、コピーする必要があります新しいファイルをクライアントに送信し、トンネルを再起動し、私の指を交差させ、後でそれが表示されることを願っています。
ルートCAで同じ秘密鍵を保持することで、すべての証明書が新しいルートに対して引き続き正常に検証できるようになります。あなたに必要なのは、新しいルートを信頼することだけです。
証明書の署名関係は、秘密鍵の署名に基づいています。新しい公開証明書を生成する間、同じ秘密鍵（および暗黙的に同じ公開鍵）を保持し、新しい有効期間とその他の新しい属性を必要に応じて変更すると、信頼関係が維持されます。 CRLも、証明書のように秘密鍵で署名されているため、古い証明書から新しい証明書へと継続できます。
確認しましょう！
ルート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暗号APIブラウザーでは、Apacheは古いルートを提示していますが、新しいルートはまだコンピューターの信頼されたルートストアにあります。 Apacheが別のチェーン（古いルート）を提示しているにもかかわらず、それは自動的に検出され、信頼された（新しい）ルートに対して証明書が検証されます。信頼されたルートから新しいルートを取り除き、元のルート証明書を追加した後、すべてが順調です。
それでおしまいです！更新するときに同じ秘密鍵を保持し、新しい信頼されたルートに入れ替えると、ほとんどすべての動作するになります。幸運を！
元のCAキーの更新された証明書にCA拡張機能がない可能性があることに気付きました。これは私にとってより適切に機能しました（v3 CA拡張が定義されている./ renewedselfsignedca.confと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
ルートの有効期間を延長する基本モード（公開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
@Bianconiglio plus -set_serialがうまくいきました。私のサーバーはイントラネットのみであるため、副作用についてあまり心配する必要はなく、今では「適切な」ソリューションに取り組む時間があります。
次の設定可能なスクリプトを使用しました。変数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
ルート証明書の有効期限が切れると、署名した証明書も期限切れになります。新しいルート証明書を生成し、それで新しい証明書に署名する必要があります。プロセスを数年ごとに繰り返したくない場合、唯一の実際のオプションは、ルート証明書の有効日付を10年または20年のように延長することです。私が自分で使用するために生成したルートは、20年に設定しました。
ルート証明書を「更新」することはできません。できることは新しいものを生成することだけです。
古いルートが期限切れになる少なくとも1〜2年前に新しいルートを生成します。これにより、何か問題が発生した場合にタイムウォールに違反することなく、切り替えることができます。そうすれば、新しい証明書で問題が解決するまで、常に一時的に古い証明書に戻すことができます。
VPNトンネルに関する限り、私はいくつかのテストベッドサーバーを設定して実験を行い、クライアントのマシンで実行する前に何をしなければならないかを正確に理解します。
私たちにも同じ問題がありましたが、Debianサーバーが古く、openSSLにこの問題があったためです。
https://en.wikipedia.org/wiki/Year_2038_problem
Debian 6で利用可能なOpenSSLの最後のバージョンがこの問題を引き起こしています。 2018年1月23日より後に作成されたすべての証明書はValityを生成します：1901年！
解決策は、OpenSSLを更新することです。クライアント用の構成ファイル（証明書付き）を再度作成できます。