Trzymaj główny CA VPN offline i nadal wydawaj certyfikaty

Twoja VPN odpowiada na połączenia o 3 w nocy, podczas gdy maszyna podpisująca jej certyfikaty stoi wyłączona w szufladzie. Klient weryfikujący certyfikat serwera nigdy nie kontaktuje się z Twoim CA, więc CA nie musi być osiągalny dla żadnego połączenia. Część, która wymaga planowania, to dzień, w którym certyfikat trzeba wydać, odnowić lub unieważnić podczas gdy klucz główny pozostaje pod zamkiem.

Co naprawdę weryfikuje połączenie

Gdy klient OpenVPN się łączy, przechodzi łańcuch podpisów od certyfikatu liścia serwera w górę do certyfikatu CA, któremu już ufa, sprawdza okno ważności i, jeśli profil tak mówi, zagląda do listy unieważnień. Nigdy nie szuka Twojego głównego CA. Serwer robi to samo w lustrzanym odbiciu dla certyfikatów klientów. W chwili połączenia obecne są tylko liść, certyfikat pośredni i pakiet zaufania rozdany wcześniej.

To, co naprawdę zawodzi, jest jedną z trzech rzeczy: klucz podpisujący jest niedostępny przy wydaniu, lista unieważnień jest przestarzała albo pakiet zaufania klienta jest starszy niż łańcuch przedstawiany przez serwer. Pierwsza to problem procesu; dwie pozostałe to problemy dystrybucji. Żadna z nich nie wymaga, by klucz główny był online, a zarządzana usługa VPN, która wymaga prywatnego certyfikatu do uwierzytelniania tunelu, tylko przenosi uprawnienia podpisywania do dostawcy. Azure punkt-lokalizacja działa odwrotnie: przesyłasz certyfikat główny i certyfikaty podpisane pod nim są uznawane za zaufane, więc pytaj, kto podpisuje, kto weryfikuje i jak certyfikat jest wycofywany wcześniej.

Zbuduj główny CA na hoście, który nigdy nie dostaje adresu

Główny CA offline używa się rzadko: do podpisania certyfikatu pośredniego CA, a później do jego odnowienia lub unieważnienia. Wszystko inne dzieje się o poziom niżej. Pracę z kluczem głównym wykonaj na maszynie trzymanej poza siecią, jeśli to możliwe z systemu live, i zapisz, kto był w pokoju. Polecenia zakładają OpenSSL 1.1.1 lub nowszy, ponieważ -addext nie występuje w starszych kompilacjach.

openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 -out root.key
openssl req -x509 -new -key root.key -sha256 -days 7300 \
  -subj "/CN=Example VPN Root CA" -out root.crt \
  -addext "basicConstraints=critical,CA:TRUE" \
  -addext "keyUsage=critical,keyCertSign,cRLSign"

Utwórz certyfikat pośredni na hoście podpisującym i zanieś tylko jego żądanie do maszyny offline. Główny CA podpisuje to żądanie z zerową długością ścieżki, więc pośredni CA może podpisywać certyfikaty końcowe, ale nie może utworzyć pod sobą kolejnego CA. To jedno rozszerzenie powstrzymuje przejętego hosta podpisującego przed stworzeniem uprawnienia równego głównemu. Używaj ECDSA tylko wtedy, gdy każdy klient działa na OpenVPN 2.4 lub nowszym; w przeciwnym razie wygeneruj klucze RSA i zachowaj ten sam przebieg.

openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 -out intermediate.key
openssl req -new -key intermediate.key -subj "/CN=Example VPN Intermediate CA" -out intermediate.csr
openssl x509 -req -in intermediate.csr -CA root.crt -CAkey root.key \
  -CAcreateserial -days 3650 -sha256 -extfile intermediate.ext -out intermediate.crt

intermediate.ext zawiera basicConstraints=critical,CA:TRUE,pathlen:0, keyUsage=critical,keyCertSign,cRLSign i authorityKeyIdentifier=keyid:always. Odłóż klucz główny do sejfu, zanim host podpisujący zostanie ponownie podłączony. Jeśli główny CA musi móc unieważnić certyfikat pośredni, podpisz go za pomocą openssl ca -config root.cnf -extensions intermediate_ca wobec index.txt na poziomie głównym zamiast openssl x509 -req, aby numer seryjny został zapisany; następnie wyślij wynikową listę główną w profilu klienta, gdzie oparty na pliku crl-verify odczytuje ją przy starcie. Wysyłaj klientom pakiet z oboma certyfikatami CA; sam liść nie zweryfikuje się wobec głównego.

Wydawaj liście z pośredniego CA, z bazą danych

Podpisywanie za pomocą openssl x509 -req działa do momentu, gdy trzeba unieważnić, ponieważ nic nie zapisuje numeru seryjnego. Użyj openssl ca od pierwszego certyfikatu, aby numer seryjny, termin ważności i stan unieważnienia żyły w jednej bazie danych. Utwórz pliki bazy danych raz, a następnie skieruj na nie konfigurację:

