Wygaśnięcie i odnowienie certyfikatu głównego urzędu certyfikacji

96

W 2004 r. Utworzyłem mały urząd certyfikacji korzystający z OpenSSL w systemie Linux i proste skrypty zarządzania dostarczane z OpenVPN. Zgodnie ze wskazówkami, które wtedy znalazłem, ustawiłem okres ważności certyfikatu głównego urzędu certyfikacji na 10 lat. Od tego czasu podpisałem wiele certyfikatów dla tuneli OpenVPN, stron internetowych i serwerów poczty elektronicznej, z których wszystkie mają również okres ważności 10 lat (to może być źle, ale wtedy nie wiedziałem lepiej).

Znalazłem wiele przewodników na temat konfigurowania urzędu certyfikacji, ale tylko bardzo niewiele informacji na temat zarządzania nim, a w szczególności na temat tego, co należy zrobić po wygaśnięciu certyfikatu głównego urzędu certyfikacji, co nastąpi za jakiś czas w 2014 r. Mam więc następujące pytania:

  • Czy certyfikaty, których okres ważności wydłuża się po wygaśnięciu certyfikatu głównego urzędu certyfikacji, staną się nieważne, gdy ten ostatni wygaśnie, czy też będą nadal ważne (ponieważ zostały podpisane w okresie ważności certyfikatu urzędu certyfikacji)?
  • Jakie operacje są potrzebne do odnowienia certyfikatu głównego urzędu certyfikacji i zapewnienia płynnego przejścia po jego wygaśnięciu?
    • Czy mogę w jakiś sposób ponownie podpisać aktualny główny certyfikat CA z innym okresem ważności i przesłać nowo podpisany certyfikat do klientów, aby certyfikaty klientów pozostały ważne?
    • Czy też muszę zastąpić wszystkie certyfikaty klienta nowymi podpisanymi przez nowy certyfikat głównego urzędu certyfikacji?
  • Kiedy należy odnowić certyfikat głównego urzędu certyfikacji? Zbliża się termin wygaśnięcia lub rozsądny termin przed wygaśnięciem?
  • Jeśli odnowienie certyfikatu głównego urzędu certyfikacji stanie się poważnym zadaniem, co mogę teraz zrobić lepiej, aby zapewnić płynniejsze przejście przy następnym odnawianiu (oczywiście bez ustawienia okresu ważności na 100 lat)?

Sytuację komplikuje nieco fakt, że mój jedyny dostęp do niektórych klientów odbywa się przez tunel OpenVPN, który używa certyfikatu podpisanego przez bieżący certyfikat CA, więc jeśli będę musiał zastąpić wszystkie certyfikaty klienta, będę musiał skopiować nowe pliki do klienta, zrestartuj tunel, trzymaj kciuki i mam nadzieję, że pojawi się później.

Remy Blank
źródło

Odpowiedzi:

142

Utrzymanie tego samego klucza prywatnego w głównym urzędzie certyfikacji umożliwia dalsze sprawdzanie poprawności wszystkich certyfikatów względem nowego katalogu głównego; wszystko, czego potrzebujesz, to zaufać nowemu rootowi.

Relacja podpisywania certyfikatów opiera się na sygnaturze z klucza prywatnego; utrzymywanie tego samego klucza prywatnego (i domyślnie tego samego klucza publicznego) podczas generowania nowego certyfikatu publicznego, z nowym okresem ważności i wszelkimi innymi nowymi atrybutami zmienianymi w razie potrzeby, utrzymuje relację zaufania na miejscu. Listy CRL również mogą przechodzić ze starego certyfikatu do nowego, ponieważ są one, podobnie jak certyfikaty, podpisane przez klucz prywatny.


Sprawdźmy!

Utwórz główny urząd certyfikacji:

openssl req -new -x509 -keyout root.key -out origroot.pem -days 3650 -nodes

Wygeneruj z niego certyfikat podrzędny:

openssl genrsa -out cert.key 1024
openssl req -new -key cert.key -out cert.csr

Podpisz certyfikat dziecka:

openssl x509 -req -in cert.csr -CA origroot.pem -CAkey root.key -create_serial -out cert.pem
rm cert.csr

