AWS Client VPN: servercertifikat contra klientcertifikatets rolle

Et Client VPN-endepunkt har altid brug for et TLS-servercertifikat. Det er den identitet, det administrerede endepunkt fremviser, når en klient opretter forbindelse. Det er et andet objekt end de certifikater, individuelle klienter fremviser, når gensidig godkendelse er i brug. At blande de to sammen er den mest almindelige grund til, at en ellers korrekt ACM-opsætning stadig fejler ved den første forbindelse.

Her er en gennemgang fra konsollen og udad, i den rækkefølge en forbindelse faktisk gennemløber.

To roller, ét endepunkt

Endepunktet ejer en serveridentitet og eventuelt en måde at godkende klientidentiteter på. De konfigureres separat. Den ene afgør om klienten kan stole på tjenesten; den anden afgør, om tjenesten accepterer klienten.

Læs tabellen som tre uafhængige krav i stedet for som ét certifikat. Servercertifikatet og dets private nøgle bliver hos tjenesten. Et klientcertifikat og dets matchende private nøgle lever på enheden. CA-materialet er det, en verifikator bruger til at kontrollere kæden. Kun den midterste række hører nogensinde på en laptop.

Hvad ACM-servercertifikatet gør

Når du opretter endepunktet, skal servercertifikatet være tilgængeligt i ACM i samme region som endepunktet. Konsollen beder om en ARN, og den ARN skal kunne slås op der. ACM kan indeholde et certifikat, du har klargjort med domænevalidering, eller et du har importeret sammen med dets nøgle og kæde. Begge virker i denne rolle; de adskiller sig i fornyelse og i hvem der har den private nøgle.

Vælg den klargøringsvej, der passer til, hvem der kan forny certifikatet, ikke den der tilfældigvis producerede en fil, der ser gyldig ud.

Hvad gensidig godkendelse tilføjer

Valg af certifikatbaseret klientgodkendelse tilføjer et andet spørgsmål: hvilke klienter må overhovedet oprette forbindelse. Hver klient fremviser sit eget certifikat og beviser besiddelsen af den matchende private nøgle. Separate identiteter er det, der gør selektiv tilbagekaldelse mulig senere. At kopiere én klientnøgle til hver enhed kasserer den egenskab i stilhed, selv når servercertifikatet er skaffet perfekt.

Endepunktets godkendelsesmetode er et valg, ikke et universelt krav.

Active Directory og fødereret godkendelse besvarer det samme spørgsmål på andre måder. En opskrift med gensidige certifikater er ikke automatisk login-designet til de udrulninger, og server-TLS-verifikation bliver på plads uanset, hvordan brugeren lukkes ind.

Hvorfor den samme CA-ARN ikke er nøgledeling

AWS dokumenterer, at når server- og klientcertifikaterne er udstedt af samme CA, kan servercertifikatets ARN også bruges til valg af klientcertifikat. Den sætning handler om, hvilken kæde endepunktet stoler på til verifikation. Den beder ikke klienter om at bruge serverens private nøgle. En laptop har stadig brug for sit eget klientcertifikat og sin egen matchende nøgle.

Når klientens CA er en anden udsteder, er den dokumenterede vej at importere den CA til ACM og vælge den til klientrollen.

Før fejlen tilbage til et trin

Identificér, hvilket trin der fejler, før du udskifter noget. Hvis klienten afviser endepunktet, er server-ARN'en eller dens kæde den mistænkte. Hvis endepunktet afviser klienten, se på klientcertifikatet, dets udsteder og den valgte godkendelsesmetode. Hvis tunnelen kommer op, og trafikken stadig fejler, er du helt forbi certifikaterne.

Udskift ét objekt ad gangen, fordi at bytte begge ender på én gang genskaber den tvetydighed, du startede med.

Kontrollér også tjenestens understøttede nøglealgoritmer og krævede udvidelser for den specifikke rolle. Et certifikat, der opfylder kravene til et offentligt websted, er ikke bevis for, at alle identitetskrav for Client VPN er opfyldt.

Skriv ned, hvilken ARN hvert felt indeholder, hvilken CA der udstedte klientcertifikatet, og hvilken godkendelsesmetode endepunktet faktisk bruger. Tre linjer dokumentation gør den næste fornyelse til en opgave i stedet for en undersøgelse.