Повторный выпуск самозаверяющего корневого центра сертификации без аннулирования подписанных им сертификатов
Я создал самоподписанный корневой центр сертификации для нескольких внутренних служб в нашей компании, который я настроил сам (в основном обслуживаемый через HTTPS). Затем я создал сертификаты для этих служб, подписанные этим ЦС.
Теперь я хочу добавить расширение x509 (точка распространения CRL) к корневому ЦС без аннулирования существующих сертификатов сервера, выпущенных этим ЦС. Возможно ли это?
Я интуитивно чувствую «да», потому что, как я понимаю, доступ к соответствующему закрытому ключу необходим и достаточен для «полной власти» над идентификацией сертификата. То есть, если только какой-то одноразовый номер не включен вместе с открытым ключом в сертификат при его генерации (вероятно).
Я все еще новичок в управлении сертификатами SSL, но я (кажется, я) понимаю основы стандартной цепочки доверия. Мне также комфортно базовое использование других криптовалют PKI: я управляю ключами SSH и использую GPG для подписи и шифрования. Я изучал информатику, хотя я просто любитель криптографии-самоучка.
Я никогда не делал CSR для исходного IIRC (я думаю, что это был прямой результат openssl req -new -x509 ]). Конечно, у меня все еще есть оригинальный закрытый ключ CA, и с его помощью я смог "перевернуть" исходный сертификат в запрос на подпись сертификата:
Я никогда не делал CSR для исходного IIRC (я думаю, что это был прямой вывод openssl req -new -x509 ). Конечно, у меня все еще есть оригинальный закрытый ключ CA, и с его помощью я смог "перевернуть" исходный сертификат в запрос на подпись сертификата:
Я никогда не делал 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 → Установите графический интерфейс сертификата в Windows или / usr / local / share / ca-сертификаты , а затем update-ca-сертификаты в Debian и Ubuntu. Но недавно я столкнулся с исключением: Git в Windows, особенно если он установлен для использования Windows Secure Channel в качестве серверной части SSL. Который, по-видимому, по умолчанию настаивает на том, что в сертификатах SSL должно быть поле CRL.
Так что я думаю, что это 'angery@git.mycompany.co.za /gitblit/r/secret_project.git/ ': schannel: next Ошибка инициализацииSecurityContext: Неизвестная ошибка (0x80092012) - функции отзыва не удалось проверить отзыв сертификата.
Если я установил Git с OpenSSL и вручную объедините мой CA с файлом, на который указывает git.http.sslcainfo, тогда он работает, но я боюсь, что мои пользователи будут склонны отказываться от проверки подлинности SSL, если они считают, что этот процесс требует больше усилий, чем щелкнуть "простой" графический интерфейс установщика сертификатов Windows.
Два сертификата считаются одинаковыми, если совпадают Имя субъекта и Открытый ключ сертификатов.
Таким образом, все вы необходимо повторно использовать ключи и убедиться, что имя субъекта в новом сертификате такое же, как в старом. После этого вы можете изменить любое из других полей и / или расширений, и полученный сертификат будет считаться таким же.
Например, создайте файл конфигурации OpenSSL:
[ req ]
prompt = no
string_mask = default
distinguished_name = x509_distinguished_name
x509_extensions = x509_ext
[ x509_distinguished_name ]
# Note that the following are in 'reverse order' to what you'd expect to see.
# Adjust for your setup:
countryName = za
organizationName = My Company
organizationalUnitName = Security
commonName = My Root CA
[ x509_ext ]
basicConstraints = critical,CA:true
keyUsage = critical, keyCertSign, cRLSign
subjectKeyIdentifier = hash
crlDistributionPoints = URI:http://security.mycompany.co.za/root.crl
и сохраните его, например, как rootca.cnf . Убедитесь, что элементы [req_distinguished_name] идентичны элементам в вашем исходном сертификате корневого CA (это идентичная часть имени субъекта).
Затем запустите:
openssl req -new -x509 -key rootca.key -out MyNewCA.pem -config rootca.cnf
где rootca.key - это закрытый ключ, используемый в исходном сертификате (это идентичная часть открытого / закрытого ключа).
Это создает MyNewCA.pem , который вы можете проверить с помощью:
$ openssl x509 -noout -text -in MyNewCA.pem
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 17564687072266118846 (0xf3c24dd49d5166be)
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=za, O=My Company, OU=Security, CN=My Root CA
Validity
Not Before: Jul 15 05:05:54 2017 GMT
Not After : Aug 14 05:05:54 2017 GMT
Subject: C=za, O=My Company, OU=Security, CN=My Root CA
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:c8:3d:32:8a:56:31:f6:27:1a:ce:9e:b2:1d:fb:
ce:9f:ce:5b:42:25:aa:fe:8b:f4:34:32:ac:b3:02:
50:71:f8:c3:43:0c:c7:2c:9f:fe:48:1b:c6:c0:e7:
d6:44:a9:e7:d7:a0:7e:58:f4:b6:38:61:7e:d0:af:
0f:56:21:e7:49:7a:66:13:f5:7a:fe:3d:ab:65:f8:
01:eb:52:a7:3b:ae:a0:cf:50:57:b9:e0:09:0b:1f:
90:14:fb:18:56:1d:57:99:a9:76:a2:63:d1:c2:d3:
a3:f4:3a:ff:91:0d:ee:8d:44:13:58:00:09:93:da:
e8:6a:fd:64:5f:c3:42:8e:2a:49:6e:0d:73:b7:b9:
d4:6c:c6:ce:30:c5:82:24:a5:00:37:17:a0:1d:f1:
c9:e9:e3:18:48:22:4f:33:96:a7:3c:a9:31:f1:3f:
14:40:6a:74:e8:78:82:45:04:d4:4b:56:0b:cd:be:
48:8d:03:fb:39:70:0b:91:99:70:06:bd:5e:8b:f2:
d1:f4:6f:fc:ce:e7:f8:3c:0a:20:ea:35:b8:5f:2f:
ee:8d:ff:d3:93:85:6b:fb:71:db:1b:e6:e9:1d:a7:
f8:e4:ae:f4:71:fe:35:a7:89:24:af:69:a4:34:3b:
14:66:05:02:5e:2a:1d:ac:e0:d2:48:6c:13:4e:75:
58:93
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints: critical
CA:TRUE
X509v3 Key Usage: critical
Certificate Sign, CRL Sign
X509v3 Subject Key Identifier:
3B:45:93:3A:2A:BC:39:29:36:13:6C:BD:B6:B4:31:C7:E7:BB:32:73
X509v3 CRL Distribution Points:
Full Name:
URI:http://security.mycompany.co.za/root.crl
Signature Algorithm: sha256WithRSAEncryption
4d:96:d4:03:4f:e3:7c:26:be:59:f8:23:87:60:f7:4c:d3:a1:
1c:77:a1:14:e3:e7:da:c8:2a:a3:1b:06:2a:4d:55:1c:83:26:
73:46:0d:8a:e4:b7:d1:1e:38:cc:78:90:00:01:b3:8e:f9:3c:
62:be:04:09:90:4e:22:87:b1:aa:bd:f9:73:bd:a7:76:ad:d5:
ae:2d:7a:1c:1e:1a:67:c8:57:4c:f9:6d:8b:62:d6:e5:ea:e0:
40:5c:12:28:7e:ea:f0:0c:d6:cd:f4:1d:d5:56:09:ad:43:b4:
eb:8c:68:ce:56:a2:a8:ae:a4:d5:35:bb:58:b8:ed:82:82:b5:
ef:cb:e2:6d:76:61:ed:ee:a5:1f:68:95:07:ed:5b:f0:65:92:
d2:dc:1d:c6:fa:7f:e0:c9:38:c2:c6:6f:03:38:e7:3a:b0:24:
06:e0:bc:07:dd:e7:a0:dc:74:09:e5:37:7b:66:e1:6f:47:4c:
71:ff:02:48:7f:d4:4f:ce:cb:91:e9:ee:cd:b6:f1:0a:03:19:
3e:19:05:7d:8f:48:e7:f1:cc:07:37:3d:91:3c:6f:54:71:3c:
a2:6c:55:c3:03:c1:7f:eb:9e:70:f1:8f:a1:fb:62:33:8b:86:
2c:79:bc:76:e2:01:9a:68:df:af:40:a1:b2:9c:f6:a1:e1:6e:
2a:dd:1a:d6
Используйте этот новый сертификат вместо оригинала.
Вы можете изменить другие поля и расширения, например срок действия сертификата, но имейте в виду, что на самом деле у вас не должно быть никаких ограничений (кроме basicConstraints = critical, CA: true ) в сертификате корневого ЦС.
После дальнейшего рассмотрения ваша проблема может быть просто связана с тем, что замещающий сертификат корневого ЦС не имеет basicConstraint ] и, возможно, расширения keyUsage . Возможно, стоит попробовать сначала добавить эти два расширения в ваш ext.conf и протестировать получившийся новый сертификат корневого центра сертификации, используя опубликованный вами метод -x509toreq .