Wszystko ustawione, normalna relacja certyfikatu. Sprawdźmy zaufanie:

# openssl verify -CAfile origroot.pem -verbose cert.pem
cert.pem: OK

Ok, powiedzmy teraz, że minęło 10 lat. Wygenerujmy nowy certyfikat publiczny z tego samego głównego klucza prywatnego.

openssl req -new -key root.key -out newcsr.csr
openssl x509 -req -days 3650 -in newcsr.csr -signkey root.key -out newroot.pem
rm newcsr.csr

I .. czy to zadziałało?

# openssl verify -CAfile newroot.pem -verbose cert.pem
cert.pem: OK

Ale dlaczego? To różne pliki, prawda?

# sha1sum newroot.pem
62577e00309e5eacf210d0538cd79c3cdc834020  newroot.pem
# sha1sum origroot.pem
c1d65a6cdfa6fc0e0a800be5edd3ab3b603e1899  origroot.pem

Tak, ale to nie znaczy, że nowy klucz publiczny nie kryptograficznie pasuje do podpisu na certyfikacie. Różne numery seryjne, ten sam moduł:

# openssl x509 -noout -text -in origroot.pem
        Serial Number:
            c0:67:16:c0:8a:6b:59:1d
...
            RSA Public Key: (1024 bit)
                Modulus (1024 bit):
                    00:bd:56:b5:26:06:c1:f6:4c:f4:7c:14:2c:0d:dd:
                    3c:eb:8f:0a:c0:9d:d8:b4:8c:b5:d9:c7:87:4e:25:
                    8f:7c:92:4d:8f:b3:cc:e9:56:8d:db:f7:fd:d3:57:
                    1f:17:13:25:e7:3f:79:68:9f:b5:20:c9:ef:2f:3d:
                    4b:8d:23:fe:52:98:15:53:3a:91:e1:14:05:a7:7a:
                    9b:20:a9:b2:98:6e:67:36:04:dd:a6:cb:6c:3e:23:
                    6b:73:5b:f1:dd:9e:70:2b:f7:6e:bd:dc:d1:39:98:
                    1f:84:2a:ca:6c:ad:99:8a:fa:05:41:68:f8:e4:10:
                    d7:a3:66:0a:45:bd:0e:cd:9d
# openssl x509 -noout -text -in newroot.pem
        Serial Number:
            9a:a4:7b:e9:2b:0e:2c:32
...
            RSA Public Key: (1024 bit)
                Modulus (1024 bit):
                    00:bd:56:b5:26:06:c1:f6:4c:f4:7c:14:2c:0d:dd:
                    3c:eb:8f:0a:c0:9d:d8:b4:8c:b5:d9:c7:87:4e:25:
                    8f:7c:92:4d:8f:b3:cc:e9:56:8d:db:f7:fd:d3:57:
                    1f:17:13:25:e7:3f:79:68:9f:b5:20:c9:ef:2f:3d:
                    4b:8d:23:fe:52:98:15:53:3a:91:e1:14:05:a7:7a:
                    9b:20:a9:b2:98:6e:67:36:04:dd:a6:cb:6c:3e:23:
                    6b:73:5b:f1:dd:9e:70:2b:f7:6e:bd:dc:d1:39:98:
                    1f:84:2a:ca:6c:ad:99:8a:fa:05:41:68:f8:e4:10:
                    d7:a3:66:0a:45:bd:0e:cd:9d

Przejdźmy trochę dalej, aby sprawdzić, czy działa on w sprawdzaniu poprawności certyfikatów w świecie rzeczywistym.

Uruchom instancję Apache i spróbujmy (struktura pliku debian, dostosuj w razie potrzeby):

# cp cert.pem /etc/ssl/certs/
# cp origroot.pem /etc/ssl/certs/
# cp newroot.pem /etc/ssl/certs/
# cp cert.key /etc/ssl/private/

Ustawimy te dyrektywy na VirtualHostnasłuchiwanie na 443 - pamiętaj, że newroot.pemcertyfikat główny nawet nie istniał, kiedy cert.pemzostał wygenerowany i podpisany.