mkdir -p /etc/vpn-ca/intermediate/newcerts
touch /etc/vpn-ca/intermediate/index.txt
echo 1000 > /etc/vpn-ca/intermediate/serial
echo 1000 > /etc/vpn-ca/intermediate/crlnumber

[ ca ]
default_ca = CA_default
[ CA_default ]
dir = /etc/vpn-ca/intermediate
database = $dir/index.txt
new_certs_dir = $dir/newcerts
serial = $dir/serial
crlnumber = $dir/crlnumber
certificate = $dir/intermediate.crt
private_key = $dir/intermediate.key
default_md = sha256
default_days = 365
default_crl_days = 30
unique_subject = no
policy = policy_any
[ policy_any ]
commonName = supplied
[ server_cert ]
basicConstraints = CA:FALSE
keyUsage = critical, digitalSignature
extendedKeyUsage = serverAuth
subjectAltName = @server_names
[ client_cert ]
basicConstraints = CA:FALSE
keyUsage = critical, digitalSignature
extendedKeyUsage = clientAuth
[ server_names ]
DNS.1 = vpn.example.com

Wiersz użycia klucza zakłada klucz ECDSA; dodaj keyEncipherment dla RSA. Daj każdemu klientowi własną nazwę pospolitą, ponieważ OpenVPN identyfikuje połączenie po tym polu, a dwa laptopy współdzielące CN=vpn-client nie da się rozróżnić w logach, w regułach client-config-dir ani w żadnym pushu dla użytkownika, i tracisz przypisanie, które czyni decyzję o unieważnieniu obronną. Wydaj i zweryfikuj liść w ten sposób:

openssl req -new -key alice.key -subj "/CN=alice-laptop" -out alice.csr
openssl ca -config intermediate.cnf -extensions client_cert -in alice.csr -out alice.crt -batch
openssl verify -CAfile ca-bundle.crt -untrusted intermediate.crt alice.crt

Trzymaj klucz podpisujący za granicą polityki zamiast kopiować go na host VPN: mała usługa, która uwierzytelnia żądanie, sprawdza nazwę pospolitą wobec listy dozwolonych i zwraca tylko certyfikat. Zapisuj każdy numer seryjny; log jest jedynym ogniwem między certyfikatem a osobą, która o niego poprosiła.

Publikuj unieważnienia bez budzenia głównego CA

Certyfikaty klientów unieważnia pośredni CA, nigdy główny. Lista główna ma znaczenie tylko wtedy, gdy pośredni CA zostanie spalony. Skieruj serwer na listę pośrednią za pomocą crl-verify. CRL oparty na pliku jest wczytywany przy starcie usługi, więc wczytaj go ponownie po każdym odtworzeniu; forma katalogowa czyta stan w chwili połączenia i kosztuje jeden plik na numer seryjny.

Unieważnij i odtwórz dwoma poleceniami z tej samej bazy danych:

openssl ca -config intermediate.cnf -revoke /etc/vpn-ca/intermediate/newcerts/1001.pem
openssl ca -config intermediate.cnf -gencrl -out /etc/openvpn/crl.pem

Potem pilnuj zegara. CRL niesie pole następnej aktualizacji, a gdy ta data minie, weryfikujący partner odrzuca listę zamiast ją ignorować. Miesięczne odtwarzanie z default_crl_days = 30 zostawia zapas; roczne nie. Krótsze czasy życia liści to bardziej niezawodna kontrola, ponieważ unieważnienie działa tylko tam, gdzie lista jest sprawdzana.

Przetestuj łańcuch, a potem zapisz ceremonię

Odtwórz cztery awarie, zanim zaufasz projektowi. Zweryfikuj łańcuch za pomocą openssl verify -CAfile ca-bundle.crt -untrusted intermediate.crt server.crt. Połącz się z wygasłym certyfikatem klienta i potwierdź, że serwer go odrzuca. Unieważnij klienta testowego, wczytaj ponownie i potwierdź, że lista działa. Przesuń zegar hosta o dzień do przodu, ponieważ zły zegar może wydać i odrzucić certyfikaty, które gdzie indziej wyglądają na ważne.

Główny CA offline jest kontrolą tylko wtedy, gdy istnieje dokumentacja: dwie wskazane osoby do ceremonii, zapis każdego podpisanego numeru seryjnego, zaszyfrowana kopia zapasowa przechowywana oddzielnie od maszyny i test odtworzenia na izolowanym hoście. Podpisz zapasowy pośredni CA podczas tej samej ceremonii, aby martwy host podpisujący nie zmusił Cię do odblokowania głównego o północy.

Zanim uznasz to za gotowe, potwierdź pięć rzeczy: klucz główny nie jest na hoście sieciowym, klucz pośredni żyje tylko na hoście podpisującym, pakiet klienta zawiera oba certyfikaty CA, CRL ma przyszłą następną aktualizację i ktoś ma wpis w kalendarzu na każde wygaśnięcie w łańcuchu. Jeśli jednego brakuje, konfiguracja wyglądająca na offline jest po prostu nieudokumentowana.