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

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.

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:

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:

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!

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

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

@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

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.

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.