Я создал самозаверяющий корневой центр сертификации для нескольких внутренних служб в нашей компании, который я настроил сам (в основном обслуживаемый по HTTPS). Затем я создал сертификаты для этих служб, подписанные этим CA.
Теперь я хочу добавить расширение x509 (точка распространения CRL) к корневому ЦС без аннулирования существующих сертификатов сервера, выданных этим ЦС. Это возможно?
Мне кажется, что «да», потому что, как я понимаю, доступ к соответствующему закрытому ключу необходим и достаточен для «полных полномочий» над идентификацией сертификата. То есть, если не существует какого-то одноразового номера, включенного вместе с открытым ключом в сертификат, когда он генерируется (вероятно).
Я все еще довольно плохо знаком с управлением сертификатами SSL, но я (кажется, я) понимаю основы стандартной цепочки доверия. Мне также нравится базовое использование других криптографических PKI: я управляю ключами SSH и использую GPG для подписи и шифрования. Я изучал информатику, хотя я только увлекаюсь криптографией.
Я никогда не делал CSR для оригинального IIRC (я думаю, что это был прямой вывод openssl req -new -x509). Конечно, у меня все еще есть оригинальный ключ CA, и с его помощью я смог «превратить» исходный сертификат в запрос на подпись сертификата:
openssl x509 -x509toreq -in MyCA.pem -out MyCA.csr -signkey private/MyCA.key
Я надеялся, что это эффективно «извлечет» одноразовый номер, упомянутый выше, и позволит мне воссоздать сертификат, но на этот раз с crlDistributionPointsполем, и, следовательно, все сертификаты, которые были подписаны с исходным ЦС, все равно будут проверяться на соответствие этому новому ЦС, за исключением что клиенты будут получать мой (в настоящее время пустой) файл CRL с URL-адреса HTTP, указанного в поле.
Итак, я сделал файл конфигурации расширения ext.conf:
[ cert_ext ]
subjectKeyIdentifier=hash
crlDistributionPoints=URI:http://security.mycompany.co.za/root.crl
И я создал новую версию корневого CA из CSR:
openssl x509 -extfile ./ext.conf -extensions cert_ext -req -signkey private/MyCA.key -in MyCA.csr -out MyNewCA.pem
Теперь, когда я смотрю сертификат с openssl x509 -text -in MyNewCA.pem | less
Я вижу часть расширения CRL:
X509v3 extensions:
X509v3 Subject Key Identifier:
82:D0:01:03:49:FF:30:16:FA:DC:0A:1E:C1:8C:3D:66:A1:78:FF:F8
X509v3 CRL Distribution Points:
Full Name:
URI:http://security.mycompany.co.za/root.crl`
Но увы! Мои ранее подписанные сертификаты больше не проверяют это:
openssl verify -verbose -CAfile MyCA.pem git.pem
git.pem: OK
openssl verify -verbose -CAfile MyNewCA.pem git.pem
git.pem: <redacted DN>
error 20 at 0 depth lookup:unable to get local issuer certificate
В основном я ищу больше информации о том, как работают сертификаты и почему. Но я также приветствовал бы решение проблемы, которая привела к этому, так что здесь также есть некоторая справочная информация.
Как я попал в этот беспорядок: HTTPS к внутренним сервисам прекрасно работает, когда мой CA установлен через Explorer RMB → Install Certificate GUI в Windows или /usr/local/share/ca-certificatesпосле него update-ca-certificatesв Debian и Ubuntu. Но недавно я столкнулся с исключением: Git в Windows, особенно если он установлен для использования Windows Secure Channel в качестве фонового соединения SSL. Который, по-видимому, по умолчанию настаивает на том, что в сертификатах SSL должно быть поле CRL.
Так что я предполагаю, что это действительно проблема безопасного канала Windows, потому что сообщение об ошибке, с которым я продолжаю сталкиваться, кажется полностью специфичным для Microsoft: fatal: unable to access 'https://angery@git.mycompany.co.za/gitblit/r/secret_project.git/': schannel: next InitializeSecurityContext failed: Unknown error (0x80092012) - The revocation function was unable to check revocation for the certificate.
Если я устанавливаю Git с OpenSSL и вручную соединяю свой CA с файлом, на который указывает git.http.sslcainfo, тогда он работает, но я боюсь, что мои пользователи будут склонны отказаться от проверки подлинности SSL, если они считают, что этот процесс требует больше усилий, чем щелкнув "простой" графический интерфейс установщика сертификатов Windows.
-x509toreqэто восстановит всю уникальную информацию из существующего корневого центра сертификации, но либо этого не произойдет, либо там что-то не так с моим процессом.
req -new -x509и x509 -req -signkeyоба по умолчанию используют серийный номер самоподписанного сертификата для случайного числа (хотя это может быть переопределено), фактически одноразовый номер. Если ваш дочерний сертификат (или любой из них) содержит AuthorityKeyIdentifier, использующий опцию «Issueer + Serial» (вместо или в дополнение к опции «KeyID»), что будет иметь место, если вы использовали caс исходным конфигурационным файлом по умолчанию, вы необходимо создать новый рут с тем же серийным номером, что и у старого; использовать -set_serial. ...