Вопрос: Срок действия и продление корневого сертификата сертификационного центра


В 2004 году я создал небольшой центр сертификации с использованием OpenSSL в Linux и простые сценарии управления, предоставляемые OpenVPN. В соответствии с руководствами, которые я нашел в то время, я установил срок действия сертификата корневого ЦС на 10 лет. С тех пор я подписал много сертификатов для туннелей OpenVPN, веб-сайтов и серверов электронной почты, все из которых также имеют срок действия 10 лет (возможно, это было неправильно, но в то время я не знал лучше).

Я нашел множество руководств по настройке ЦС, но только очень мало информации о его управлении и, в частности, о том, что должно быть сделано, когда истекает срок действия корневого сертификата ЦС, что произойдет некоторое время в 2014 году. Поэтому у меня есть следующее вопросов:

  • Будут ли сертификаты, срок действия которых истекает после истечения срока действия корневого сертификата ЦС, становятся недействительными, как только последний истекает, или они будут оставаться действительными (поскольку они были подписаны в течение срока действия сертификата ЦС)?
  • Какие операции необходимы для обновления корневого сертификата ЦС и обеспечения плавного перехода по истечении срока его действия?
    • Могу ли я каким-либо образом переписать текущий корневой сертификат ЦС с другим сроком действия и загрузить недавно подписанный сертификат клиентам, чтобы сертификаты клиентов оставались действительными?
    • Или мне нужно заменить все клиентские сертификаты новыми, подписанными новым корневым сертификатом CA?
  • Когда следует обновить корневой сертификат ЦС? Близко к истечению срока действия или разумное время до истечения срока действия?
  • Если возобновление корневого сертификата ЦС станет важной частью работы, что я могу сделать лучше сейчас, чтобы обеспечить более плавный переход при следующем обновлении (не считая, конечно, срок действия до 100 лет)?

Ситуация немного усложняется тем фактом, что мой единственный доступ к некоторым клиентам осуществляется через туннель OpenVPN, который использует сертификат, подписанный текущим сертификатом CA, поэтому, если мне нужно заменить все сертификаты клиентов, мне нужно будет скопировать новые файлы для клиента, перезапустить туннель, пересечь пальцы и надеяться, что он появится позже.


85
2017-08-30 08:34


Источник




Ответы:


Сохранение того же частного ключа в корневом ЦС позволяет всем сертификатам продолжать успешно проверять новый корень; все, что от вас требуется, - это доверять новому корню.

Отношение подписания сертификата основано на сигнатуре от закрытого ключа; сохраняя один и тот же секретный ключ (и, неявно, тот же самый открытый ключ) при создании нового публичного сертификата, с новым сроком действия и любыми другими новыми атрибутами, измененными по мере необходимости, сохраняет доверительные отношения на месте. CRL также могут переходить от старого сертификата к новому, как и к ним, например, к сертификатам, подписанным закрытым ключом.


Итак, давайте проверим!

Создание корневого ЦС:

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

Давайте посмотрим, как opensl видит это:

# 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? Сначала нужно доверять корню, тогда все хорошо, с порядковым номером нового корня:

newroot

И мы все равно должны работать со старым корнем. Переключите конфигурацию 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 представляет старый root, но новый root все еще находится в доверенном корневом хранилище компьютера. Он автоматически найдет его и проверит сертификат против доверенного (нового) корня, несмотря на то, что Apache представляет другую цепочку (старый корень). После удаления нового корня из доверенных корней и добавления исходного корневого сертификата все хорошо:

oldroot


Итак, это все! Сохраняйте тот же секретный ключ при обновлении, свопите в новый доверенный корень, и это почти все просто работает, Удачи!


122
2017-09-04 18:40



В любом случае, какой смысл создавать новый корневой сертификат, если вы собираетесь повторно использовать один и тот же закрытый ключ? Если вы продолжаете делать это снова и снова, то в чем смысл даже даты истечения срока действия сертификата? Я подумал, что срок использования корня был использован, чтобы заставить админов сделать более новый (наиболее вероятно более сильный) закрытый ключ, который более защищен от когда-либо продвигающихся машин, пытающихся разбить ключи. 40-битный ключ, сделанный 20 лет назад, недостаточно безопасен для - jvhashe
@jvhashe Если корневой сертификат больше не криптографически достаточно силен, тогда вы должны избавиться от него, независимо от его срока годности. Если вы создаете свой собственный корень, нет ничего, что помешало бы вам установить его, чтобы истечь сотни лет назад, когда вы больше не будете на планете. Истечение срока действия вряд ли имеет отношение к корневому сертификату - и для дочернего сертификата истечение на самом деле не связано с криптографической силой (попросите ЦС, которые готовятся отменить все 1024-разрядные сертификаты в октябре) - см. Вот для получения дополнительной информации. - Shane Madden♦
В дополнение к вышесказанному, я обнаружил, что серийный номер должен быть таким же, чтобы этот метод работал. - Scott Presnell
-set_serial 01 - WTF ??? ВЫ НЕ МОЖЕТЕ ПОЛУЧИТЬ СЕРИЙНЫЕ НОМЕРА, Вы даже консультировались RFC 4158, Internet X.509 Инфраструктура открытого ключа: построение пути сертификации? Или ты просто делаешь это, когда идешь? Вы не знаете проблем, которые вы вызываете в пользовательских агентах, когда они начинают строить путь. - jww
@Shane - Этот ответ является ссылаясь и используется в дикой природе. См., Например, Обновление Центра сертификации в OPENSSL Проверка сбоя на переполнение стека. Я здесь, потому что ОП процитировал это. - jww