SSLEngine on
SSLCertificateFile /etc/ssl/certs/cert.pem
SSLCertificateKeyFile /etc/ssl/private/cert.key
SSLCertificateChainFile /etc/ssl/certs/newroot.pem

Sprawdźmy, jak widzi to openssl:

# openssl s_client -showcerts -CAfile newroot.pem -connect localhost:443

Certificate chain
 0 s:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=server.lan
   i:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=root
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
 1 s:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=root
   i:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=root
-----BEGIN CERTIFICATE-----
MIICHzCCAYgCCQCapHvpKw4sMjANBgkqhkiG9w0BAQUFADBUMQswCQYDVQQGEwJB
...
-----END CERTIFICATE-----
(this should match the actual contents of newroot.pem)
...
Verify return code: 0 (ok)

Ok, a co z przeglądarką korzystającą z kryptograficznego interfejsu API MS? Najpierw zaufaj rootowi, potem wszystko będzie dobrze, z numerem seryjnym nowego roota:

newroot

I powinniśmy nadal pracować ze starym rootem. Przełącz konfigurację Apache wokół:

SSLEngine on
SSLCertificateFile /etc/ssl/certs/cert.pem
SSLCertificateKeyFile /etc/ssl/private/cert.key
SSLCertificateChainFile /etc/ssl/certs/origroot.pem

Wykonaj pełny restart na Apache, przeładowanie nie przełączy poprawnie certyfikatów.

# openssl s_client -showcerts -CAfile origroot.pem -connect localhost:443

Certificate chain
 0 s:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=server.lan
   i:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=root
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
 1 s:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=root
   i:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=root
-----BEGIN CERTIFICATE-----
MIIC3jCCAkegAwIBAgIJAMBnFsCKa1kdMA0GCSqGSIb3DQEBBQUAMFQxCzAJBgNV
...
-----END CERTIFICATE-----
(this should match the actual contents of origroot.pem)
...
Verify return code: 0 (ok)

A dzięki przeglądarce MS crypto API Apache prezentuje stary katalog główny, ale nowy katalog główny nadal znajduje się w zaufanym magazynie głównym komputera. Automatycznie go znajdzie i zweryfikuje certyfikat względem zaufanego (nowego) katalogu głównego, mimo że Apache prezentuje inny łańcuch (stary katalog główny). Po usunięciu nowego katalogu głównego z zaufanych katalogów głównych i dodaniu oryginalnego certyfikatu głównego wszystko jest w porządku:

oldroot


Więc to jest to! Zachowaj ten sam klucz prywatny podczas odnawiania, zamień w nowym zaufanym katalogu głównym, a prawie wszystko działa . Powodzenia!

Shane Madden
źródło
2
W każdym razie, po co tworzyć nowy certyfikat główny, jeśli zamierzasz ponownie użyć tego samego klucza prywatnego? Jeśli ciągle to robisz w kółko, to po co w ogóle mieć datę ważności certyfikatu? Myślałem, że wygaśnięcie katalogu głównego zostało użyte, aby zmusić administratorów do stworzenia nowszego (najprawdopodobniej silniejszego) klucza prywatnego, który jest bardziej bezpieczny przed ciągle rozwijającymi się maszynami próbującymi złamać klucze. 40-bitowy klucz wykonany 20 lat temu nie jest wystarczająco bezpieczny dla
jvhashe
2
@jvhashe Jeśli certyfikat główny nie jest już wystarczająco silny pod względem kryptograficznym, powinieneś się go pozbyć niezależnie od daty jego ważności. Jeśli tworzysz swój własny korzeń, nic nie stoi na przeszkodzie, aby wygasł setki lat temu, kiedy już nie będziesz na planecie. Data wygaśnięcia jest mało istotna w przypadku certyfikatu głównego - w przypadku certyfikatu podrzędnego data wygaśnięcia nie dotyczy tak naprawdę siły kryptograficznej (zapytaj urzędy certyfikacji, które przygotowują się do odwołania wszystkich 1024-bitowych certyfikatów w październiku) - zobacz tutaj, aby uzyskać więcej informacji.
Shane Madden
3
Oprócz powyższego stwierdziłem, że numer seryjny musi być taki sam, aby ta metoda działała.
Scott Presnell,
2
-set_serial 01- WTF ??? NIE MOŻNA UŻYWAĆ NUMERÓW SERYJNYCH . Czy skonsultowałeś się nawet z RFC 4158, Internet X.509 Infrastruktura klucza publicznego: budowa ścieżki certyfikacji ? A może po prostu wymyślasz to na bieżąco? Nie masz pojęcia o problemach, które powodują agenty użytkownika, gdy zaczynają budować ścieżkę.
1
@jww Czy przeczytałeś odpowiedź? To tylko dowód na to, że kryptografia działa. To polecenie dosłownie generuje certyfikat testowy, który możemy później zweryfikować, w celu przetestowania relacji między starym i nowym certyfikatem głównym. Jeśli ktoś jest przy użyciu bezpośrednio te polecenia, mam nadzieję, coś łamie, i zdają sobie sprawę, że trzeba zwrócić uwagę na kontekst czegoś przed ślepo uruchomienie go (lub odlatują uchwyt o tym, czy 01jest dopuszczalne seryjny w laboratorium).
Shane Madden
14

