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

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

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

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

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

85 голосов | спросил Remy Blank 30 PM000000120000000931 2011, 12:34:09

6 ответов


122

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

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

И мы все равно должны работать со старым корнем. Переключите конфигурацию 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)

И с помощью браузера API Crypto API Apache представляет старый root, но новый root все еще находится в доверенном корневом хранилище компьютера. Он автоматически найдет его и проверит сертификат против доверенного (нового) корня, несмотря на то, что Apache представляет другую цепочку (старый корень). После удаления нового корня из доверенных корней и добавления исходного корневого сертификата все хорошо:

oldroot


Итак, вот и все! Храните тот же секретный ключ при обновлении, замените новый доверенный корень, и он почти все просто работает . Удачи!

ответил Shane Madden 4 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowSun, 04 Sep 2011 22:40:29 +0400 2011, 22:40:29
13

Я заметил, что расширения 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
ответил Bianconiglio 22 PMpMon, 22 Apr 2013 14:31:02 +040031Monday 2013, 14:31:02
2

Основной режим для продления допустимого периода времени 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
ответил ggrandes 22 Jpm1000000pmTue, 22 Jan 2013 20:35:13 +040013 2013, 20:35:13
0

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

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

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

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

ответил Snowhare 4 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowSun, 04 Sep 2011 03:59:10 +0400 2011, 03:59:10
0

@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
ответил Wolfgang Fahl 30 J0000006Europe/Moscow 2017, 20:33:06
0

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

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

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

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

ответил Manuel 9 MarpmFri, 09 Mar 2018 13:38:54 +03002018-03-09T13:38:54+03:0001 2018, 13:38:54

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132