AWS Client VPN: sertipiko ng server kumpara sa papel ng sertipiko ng kliyente
Pinatutunayan ng sertipiko ng server ng endpoint ang serbisyo. Ang mutual na pagpapatunay ay nagdaragdag ng pagkakakilanlan bawat kliyente at tiwala sa CA nang hindi ibinabahagi ang susi ng server.
Ang endpoint ng Client VPN ay laging nangangailangan ng TLS na sertipiko ng server. Iyon ang pagkakakilanlang ipinapakita ng pinamamahalaang endpoint kapag kumokonekta ang isang kliyente. Ibang bagay ito kaysa sa mga sertipikong ipinapakita ng mga indibidwal na kliyente kapag ginagamit ang mutual na pagpapatunay. Ang paghahalo sa dalawa ang pinakakaraniwang dahilan kung bakit ang isang setup ng ACM na tama sa ibang aspeto ay nabibigo pa rin sa unang koneksyon.
Narito ang isang paglalakbay mula sa console patungo sa labas, sa pagkakasunod-sunod na aktuwal na dinaraanan ng isang koneksyon.
Dalawang papel, isang endpoint
Nagmamay-ari ang endpoint ng pagkakakilanlan ng server at, opsyonal, isang paraan upang i-verify ang pagkakakilanlan ng mga kliyente. Hiwalay na kino-configure ang mga ito. Ang isa ay nagpapasya kung maaaring magtiwala ang kliyente sa serbisyo; ang isa pa ay nagpapasya kung tinatanggap ng serbisyo ang kliyente.
| 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 |
Basahin ang talahanayan bilang tatlong malayang pangangailangan sa halip na isang sertipiko. Nananatili sa serbisyo ang sertipiko ng server at ang pribadong susi nito. Ang sertipiko ng kliyente at ang katugmang pribadong susi ay nasa device. Ang materyal ng CA ang ginagamit ng verifier upang suriin ang chain. Tanging ang gitnang hilera ang kailanman kabilang sa isang laptop.
Ano ang ginagawa ng sertipiko ng server ng ACM
Kapag gumawa ka ng endpoint, dapat available ang sertipiko ng server sa ACM sa parehong Rehiyon ng endpoint. Humihingi ang console ng ARN, at dapat maresolba ang ARN na iyon doon. Maaaring maglaman ang ACM ng sertipikong naibigay mo nang may domain validation, o ng isang inangkat mo kasama ang susi at chain nito. Gumagana ang dalawa sa papel na ito; nagkakaiba sila sa pag-renew at sa kung sino ang may hawak ng pribadong susi.
Piliin ang landas ng pagbibigay na tumutugma sa kung sino ang makakapag-renew ng sertipiko, hindi ang isa na nagkataong gumawa ng file na mukhang balido.
Ano ang idinadagdag ng mutual na pagpapatunay
Ang pagpili ng pagpapatunay ng kliyente batay sa sertipiko ay nagdaragdag ng ikalawang tanong: aling mga kliyente ang maaaring kumonekta. Ipinapakita ng bawat kliyente ang sariling sertipiko at pinatutunayan ang paghawak sa katugmang pribadong susi. Ang magkahiwalay na pagkakakilanlan ang nagpapangyari sa piling pagbawi sa hinaharap. Ang pagkopya ng isang susi ng kliyente sa bawat device ay tahimik na nagtatapon ng katangiang iyon, kahit na perpektong nakuha ang sertipiko ng server.
Ang paraan ng pagpapatunay ng endpoint ay isang pagpili, hindi isang pangkalahatang pangangailangan.
Sinasagot ng Active Directory at federated na pagpapatunay ang parehong tanong sa ibang paraan. Ang resipe ng mutual na sertipiko ay hindi awtomatikong disenyo ng pag-login para sa mga deployment na iyon, at nananatili ang TLS verification ng server kahit paano pinapasok ang user.
Bakit ang parehong ARN ng CA ay hindi pagbabahagi ng susi
Isinasaad ng AWS na kapag ang mga sertipiko ng server at kliyente ay inisyu ng parehong CA, maaari ring gamitin ang ARN ng sertipiko ng server para sa pagpili ng sertipiko ng kliyente. Ang pangungusap na iyon ay tungkol sa kung aling chain ang pinagkakatiwalaan ng endpoint sa pag-verify. Hindi nito sinasabi sa mga kliyente na gamitin ang pribadong susi ng server. Kailangan pa rin ng laptop ang sariling sertipiko ng kliyente at ang sariling katugmang susi.
Kapag ang CA ng kliyente ay ibang issuer, ang dokumentadong landas ay i-import ang CA na iyon sa ACM at piliin ito para sa papel ng kliyente.
Sundan ang kabiguan pabalik sa isang yugto
Tukuyin kung aling yugto ang nabibigo bago ka magpalit ng anuman. Kung tinatanggihan ng kliyente ang endpoint, ang ARN ng server o ang chain nito ang pinaghihinalaan. Kung tinatanggihan ng endpoint ang kliyente, tingnan ang sertipiko ng kliyente, ang issuer nito at ang napiling paraan ng pagpapatunay. Kung bumangon ang tunnel at nabibigo pa rin ang trapiko, lagpas ka na sa mga sertipiko.
Palitan ang isang bagay sa isang pagkakataon, dahil ang pagpapalit ng dalawang dulo nang sabay ay nagpaparami ng kalabuan na sinimulan mo.
Suriin din ang mga sinusuportahang algorithm ng susi at mga kinakailangang extension ng serbisyo para sa partikular na papel. Ang sertipikong nakakatugon sa isang pampublikong website ay hindi patunay na natugunan ang lahat ng pangangailangan sa pagkakakilanlan ng Client VPN.
Isulat kung aling ARN ang hawak ng bawat field, aling CA ang nag-isyu ng sertipiko ng kliyente at aling paraan ng pagpapatunay ang aktuwal na ginagamit ng endpoint. Ang tatlong linyang talaan ay ginagawang gawain ang susunod na pag-renew sa halip na imbestigasyon.