Zauważyłem, że w odnowionym certyfikacie oryginalnego klucza CA może brakować rozszerzeń CA. To działało bardziej odpowiedni dla mnie (tworzy ./renewedselfsignedca.conf gdzie rozszerzenia v3 CA są zdefiniowane i ca.key i ca.crt są traktowane jako oryginalny klucz i certyfikat CA):

openssl x509 -x509toreq -in ca.crt -signkey ca.key -out renewedselfsignedca.csr
echo -e "[ v3_ca ]\nbasicConstraints= CA:TRUE\nsubjectKeyIdentifier= hash\nauthorityKeyIdentifier= keyid:always,issuer:always\n" > renewedselfsignedca.conf
openssl x509 -req -days 1095 -in renewedselfsignedca.csr -signkey ca.key -out renewedselfsignedca.crt -extfile ./renewedselfsignedca.conf -extensions v3_ca
Bianconiglio
źródło
2
To był niezwykle pomocny dodatek. Właściwie prawidłowa odpowiedź nie daje dla mnie wystarczająco kompatybilnego certyfikatu, jeśli masz dowolne ustawienia oryginalnego katalogu głównego.
Theuni
1
Oddelegowany, bardzo pomocny. Kolejny dodatek: podobnie jak Scott Presnell w komentarzach do zaakceptowanej odpowiedzi, musiałem ręcznie określić szesnastkowy numer seryjny odnowionego certyfikatu, aby pasował do starego. Oznaczało to dodanie -set_serial 0xdeadbeefabba(nie prawdziwego numeru seryjnego :)) do ostatniego polecenia x509. Dopiero wtedy moje certyfikaty klienta pomyślnie zweryfikowały na podstawie odnowionego certyfikatu CA.
JK Laiho
Ta metoda jest łatwiejsza, ponieważ zachowuje te same informacje, co poprzedni certyfikat.
Lepe
Stworzyłem skrypt dla tego rozwiązania plus -set_serial - patrz moja odpowiedź
Wolfgang Fahl
Ta odpowiedź pozwoliła mi zaoszczędzić mnóstwo pracy, po prawie dniu spędzonym na problemie, który tego wymagał, prawie miałem się poddać, daję ci za to kapelusz!
Onitlikesonic
2

Tryb podstawowy, aby przedłużyć prawidłowy okres rootowania (potrzebujesz publicznego X.509 i powiązanego klucza prywatnego):

Wygeneruj CSR z publicznego X.509 i klucza prywatnego:

openssl x509 -x509toreq -in XXX.crt -signkey XXX.key -out XXX.csr

Ponownie podpisz CSR kluczem prywatnym:

openssl x509 -in XXX.csr -out XXX.crt -signkey XXX.key -req -days 365
Grgrandes
źródło
1

@Bianconiglio plus -set_serial pracował dla mnie. Mój serwer jest tylko intranetowy, więc nie martwię się zbytnio o skutki uboczne i mam teraz czas, aby pracować nad „właściwym” rozwiązaniem.

