AWS Client VPN: servercertifikat kontra klientcertifikatets roll

En Client VPN-slutpunkt behöver alltid ett TLS-servercertifikat. Det är den identitet som den hanterade slutpunkten visar upp när en klient ansluter. Det är ett annat objekt än de certifikat som enskilda klienter visar upp när ömsesidig autentisering används. Att blanda ihop de två är den vanligaste orsaken till att en i övrigt korrekt ACM-konfiguration ändå misslyckas vid den första anslutningen.

Här följer en genomgång från konsolen och utåt, i den ordning en anslutning faktiskt passerar.

Två roller, en slutpunkt

Slutpunkten äger en serveridentitet och, valfritt, ett sätt att verifiera klientidentiteter. Dessa konfigureras separat. Den ena avgör om klienten kan lita på tjänsten; den andra avgör om tjänsten accepterar klienten.

Läs tabellen som tre oberoende krav i stället för som ett enda certifikat. Servercertifikatet och dess privata nyckel stannar hos tjänsten. Ett klientcertifikat och dess matchande privata nyckel finns på enheten. CA-materialet är det som en verifierare använder för att kontrollera kedjan. Bara den mellersta raden hör någonsin hemma på en laptop.

Vad ACM-servercertifikatet gör

När du skapar slutpunkten måste servercertifikatet finnas i ACM i samma region som slutpunkten. Konsolen frågar efter ett ARN, och det ARN:et måste kunna slås upp där. ACM kan innehålla ett certifikat som du har anskaffat med domänvalidering, eller ett som du har importerat tillsammans med dess nyckel och kedja. Båda fungerar i den här rollen; de skiljer sig i förnyelse och i vem som har den privata nyckeln.

Välj den anskaffningsväg som passar den som kan förnya certifikatet, inte den som råkade producera en giltigt utseende fil.

Vad ömsesidig autentisering lägger till

Att välja certifikatbaserad klientautentisering lägger till en andra fråga: vilka klienter som alls får ansluta. Varje klient visar upp sitt eget certifikat och bevisar innehav av den matchande privata nyckeln. Separata identiteter är det som gör selektiv återkallelse möjlig senare. Att kopiera en klientnyckel till varje enhet kastar tyst bort den egenskapen, även när servercertifikatet har anskaffats perfekt.

Slutpunktens autentiseringsmetod är ett val, inte ett universellt krav.

Active Directory och federerad autentisering besvarar samma fråga på andra sätt. Ett recept med ömsesidiga certifikat är inte automatiskt inloggningsdesignen för dessa distributioner, och serverns TLS-verifiering ligger kvar oavsett hur användaren släpps in.

Varför samma CA-ARN inte är nyckeldelning

AWS dokumenterar att när server- och klientcertifikaten har utfärdats av samma CA kan servercertifikatets ARN även användas för valet av klientcertifikat. Den meningen handlar om vilken kedja slutpunkten litar på vid verifiering. Den säger inte till klienter att använda serverns privata nyckel. En laptop behöver fortfarande sitt eget klientcertifikat och sin egen matchande nyckel.

När klientens CA är en annan utfärdare, är den dokumenterade vägen att importera den CA:n till ACM och välja den för klientrollen.

Spåra felet tillbaka till ett steg

Ta reda på vilket steg som misslyckas innan du byter ut något. Om klienten avvisar slutpunkten är serverns ARN eller dess kedja den misstänkta. Om slutpunkten avvisar klienten, titta på klientcertifikatet, dess utfärdare och den valda autentiseringsmetoden. Om tunneln kommer upp och trafiken fortfarande misslyckas har du passerat certifikaten.

Byt ut ett objekt i taget, eftersom att byta båda ändarna samtidigt återskapar den tvetydighet du började med.

Kontrollera också tjänstens stödda nyckelalgoritmer och nödvändiga tillägg för den specifika rollen. Ett certifikat som uppfyller kraven för en offentlig webbplats är inget bevis för att alla identitetskrav för Client VPN är uppfyllda.

Skriv ned vilket ARN varje fält innehåller, vilken CA som utfärdade klientcertifikatet och vilken autentiseringsmetod slutpunkten faktiskt använder. Tre rader dokumentation gör nästa förnyelse till en uppgift i stället för en utredning.