AWS Client VPN: servercertifikat kontra klientcertifikatets rolle

Et Client VPN-endepunkt trenger alltid et TLS-servercertifikat. Det er identiteten det administrerte endepunktet viser frem når en klient kobler til. Det er et annet objekt enn sertifikatene individuelle klienter viser frem når gjensidig autentisering brukes. Å blande de to er den vanligste årsaken til at et ellers korrekt ACM-oppsett likevel feiler ved den første tilkoblingen.

Her er en gjennomgang fra konsollen og utover, i den rekkefølgen en tilkobling faktisk går.

To roller, ett endepunkt

Endepunktet eier en serveridentitet og, valgfritt, en måte å verifisere klientidentiteter på. Disse konfigureres separat. Den ene avgjør om klienten kan stole på tjenesten; den andre avgjør om tjenesten godtar klienten.

Les tabellen som tre uavhengige krav i stedet for som ett sertifikat. Servercertifikatet og den private nøkkelen blir hos tjenesten. Et klientcertifikat og den tilhørende private nøkkelen ligger på enheten. CA-materialet er det en verifiserer bruker for å kontrollere kjeden. Bare den midterste raden hører noen gang hjemme på en laptop.

Hva ACM-servercertifikatet gjør

Når du oppretter endepunktet, må servercertifikatet være tilgjengelig i ACM i samme region som endepunktet. Konsollen ber om en ARN, og den ARN-en må kunne slås opp der. ACM kan inneholde et sertifikat du har skaffet med domenebekreftelse, eller et du har importert sammen med nøkkelen og kjeden. Begge fungerer i denne rollen; de skiller seg i fornyelse og i hvem som har den private nøkkelen.

Velg anskaffelsesveien som passer til hvem som kan fornye sertifikatet, ikke den som tilfeldigvis produserte en fil som ser gyldig ut.

Hva gjensidig autentisering legger til

Å velge sertifikatbasert klientautentisering legger til et andre spørsmål: hvilke klienter som i det hele tatt får koble til. Hver klient viser frem sitt eget sertifikat og beviser at den har den tilhørende private nøkkelen. Separate identiteter er det som gjør selektiv tilbakekalling mulig senere. Å kopiere én klientnøkkel til hver enhet kaster den egenskapen stille bort, selv når servercertifikatet er anskaffet perfekt.

Endepunktets autentiseringsmetode er et valg, ikke et universelt krav.

Active Directory og føderert autentisering svarer på samme spørsmål på andre måter. En oppskrift med gjensidige sertifikater er ikke automatisk påloggingsdesignet for disse utrullingene, og serverens TLS-verifisering blir stående uansett hvordan brukeren slippes inn.

Hvorfor samme CA-ARN ikke er nøkkeldeling

AWS dokumenterer at når server- og klientcertifikatene er utstedt av samme CA, kan servercertifikatets ARN også brukes til valg av klientcertifikat. Den setningen handler om hvilken kjede endepunktet stoler på ved verifisering. Den sier ikke til klienter at de skal bruke serverens private nøkkel. En laptop trenger fortsatt sitt eget klientcertifikat og sin egen tilhørende nøkkel.

Når klientens CA er en annen utsteder, er den dokumenterte veien å importere den CA-en til ACM og velge den for klientrollen.

Spor feilen tilbake til et trinn

Finn ut hvilket trinn som feiler før du bytter ut noe. Hvis klienten avviser endepunktet, er serverens ARN eller kjeden mistenkt. Hvis endepunktet avviser klienten, se på klientcertifikatet, utstederen og den valgte autentiseringsmetoden. Hvis tunnelen kommer opp og trafikken fortsatt feiler, har du passert sertifikatene.

Bytt ut ett objekt om gangen, fordi å bytte begge ender samtidig gjenskaper tvetydigheten du startet med.

Kontroller også tjenestens støttede nøkkelalgoritmer og påkrevde utvidelser for den aktuelle rollen. Et sertifikat som tilfredsstiller et offentlig nettsted er ikke bevis på at alle identitetskrav for Client VPN er oppfylt.

Skriv ned hvilken ARN hvert felt inneholder, hvilken CA som utstedte klientcertifikatet, og hvilken autentiseringsmetode endepunktet faktisk bruker. Tre linjer dokumentasjon gjør neste fornyelse til en oppgave i stedet for en etterforskning.