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://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.
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.
-x509toreqto odzyska wszystkie unikalne informacje z istniejącego głównego urzędu certyfikacji, ale albo nie, albo coś jest nie tak z moim procesem.
req -new -x509i x509 -req -signkeyoba domyślnie szeregują samopodpisany certyfikat na losową liczbę (chociaż można to zastąpić), w rzeczywistości nonce. Jeśli twoje dziecko cert (lub którykolwiek z nich) zawiera AuthorityKeyIdentifier przy użyciu opcji „wystawca + numer seryjny” (zamiast lub oprócz opcji „keyid”), co będzie miało miejsce w przypadku użycia caz domyślnym plikiem konfiguracyjnym w górę, musisz utworzyć nowy katalog główny z tym samym numerem seryjnym, co stary; użyć -set_serial. ...