AWS Client VPN: certyfikat serwera a rola certyfikatu klienta

Punkt końcowy Client VPN zawsze potrzebuje certyfikatu TLS serwera. To tożsamość, którą zarządzany punkt końcowy przedstawia, gdy klient się łączy. To inny obiekt niż certyfikaty przedstawiane przez poszczególnych klientów przy wzajemnym uwierzytelnianiu. Pomylenie tych dwóch rzeczy to najczęstsza przyczyna, dla której skądinąd poprawna konfiguracja ACM nadal zawodzi przy pierwszym połączeniu.

Oto przejście od konsoli na zewnątrz, w kolejności, w jakiej połączenie rzeczywiście przebiega.

Dwie role, jeden punkt końcowy

Punkt końcowy ma tożsamość serwera i opcjonalnie sposób weryfikacji tożsamości klientów. Te elementy konfiguruje się osobno. Jeden decyduje, czy klient może zaufać usłudze; drugi decyduje, czy usługa akceptuje klienta.

Czytaj tabelę jako trzy niezależne wymagania, a nie jako jeden certyfikat. Certyfikat serwera i jego klucz prywatny pozostają przy usłudze. Certyfikat klienta i pasujący klucz prywatny znajdują się na urządzeniu. Materiał CA to to, czym weryfikator sprawdza łańcuch. Tylko środkowy wiersz kiedykolwiek należy do laptopa.

Co robi certyfikat serwera ACM

Podczas tworzenia punktu końcowego certyfikat serwera musi być dostępny w ACM w tym samym regionie co punkt końcowy. Konsola prosi o ARN i ten ARN musi się tam rozwiązywać. ACM może przechowywać certyfikat udostępniony z walidacją domeny albo ten zaimportowany razem z kluczem i łańcuchem. Oba działają w tej roli; różnią się odnawianiem i tym, kto ma klucz prywatny.

Wybierz ścieżkę udostępniania odpowiadającą temu, kto może odnowić certyfikat, a nie tę, która przypadkiem dała poprawnie wyglądający plik.

Co dodaje wzajemne uwierzytelnianie

Wybór uwierzytelniania klienta opartego na certyfikatach dodaje drugie pytanie: którzy klienci mogą się w ogóle łączyć. Każdy klient przedstawia własny certyfikat i dowodzi posiadania pasującego klucza prywatnego. To właśnie osobne tożsamości umożliwiają później selektywne unieważnienie. Kopiowanie jednego klucza klienta na każde urządzenie po cichu odrzuca tę właściwość, nawet gdy certyfikat serwera uzyskano bezbłędnie.

Metoda uwierzytelniania punktu końcowego jest wyborem, a nie uniwersalnym wymogiem.

Active Directory i uwierzytelnianie federacyjne odpowiadają na to samo pytanie innymi środkami. Przepis z wzajemnym certyfikatem nie jest automatycznie projektem logowania dla tych wdrożeń, a weryfikacja TLS serwera pozostaje niezależnie od tego, jak użytkownik jest wpuszczany.

Dlaczego ten sam ARN CA nie jest udostępnianiem kluczy

AWS dokumentuje, że gdy certyfikaty serwera i klienta wystawia ta sama CA, ARN certyfikatu serwera można również użyć do wyboru certyfikatu klienta. To zdanie dotyczy tego, któremu łańcuchowi punkt końcowy ufa podczas weryfikacji. Nie mówi klientom, aby używali klucza prywatnego serwera. Laptop nadal potrzebuje własnego certyfikatu klienta i własnego pasującego klucza.

Gdy CA klienta jest innym wystawcą, udokumentowaną ścieżką jest zaimportowanie tej CA do ACM i wybranie jej dla roli klienta.

Cofnij awarię do etapu

Zanim cokolwiek wymienisz, ustal, który etap zawodzi. Jeśli klient odrzuca punkt końcowy, podejrzany jest ARN serwera lub jego łańcuch. Jeśli punkt końcowy odrzuca klienta, sprawdź certyfikat klienta, jego wystawcę i wybraną metodę uwierzytelniania. Jeśli tunel się podnosi, a ruch nadal zawodzi, jesteś już poza certyfikatami.

Wymieniaj jeden obiekt naraz, ponieważ zamiana obu końców jednocześnie odtwarza niejednoznaczność, od której zacząłeś.

Sprawdź też obsługiwane algorytmy kluczy i wymagane rozszerzenia usługi dla konkretnej roli. Certyfikat spełniający wymagania publicznej witryny nie jest dowodem, że spełniono wszystkie wymagania tożsamości Client VPN.

Zapisz, który ARN zawiera każde pole, która CA wystawiła certyfikat klienta i której metody uwierzytelniania punkt końcowy faktycznie używa. Trzy linie zapisu zamieniają kolejne odnawianie w zadanie, a nie w dochodzenie.