Sam CSR nie jest rejestracją: co musi sprawdzić CA VPN

Wniosek o podpis certyfikatu zawiera klucz publiczny i żądany subject, podpisane pasującym kluczem prywatnym. Ten podpis dowodzi, że wnioskujący ma klucz. Nie dowodzi, że ma prawo do żądanej nazwy, urządzenia lub roli w VPN, a traktowanie wniosku tak, jakby to dowodził, jest właśnie tym, jak zgłoszenie do pomocy technicznej staje się nadaniem dostępu.

Dwa modele rejestracji warto porównać według tego, co wiążą, a nie według tego, jakim protokołem mówią.

Wniosek twierdzi nazwę, ale jej nie dowodzi

Czytaj wniosek według tego, co naprawdę zawiera: klucz publiczny, wybrany przez wnioskującego subject i podpis własny nad oboma. Nic w tej strukturze nie odwołuje się do twojego spisu, katalogu kont ani procesu zatwierdzania. Subject taki jak cn=finance-laptop to ciąg znaków, który ktoś wpisał. Dopóki proces wydawania nie sprawdzi tego ciągu względem zaufanego rekordu, certyfikat jest twierdzeniem z dołączonym podpisem. Ta różnica to cały powód istnienia procesu rejestracji.

Konsekwencja ma znaczenie operacyjne. Urząd certyfikacji nigdy nie potrzebuje klucza prywatnego klienta, aby wydać certyfikat, a proces, który o niego prosi, pomylił podpisywanie z przechowywaniem kluczy. Zostaw generowanie na punkcie końcowym i wysyłaj tylko połowę publiczną.

Porównaj modele według tego, co wiążą

Ręczne podpisywanie wiąże to, co operator pamięta, że ma sprawdzić. Zautomatyzowana usługa rejestracji wiąże uwierzytelniony wniosek z decyzją, którą usługa może wyegzekwować, a RFC 7030 opisuje jeden taki projekt, w którym klient uwierzytelnia się, zanim certyfikat zostanie zwrócony. Różnica, która przetrwa audyt, to nie automatyzacja; to, czy kontrola tożsamości odbywa się w ścieżce wydawania, czy obok niej.

Oba modele nadal muszą odpowiedzieć na te same trzy pytania. Kto pyta, na jakim urządzeniu lub w jakiej roli i na jak długo. System zgłoszeń, który zapisuje odpowiedzi, wykonuje prawdziwą pracę; kolejka, w której ktoś wpatruje się w nazwę zwyczajową, nie, niezależnie od tego, jak starannie certyfikat zostanie później sformatowany.

Wybierz model według oczekiwanej liczby rejestracji i rotacji urządzeń. Kilka serwerów rocznie przetrwa ręczny przegląd z pisemną listą kontrolną. Flota laptopów nie.

Zapisz cykl życia od pierwszego wydania

Zapisz identyfikator certyfikatu, właściciela, zamierzone użycie, termin ważności i ścieżkę usunięcia w momencie wydania, a nie przy pierwszym incydencie. Zamierzone użycie należy do samego certyfikatu poprzez rozszerzone użycie klucza, a rekord powinien być z nim zgodny. Certyfikat utworzony do uwierzytelniania klientów nie powinien być nieodróżnialny od certyfikatu dla serwera.

Zaplanuj odnowienie i unieważnienie zagubionego urządzenia, zanim wydasz dziesiąty profil. Certyfikat współdzielony w całym dziale zamienia ukierunkowane usunięcie w awarię, a tę decyzję znacznie taniej przejrzeć teraz niż podczas piątkowego incydentu.

Sprawdź wydany certyfikat, potem dostęp

Po rejestracji sprawdź, co zostało wydane, i potwierdź, że łańcuch prowadzi do oczekiwanego urzędu. Dwie komendy pokrywają typowe błędy: certyfikat z niewłaściwym użyciem oraz łańcuch, który działa tylko dlatego, że klient jest skonfigurowany do ignorowania walidacji.

openssl req -in client.csr -noout -verify -subject
openssl x509 -in client.crt -noout -subject -issuer -dates -ext extendedKeyUsage
openssl verify -CAfile ca.crt client.crt

Potem testuj dostęp, a nie artefakt. Certyfikat ustala tożsamość, a polityka nadal decyduje, do których usług ta tożsamość może dotrzeć. Sprawdź jedno i drugie, bo poprawny artefakt z nazbyt szeroką polityką również nie przechodzi przeglądu. Potwierdź, że klient się uwierzytelnia i otrzymuje tylko zamierzone trasy lub zasoby. Zapisz to, co zaobserwowałeś, a nie to, co profil miał robić.

Profil, który działa z niewłaściwego powodu, na przykład pasująca nazwa zwyczajowa i brak kontroli tożsamości, będzie nadal działał po usunięciu kontroli, którą uważałeś, że masz.