Сохранение одного и того же закрытого ключа в вашем корневом ЦС позволяет всем сертификатам продолжать успешную проверку на новый корень; все, что от вас требуется - это доверять новому корню.
Отношения подписи сертификата основаны на подписи с закрытым ключом; сохранение одного и того же закрытого ключа (и, косвенно, того же открытого ключа) при создании нового открытого сертификата с новым периодом действия и любыми другими новыми атрибутами, измененными по мере необходимости, сохраняет доверительные отношения на месте. Списки отзыва сертификатов также могут переходить от старого сертификата к новому, поскольку они, как и сертификаты, подписаны закрытым ключом.
Итак, давайте проверим!
Сделать корневой 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/
Мы установим эти директивы на VirtualHostпрослушивании 443 - помните, 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)
Хорошо, а как насчет браузера, использующего крипто API от MS? Сначала нужно доверять руту, а потом все хорошо, с серийным номером нового рута:
И мы все еще должны работать со старым рутом. Переключите конфигурацию 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 crypto API, Apache представляет старый корень, но новый корень все еще находится в хранилище доверенных корней компьютера. Он автоматически найдет его и проверит сертификат по доверенному (новому) корню, несмотря на то, что Apache представляет другую цепочку (старый корень). После удаления нового корня из доверенных корней и добавления исходного корневого сертификата все в порядке:
Ну это все! Сохраняйте тот же самый закрытый ключ при обновлении, меняйте местами новый доверенный корень, и он почти все работает . Удачи!