AWS Client VPN: certifikát serveru versus role klientského certifikátu
Certifikát serveru endpointu prokazuje službu. Vzájemné ověřování přidává identity jednotlivých klientů a důvěru v CA, aniž by sdílelo klíč serveru.
Endpoint Client VPN vždy potřebuje TLS certifikát serveru. To je identita, kterou spravovaný endpoint předkládá, když se klient připojuje. Je to jiný objekt než certifikáty, které předkládají jednotliví klienti při vzájemném ověřování. Záměna těchto dvou věcí je nejčastějším důvodem, proč jinak správné nastavení ACM stále selže při prvním připojení.
Následuje průchod z konzole směrem ven, v pořadí, kterým připojení skutečně prochází.
Dvě role, jeden endpoint
Endpoint vlastní identitu serveru a volitelně způsob, jak ověřovat identity klientů. To se konfiguruje odděleně. Jedno rozhoduje o tom, zda klient může službě důvěřovat; druhé rozhoduje o tom, zda služba přijme klienta.
| Material | Purpose | Where it lives |
|---|---|---|
| Server certificate and private key | The managed endpoint proves its TLS identity | ACM, in the endpoint's Region |
| Client certificate and matching key | An individual client proves its identity | On the device |
| CA trust material | The verifier checks the issuer chain | Selected for the client role |
Čtěte tabulku jako tři nezávislé požadavky, nikoli jako jeden certifikát. Certifikát serveru a jeho soukromý klíč zůstávají u služby. Klientský certifikát a odpovídající soukromý klíč žijí na zařízení. Materiál CA je to, co ověřovatel používá ke kontrole řetězce. Na notebook patří vždy jen prostřední řádek.
Co dělá certifikát serveru v ACM
Při vytváření endpointu musí být certifikát serveru dostupný v ACM ve stejné oblasti jako endpoint. Konzole žádá ARN a tento ARN tam musí být rozpoznatelný. ACM může obsahovat certifikát, který jste zřídili s ověřením domény, nebo ten, který jste importovali spolu s klíčem a řetězcem. Oba v této roli fungují; liší se v obnově a v tom, kdo drží soukromý klíč.
Zvolte cestu zřízení podle toho, kdo může certifikát obnovovat, ne podle toho, která náhodou vytvořila platně vypadající soubor.
Co přidává vzájemné ověřování
Výběr ověřování klienta na základě certifikátů přidává druhou otázku: kteří klienti se vůbec smějí připojit. Každý klient předkládá svůj vlastní certifikát a prokazuje vlastnictví odpovídajícího soukromého klíče. Právě oddělené identity umožňují později selektivní odvolání. Kopírování jednoho klientského klíče na každé zařízení tuto vlastnost tiše zahodí, i když byl certifikát serveru získán bezchybně.
Metoda ověřování endpointu je volba, ne univerzální požadavek.
Active Directory a federované ověřování odpovídají na stejnou otázku jinými prostředky. Recept se vzájemným certifikátem není automaticky návrhem přihlašování pro tato nasazení a ověřování TLS na straně serveru zůstává bez ohledu na to, jak je uživatel vpuštěn.
Proč stejný ARN CA není sdílení klíčů
AWS dokumentuje, že pokud jsou certifikát serveru a klientský certifikát vydány stejnou CA, lze ARN certifikátu serveru použít i pro výběr klientského certifikátu. Ta věta je o tom, kterému řetězci endpoint důvěřuje při ověřování. Neříká klientům, aby používali soukromý klíč serveru. Notebook stále potřebuje svůj vlastní klientský certifikát a svůj vlastní odpovídající klíč.
Když je CA klienta jiný vydavatel, dokumentovaná cesta je importovat tuto CA do ACM a vybrat ji pro roli klienta.
Dohledejte selhání zpět k fázi
Než něco nahradíte, určete, která fáze selhává. Pokud klient odmítá endpoint, podezřelý je ARN serveru nebo jeho řetězec. Pokud endpoint odmítá klienta, podívejte se na klientský certifikát, jeho vydavatele a zvolenou metodu ověřování. Pokud tunel naskočí a provoz stále selhává, jste už mimo certifikáty.
Nahrazujte jeden objekt po druhém, protože výměna obou konců najednou reprodukuje nejednoznačnost, se kterou jste začali.
Zkontrolujte také podporované algoritmy klíčů a požadovaná rozšíření služby pro konkrétní roli. Certifikát, který vyhovuje veřejnému webu, není důkazem, že jsou splněny všechny požadavky na identitu Client VPN.
Zapište, který ARN drží každé pole, která CA vydala klientský certifikát a kterou metodu ověřování endpoint skutečně používá. Tři řádky záznamu promění příští obnovu v úkol místo vyšetřování.