Я создал самозаверяющий корневой центр сертификации для нескольких внутренних служб в нашей компании, который я настроил сам (в основном обслуживаемый через HTTPS). Затем я создал сертификаты для этих служб, подписанные этим ЦС.
Теперь я хочу добавить расширение 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
И я сгенерировал новую версию корневого центра сертификации из 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 для внутренних служб отлично работает, когда мой ЦС установлен через Проводник ПКМ → Установить графический интерфейс сертификата в 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.
Два сертификата считаются одинаковыми, пока Имя субъекта и Открытый ключ сертификатов совпадают.
Следовательно, все, что вам нужно сделать, это повторно использовать ключи и убедиться, что имя субъекта в новом сертификате такое же, как в старом. После этого вы можете изменить любые другие поля и / или расширения, и полученный сертификат будет считаться таким же.
Например, создайте файл конфигурации 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] идентичны тем, что указаны в исходном сертификате корневого центра сертификации (это идентичная часть имени субъекта).
Далее запускаем:
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 метод, который вы разместили.