Повторне видавання власного підпису root root без недійсних підписаних ним сертифікатів

Я створив авторизований сертифікат root для декількох внутрішніх служб в нашій компанії, який я налаштував сам (в основному обслуговувався через HTTPS). Тоді я створив сертифікати для цих служб, підписані з цією ЦА.

Тепер я хочу додати розширення x509 (точку розподілу CRL) до кореневого CA без недійсності існуючих сертифікатів сервера, виданих з цього CA. Чи можливо це?

Моє відчуття кишечника "так", тому що, як я розумію, доступ до відповідного приватного ключа необхідний і достатній для "повного повноваження" щодо посвідчення сертифікату. Тобто, якщо в сертифікаті під час генерування (ймовірно) не включено якесь поняття разом із відкритим ключем.

Я все ще досить новачок в управлінні сертифікатами SSL, але я (думаю, що я) розумію основи стандартного ланцюга довіри. Мені також подобається базове використання інших криптовалют PKI: я керую ключами SSH та використовую GPG для підписання та шифрування. Я вивчав комп’ютерні науки, хоч я лише криміналіст-самоучка.

Я ніколи не робив КСВ для оригінального 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 для внутрішніх служб чудово спрацьовує, коли мій ЦП встановлений через RMB Explorer → Встановити інтерфейс інтерфейсу сертифікатів у Windows, а /usr/local/share/ca-certificatesпотім update-ca-certificatesна Debian та Ubuntu. Але я нещодавно зіткнувся з винятком: Git в Windows, зокрема, якщо він встановлений, щоб використовувати захищений канал Windows як резервний 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 і вручну з'єднаю мій КА на файл, на який вказує 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]ідентичні елементам у вашому оригінальному сертифікаті Root 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сертифікату Root CA не повинно бути ніяких обмежень (крім ).

Після подальшого розгляду, ваша проблема може просто звестись до того, що ваш замінний сертифікат Root CA не має basicConstraintта, можливо, keyUsageрозширень. Можливо, варто спробувати додати ці два розширення до свого ext.confпершого та протестувати отриманий новий сертифікат Root CA, використовуючи -x509toreqметод, який ви опублікували.