Повторная выдача самозаверяющего корневого ЦС без аннулирования сертификатов, подписанных им

Я создал самозаверяющий корневой центр сертификации для нескольких внутренних служб в нашей компании, который я настроил сам (в основном обслуживаемый по 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.

Два сертификата считаются одинаковыми, если совпадают имя субъекта и открытый ключ сертификатов.

Поэтому все, что вам нужно сделать, это повторно использовать ключи и убедиться, что имя субъекта в новом сертификате совпадает со старым. После этого вы можете изменить любые другие поля и / или расширения, и полученный сертификат будет считаться тем же.

Например, создайте файл конфигурации 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метод, который вы опубликовали.