Я заметил, что расширения 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

13
2018-04-22 10:31



Это было чрезвычайно полезным дополнением. Фактически действительный ответ не приводит к достаточно совместимому сертификату для меня, если у вас есть произвольные настройки в исходном корне. - Theuni
Прикольно, очень полезно. Еще одно дополнение: как Скотт Преснелл в комментариях к принятому ответу, мне также пришлось вручную указать шестнадцатеричный серийный номер обновленного сертификата, чтобы он соответствовал старому. Это означало добавление -set_serial 0xdeadbeefabba (а не реальный серийный номер :) :) для последней команды x509. Только после этого мои клиентские сертификаты успешно подтвердили сертификат обновленного CA. - JK Laiho
Этот метод проще, поскольку он хранит ту же информацию, что и предыдущий сертификат. - lepe
Я создал скрипт для этого решения плюс -set_serial - см. Мой ответ - Wolfgang Fahl
Этот ответ сэкономил мне много работы, потратив почти день на проблему, которая требовала этого, я почти собирался сдаться, я советую вам шляпу за это! - Onitlikesonic


Основной режим для продления допустимого периода времени root (вам нужен общедоступный X.509 и выделенный личный ключ):

Создайте CSR из общедоступного X.509 и частного ключа:

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

2
2018-01-22 16:35





Когда ваш корневой сертификат истекает, так же как и сертификаты, которые вы подписали с ним. Вам нужно будет создать новый корневой сертификат и подписать с ним новые сертификаты. Если вы не хотите повторять процесс каждые несколько лет, единственным реальным вариантом является продление действительной даты в корневом сертификате примерно на десять или двадцать лет: корень, который я создал для собственного использования, я установил двадцать лет.

Вы не можете «обновить» корневой сертификат. Все, что вы можете сделать, это создать новый.

Создайте новый корень, по крайней мере, год или два, прежде чем ваш старый истечет, чтобы у вас было время сменить, не будучи против часовой стены, если что-то пойдет не так. Таким образом, вы всегда можете временно вернуться к старым сертификатам, пока не получите свои проблемы с прорезями с новым, разрешенным.

Что касается туннелей VPN, я бы поставил пару тестовых серверов для экспериментов, чтобы вы точно поняли, что вам нужно сделать, прежде чем делать это с помощью машины клиента.


0
2017-09-03 23:59



Этот ответ похоже, предполагает, что можно обновить корневой сертификат, повторно используя его ключ. Но я подозреваю, что это ничем не отличается от начала с нуля, поскольку новый сертификат будет иметь другую подпись и, следовательно, не будет проверять существующие сертификаты клиентов. - Remy Blank
да, вы можете продлить срок действия ... и работать меньше, чем воссоздать все pki, клиентские сертификаты и восстановить новый root ... - ggrandes
Часть о выдаче новых сертификатов конечных сущностей необязательна. Это зависит от того, как идентификатор ключа управления (AKID) представлен в подчиненных ЦС и сертификатах конечного объекта. Если AKID основан на {Отличительное имя, серийный номер}, то преемственность будет достигнута. Также см RFC 4518, Internet X.509 Инфраструктура открытого ключа: построение пути сертификации, - jww


@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

0
2018-06-30 17:33





У нас была та же проблема, и это было в нашем случае, потому что сервер Debian был до настоящего времени, и openSSL столкнулся с этой проблемой:

https://en.wikipedia.org/wiki/Year_2038_problem

Последняя версия OpenSSL, доступная для Debian 6, приносит эту проблему. Все сертификаты, созданные после 23.01.2018, производят Vality: за 1901 год!

Решение заключается в обновлении OpenSSL. Вы можете снова создать файлы конфигурации (с сертификатами) для клиентов.


0
2018-03-09 10:38