Użyłem następującego konfigurowalnego skryptu. Wystarczy ustawić zmienne CACRT, CAKEY i NEWCA.

# WF 2017-06-30
# https://serverfault.com/a/501513/162693
CACRT=SnakeOilCA.crt
CAKEY=SnakeOilCA.key
NEWCA=SnakeOilCA2017
serial=`openssl x509 -in $CACRT -serial -noout | cut -f2 -d=`
echo $serial
openssl x509 -x509toreq -in $CACRT -signkey $CAKEY -out $NEWCA.csr
echo -e "[ v3_ca ]\nbasicConstraints= CA:TRUE\nsubjectKeyIdentifier= hash\nauthorityKeyIdentifier= keyid:always,issuer:always\n" > $NEWCA.conf
openssl x509 -req -days 3650 -in $NEWCA.csr -set_serial 0x$serial -signkey $CAKEY -out $NEWCA.crt -extfile ./$NEWCA.conf -extensions v3_ca
openssl x509 -in $NEWCA.crt -enddate -serial -noout
Wolfgang Fahl
źródło
0

Po wygaśnięciu certyfikatu głównego, podobnie jak certyfikaty, które z nim podpisałeś. Będziesz musiał wygenerować nowy certyfikat główny i podpisać nim nowe certyfikaty. Jeśli nie chcesz powtarzać tego procesu co kilka lat, jedyną realną opcją jest przedłużenie ważnej daty na certyfikacie root około dziesięciu lub dwudziestu lat: root, który wygenerowałem na własny użytek, wyznaczyłem dwadzieścia lat.

Nie można „odnowić” certyfikatu głównego. Wszystko, co możesz zrobić, to wygenerować nowy.

Wygeneruj nowy katalog główny co najmniej rok lub dwa przed wygaśnięciem starego, abyś miał czas na zmianę bez bycia chronionym przed upływem czasu, jeśli coś pójdzie nie tak. W ten sposób zawsze możesz tymczasowo powrócić do starych certyfikatów, dopóki problemy z ząbkowaniem nie zostaną rozwiązane.

Jeśli chodzi o tunele VPN, skonfigurowałbym kilka testowanych serwerów do eksperymentowania, abyś dokładnie wiedział, co musisz zrobić, zanim zrobisz to na komputerze klienta.

Snowhare
źródło
Ta odpowiedź wydaje się sugerować, że możliwe jest odnowienie certyfikatu głównego poprzez ponowne użycie jego klucza. Podejrzewam jednak, że nie różni się to niczym od zera, ponieważ nowy certyfikat będzie miał inny podpis, a zatem nie będzie sprawdzał poprawności istniejących certyfikatów klienta.
Remy Blank
tak, możesz przedłużyć ważny okres ... i jest to mniej pracy niż odtworzenie wszystkich pki, certyfikatów klienta i przeszukanie nowego katalogu głównego ...
ggrandes
Część dotycząca wydawania nowych certyfikatów podmiotów końcowych niekoniecznie musi być prawdziwa. Zależy to od tego, jak identyfikator klucza urzędu (AKID) jest reprezentowany w podległych urzędach certyfikacji i certyfikatach jednostek końcowych. Jeśli AKID opiera się na {Distinguished Name, Serial Number} , ciągłość zostanie osiągnięta. Zobacz także RFC 4518, Internet X.509 Infrastruktura klucza publicznego: Budowanie ścieżki certyfikacji .
0

Mieliśmy ten sam problem i tak było w naszym przypadku, ponieważ serwer Debiana był nieaktualny, a openSSL miał ten problem:

https://en.wikipedia.org/wiki/Year_2038_problem

Ostatnia wersja OpenSSL dostępna dla Debian 6 przynosi ten problem. Wszystkie certyfikaty utworzone po 23.01.2018 produkują rzeczywistość: na 1901 rok!

Rozwiązaniem jest aktualizacja OpenSSL. Możesz ponownie utworzyć pliki konfiguracyjne (z certyfikatami) dla klientów.

Manuel
źródło