Ponowne wystawianie samopodpisanego głównego urzędu certyfikacji bez unieważniania podpisanych przez niego certyfikatów

Utworzyłem samopodpisany główny urząd certyfikacji dla kilku wewnętrznych usług w naszej firmie, które sam skonfigurowałem (głównie przez HTTPS). Następnie utworzyłem certyfikaty dla tych usług, podpisane tym urzędem certyfikacji.

Teraz chcę dodać rozszerzenie x509 (punkt dystrybucji CRL) do głównego urzędu certyfikacji bez unieważniania istniejących certyfikatów serwera wydanych z tego urzędu. czy to możliwe?

Moje przeczucie brzmi „tak”, ponieważ, jak rozumiem, dostęp do odpowiedniego klucza prywatnego jest konieczny i wystarczający do „pełnej władzy” nad tożsamością certyfikatu. To znaczy, chyba że do certyfikatu dołączony jest jakiś nonce wraz z kluczem publicznym podczas jego generowania (prawdopodobnie).

Nadal jestem całkiem nowy w zarządzaniu certyfikatami SSL, ale (myślę, że) rozumiem podstawy standardowego łańcucha zaufania. Czuję się swobodnie z podstawowym użyciem innych krypto PKI: zarządzam kluczami SSH i używam GPG do podpisywania i szyfrowania. Studiowałem informatykę, choć jestem samoukiem w dziedzinie kryptografii.

Nigdy nie stworzyłem CSR dla oryginalnego IIRC (myślę, że było to bezpośrednie wyjście openssl req -new -x509). Oczywiście nadal mam prywatny klucz oryginalnego urzędu certyfikacji i używając go udało mi się „odwrócić” oryginalny certyfikat na żądanie podpisania certyfikatu: openssl x509 -x509toreq -in MyCA.pem -out MyCA.csr -signkey private/MyCA.key

Miałem nadzieję, że to skutecznie „wyodrębni” nonce wspomnianą powyżej i pozwoli mi odtworzyć certyfikat, ale tym razem z crlDistributionPointspolem, a tym samym wszystkie certyfikaty podpisane oryginalnym urzędem certyfikacji będą nadal sprawdzane pod kątem tego nowego urzędu certyfikacji, z wyjątkiem klienci będą pobierać mój (obecnie pusty) plik CRL z adresu URL HTTP wskazanego w polu.

Zrobiłem więc plik konfiguracyjny rozszerzenia ext.conf:

[ cert_ext ] 
subjectKeyIdentifier=hash
crlDistributionPoints=URI:http://security.mycompany.co.za/root.crl

I wygenerowałem nową wersję głównego urzędu certyfikacji z CSR:

openssl x509 -extfile ./ext.conf -extensions cert_ext -req -signkey private/MyCA.key -in MyCA.csr -out MyNewCA.pem

Teraz kiedy przeglądam certyfikat za pomocą openssl x509 -text -in MyNewCA.pem | less

Widzę część rozszerzenia 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`

Ale niestety! Moje wcześniej podpisane certyfikaty nie są już sprawdzane względem tego:

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

Głównie szukam więcej wglądu w to, jak działają certyfikaty i dlaczego. Ale z zadowoleniem przyjmuję również rozwiązanie problemu, który do tego doprowadził, więc oto kilka podstawowych informacji.

Jak wpadłem w ten bałagan: HTTPS do usług wewnętrznych działa świetnie, gdy mój urząd certyfikacji jest instalowany za pomocą Eksploratora RMB → Zainstaluj GUI certyfikatu w systemie Windows, a /usr/local/share/ca-certificatesnastępnie update-ca-certificatesw Debianie i Ubuntu. Ale ostatnio natknąłem się na wyjątek: Git w systemie Windows, szczególnie jeśli jest zainstalowany, aby używać Windows Secure Channel jako zaplecza SSL. Co najwyraźniej domyślnie nalega, aby w certyfikatach SSL było pole CRL.

Sądzę więc, że to naprawdę problem z bezpiecznym kanałem systemu Windows, ponieważ komunikat o błędzie, z którym ciągle się spotykam, wydaje się całkowicie związany z Microsoft: fatal: unable to access 'https://[email protected]/gitblit/r/secret_project.git/': schannel: next InitializeSecurityContext failed: Unknown error (0x80092012) - The revocation function was unable to check revocation for the certificate.

Jeśli zainstaluję Git z OpenSSL i ręcznie połączę mój urząd certyfikacji z plikiem wskazanym przez git.http.sslcainfo, to zadziała, ale obawiam się, że moi użytkownicy nie będą skłonni rezygnować z weryfikacji tożsamości SSL, jeśli uznają, że ten proces jest bardziej pracochłonny niż klikając „łatwy” GUI instalatora certyfikatu systemu Windows.

Dwa certyfikaty są uważane za takie same, o ile nazwa podmiotu i klucz publiczny certyfikatów są zgodne.

Dlatego wszystko, co musisz zrobić, to ponownie użyć kluczy i upewnić się, że nazwa podmiotu w nowym certyfikacie jest taka sama jak stara. Następnie możesz zmienić dowolne inne pola i / lub rozszerzenia, a wynikowy certyfikat zostanie uznany za taki sam.

Na przykład utwórz plik konfiguracyjny 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

i zapisz jako np rootca.cnf. Upewnij się, że elementy [req_distinguished_name]są identyczne z elementami w oryginalnym certyfikacie głównego urzędu certyfikacji (jest to identyczna część nazwy podmiotu).

Następnie uruchom:

openssl req -new -x509 -key rootca.key -out MyNewCA.pem -config rootca.cnf

gdzie rootca.keyjest klucz prywatny użyty w oryginalnym certyfikacie (jest to identyczna część klucza publicznego / prywatnego).

Spowoduje to utworzenie MyNewCA.pem, które można sprawdzić za pomocą:

$ 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

Użyj tego nowego certyfikatu zamiast oryginału.

Możesz zmienić inne pola i rozszerzenia, takie jak okres ważności certyfikatu, ale pamiętaj, że tak naprawdę nie powinieneś mieć żadnych ograniczeń (innych niż basicConstraints = critical,CA:true) w certyfikacie głównego urzędu certyfikacji.

Po dalszych rozważań, Twój problem może być po prostu się do tego, że wymiana certyfikat root CA nie ma basicConstrainti ewentualnie keyUsagerozszerzenia. Może warto spróbować dodać te dwa rozszerzenia do ext.confpierwszego i przetestować wynikowy nowy certyfikat głównego urzędu certyfikacji przy użyciu -x509toreqopublikowanej metody.