Self-signed na sertipiko ng kliyente? Tinatanggihan pa rin ito ng VPN server

Nagpapadala ang operator ng address at username, at humihiling ang kliyente ng CA file, sertipiko at key. Ang paggawa ng tatlong ito nang lokal ay tila ang halatang susunod na hakbang. Ang resulta ay isang sertipiko na pinaniniwalaan lamang ng sarili mong makina. Ang pagtitiwala ng server ay nakaangkla sa isang CA na hindi mo kontrolado, kaya natatapos ang handshake bago pa ito magsimula.

Nakatira ang pagtitiwala sa server, hindi sa iyong profile

Ang pagpapatunay sa pamamagitan ng sertipiko ay isang paghahambing. Nagpapakita ang kliyente ng sertipiko; tinitingnan ng gateway kung nilagdaan ito ng isa sa mga CA sa configuration nito.

Itinutukoy ng iyong profile ang CA file na dapat gamitin ng kliyente upang i-verify ang server. Hindi nito matutukoy ang CA na dapat gamitin ng server upang i-verify ka. Hindi sa iyo ang kalahating iyon ng configuration.

Ang sertipikong ikaw mismo ang gumawa ay nabigo sa paghahambing na ito kahit teknikal na perpekto ito. Mayroon itong valid na lagda, subject at mga petsa, ngunit ang issuer ay isang CA na hindi pa narinig ng gateway. Lumilitaw ang error sa panahon ng handshake, pagkatapos nang humiling ng sertipiko ang server. Wala sa profile ng kliyente ang makakabago sa sagot.

Bakit hindi ito mapapalitan ng self-signed na sertipiko

Ang self-signed na sertipiko ay nilalagdaan ng sarili nitong key. Ang lagda ay nabe-verify laban sa parehong file, na ginagawa itong self-consistent at walang silbi bilang kredensyal para sa gateway ng iba.

Hindi tinatanong ng gateway kung panloob na pare-pareho ang sertipiko. Tinatanong nito kung nilagdaan ito ng pinagkakatiwalaang issuer.

Kaya nakakalito ang mga mensahe ng error. Maaaring mag-ulat ang kliyente ng pagkabigo sa pag-verify na parang problema ng server, habang nagtatala ang server ng hindi kilalang issuer. Pareho nilang inilalarawan ang parehong pagkakaiba mula sa magkabilang dulo.

Pinapanatili ng CSR path ang iyong pribadong key

Magagawa mo pa rin ang karamihan ng trabaho nang lokal. Gumawa ng key pair, bumuo ng certificate signing request sa paligid ng pampublikong kalahati, at ipadala ang request sa operator. Ang request lamang ang lumalabas sa iyong makina. Nananatili ang pribadong kalahati sa lugar kung saan mo ito ginawa.

openssl req -new -newkey rsa:3072 -nodes -keyout client.key -out client.csr -subj "/CN=laptop-01"

Nilalagdaan ng operator ang request gamit ang kanilang CA at ibinabalik ang sertipiko. Hindi kailanman naglakbay ang iyong pribadong key, at ang resulta ay nagkakadena sa angkla na pinagkakatiwalaan ng gateway.

Madalas laktawan ng mga managed service ang CSR at ibigay ang buong bundle. Iyon ay isang makatwirang palitan kapag tinatapos na ng parehong provider ang tunnel at hawak nito ang CA. Hindi bumubuti ang pangangalaga sa key sa pamamagitan ng pagtatago nito, dahil makakagawa ang provider ng bago anumang oras.

Ini-import ang mga bundle, hindi ini-install

Ang mga bundle ng vendor na may mga pangalang parang seguridad ay madalas na OpenVPN profile. Naglalaman ang mga ito ng configuration at kung minsan ng mga sertipiko, at wala silang ini-install. I-import ang file sa isang kliyenteng nagsasalita ng protocol, at nakakonfigur ang koneksyon.

Ang tuntunin sa paghawak ay nagmumula sa nilalaman. Kung ang profile ay naglalaman ng pribadong key, ito ay kredensyal at karapat-dapat sa parehong pag-aalaga tulad ng password: walang email, walang repository, walang shared downloads folder. Kapag ibinigay ng operator ang ca.crt, client.crt at client.key nang hiwalay, itago ang mga ito nang sama-sama na may mahigpit na pahintulot at ituro ang profile sa mga ito.

Idagdag ang mga pagsusuring maaaring nalaktawan ng operator

Ang profile na ginawa ng router ay kung minsan walang peer verification. Hinihiling ng remote-cert-tls server na ang sertipiko ng peer ay may layuning server authentication, upang hindi ma-replay ang sertipiko ng kliyente bilang server. Ang isang linyang iyon ay maliit na pagbabago na may malinaw na katwiran.

verify-x509-name ay mas malayo kapag matutukoy ng operator ang inaasahang subject o SAN. Pareho silang maliliit na dagdag sa profile, at pareho silang maipagtatanggol. Suriin ang natanggap mo bago ito i-import.

openssl x509 -in client.crt -noout -issuer -subject -dates
openssl verify -CAfile ca.crt client.crt

Ang mga setting ng verification ay hindi pag-aayos ng sirang kadena. Kung mali ang issuer, ang sagot ay sertipiko mula sa tamang CA, hindi isang flag na nagpapatay sa pagsusuri. Ang pagpatay sa verification ay ginagawang hindi natukoy ang isang pagkabigo sa authentication.

Humingi ng isang bundle: ang sertipiko ng awtoridad bilang PEM, sertipiko ng kliyenteng nilagdaan ng awtoridad na iyon, key na ikaw mismo ang gumawa o dumating sa pamamagitan ng channel na pinagkakatiwalaan mo, at ang eksaktong pangalan ng server na dapat ipakita ng sertipiko. Itala ang petsa ng pag-expire sa parehong mensahe, dahil ang nag-expire na sertipiko ay mukhang sira ng network makalipas ang mga buwan.