Client VPN galapunktam vienmēr vajag TLS servera sertifikātu. Tā ir identitāte, ko pārvaldītais galapunkts uzrāda, kad klients pievienojas. Tas ir cits objekts nekā sertifikāti, ko uzrāda atsevišķi klienti, ja tiek izmantota savstarpējā autentifikācija. Šo divu sajaukšana ir visbiežākais iemesls, kāpēc citādi pareiza ACM konfigurācija tomēr neizdodas pirmajā savienojumā.

Šeit ir apskats no konsoles uz āru tādā secībā, kādā savienojums patiešām iet.

Divas lomas, viens galapunkts

Galapunktam ir servera identitāte un, ja vēlas, veids, kā pārbaudīt klientu identitātes. Tie tiek konfigurēti atsevišķi. Viens izlemj, vai klients var uzticēties pakalpojumam; otrs izlemj, vai pakalpojums pieņem klientu.

MaterialPurposeWhere it lives
Server certificate and private keyThe managed endpoint proves its TLS identityACM, in the endpoint's Region
Client certificate and matching keyAn individual client proves its identityOn the device
CA trust materialThe verifier checks the issuer chainSelected for the client role

Lasiet tabulu kā trīs neatkarīgas prasības, nevis kā vienu sertifikātu. Servera sertifikāts un tā privātā atslēga paliek pie pakalpojuma. Klienta sertifikāts un tam atbilstošā privātā atslēga atrodas ierīcē. CA materiāls ir tas, ko pārbaudītājs izmanto ķēdes pārbaudei. Tikai vidējā rinda kādreiz pieder klēpjdatoram.

Ko dara ACM servera sertifikāts

Veidojot galapunktu, servera sertifikātam jābūt pieejamam ACM tajā pašā reģionā, kur galapunkts. Konsole prasa ARN, un šim ARN tur ir jāatrisina. ACM var glabāt sertifikātu, ko nodrošinājāt ar domēna validāciju, vai to, ko importējāt kopā ar atslēgu un ķēdi. Abi darbojas šajā lomā; tie atšķiras atjaunināšanā un tajā, kam pieder privātā atslēga.

Izvēlieties nodrošināšanas ceļu, kas atbilst tam, kas var atjaunināt sertifikātu, nevis to, kas nejauši radīja derīgi izskatīgu failu.

Ko pievieno savstarpējā autentifikācija

Sertifikātu balstītas klienta autentifikācijas izvēle pievieno otru jautājumu: kuri klienti vispār drīkst pievienoties. Katrs klients uzrāda savu sertifikātu un pierāda atbilstošās privātās atslēgas turējumu. Tieši atsevišķas identitātes vēlāk ļauj selektīvi atsaukt. Viena klienta atslēgas kopēšana uz katru ierīci klusām atmet šo īpašību, pat ja servera sertifikāts iegūts nevainojami.

Galapunkta autentifikācijas metode ir izvēle, nevis universāla prasība.

Active Directory un federatīvā autentifikācija atbild uz to pašu jautājumu citiem līdzekļiem. Savstarpēja sertifikāta recepte nav automātiski šo ieviešanu pieteikšanās dizains, un servera TLS pārbaude paliek spēkā neatkarīgi no tā, kā lietotājs tiek ielaists.

Kāpēc viens un tas pats CA ARN nav atslēgu kopīgošana

AWS dokumentē, ka tad, ja servera un klienta sertifikātus izdevusi viena un tā pati CA, servera sertifikāta ARN var izmantot arī klienta sertifikāta izvēlei. Šis teikums ir par to, kurai ķēdei galapunkts uzticas pārbaudē. Tas neprasa klientiem izmantot servera privāto atslēgu. Klēpjdatoram joprojām vajag savu klienta sertifikātu un savu atbilstošo atslēgu.

Kad klienta CA ir cits izdevējs, dokumentētais ceļš ir importēt šo CA ACM un izvēlēties to klienta lomai.

Izsekojiet kļūmi atpakaļ līdz posmam

Pirms kaut ko aizstāt, nosakiet, kurš posms neizdodas. Ja klients noraida galapunktu, aizdomīgs ir servera ARN vai tā ķēde. Ja galapunkts noraida klientu, apskatiet klienta sertifikātu, tā izdevēju un izvēlēto autentifikācijas metodi. Ja tunelis ceļas un trafiks joprojām neizdodas, jūs jau esat pāri sertifikātiem.

Aizstājiet vienu objektu vienlaikus, jo abu galu maiņa vienlaikus atkārto sākotnējo neskaidrību.

Pārbaudiet arī pakalpojuma atbalstītos atslēgu algoritmus un nepieciešamos paplašinājumus konkrētajai lomai. Sertifikāts, kas apmierina publisku vietni, nav pierādījums, ka izpildītas visas Client VPN identitātes prasības.

Pierakstiet, kurš ARN ir katrā laukā, kura CA izdeva klienta sertifikātu un kuru autentifikācijas metodi galapunkts patiešām izmanto. Trīs ieraksta rindas pārvērš nākamo atjaunināšanu par uzdevumu, nevis izmeklēšanu.

Saistītie raksti