Aling CA file ang pumapasok sa OpenVPN profile na password lang?

Daanin sa apat na tanong nang sunod-sunod at hindi na malabo ang CA dialog. Anong materyal ang aktwal na inilabas ng operator, ano ang nilalaman na ng profile, aling field ang nagtatanong, at ano ang nangyayari pagkatapos ma-load ang file? Huminto sa unang tanong na hindi mo masasagot mula sa sariling tagubilin ng operator, dahil ang manghula lampas doon ay siya mismong paraan kung paano nauuwi ang pampublikong CA certificate na katambal ng pribadong key na hindi dapat umalis sa server.

Mahalaga ang pagkakasunod-sunod: ang huling dalawang tanong ay may kahulugan lamang kapag alam mo kung anong materyal ang dapat na naroon.

Magsimula sa kung ano ang dala na ng profile

Buksan ang profile sa text editor at hanapin ang bloke ng ca bago maghanap ng file. Ang naka-embed na bloke ng ca na may pampublikong CA ng operator ay nangangahulugang self-contained ang profile, at ang client na humihingi pa rin ng CA file ay maaaring ibang profile o hindi kumpletong import ang binabasa. Kung ang profile ay may linyang ca na tumuturo sa isang path sa halip, ang path na iyon ay relative sa working directory ng client sa ilang integration at absolute sa iba. Itala kung aling anyo ang mayroon ka bago magbago ng anuman.

ca /absolute/path/operator-ca.crt
auth-user-pass
remote-cert-tls server

Suriin ang inihatid na package para sa mga file na tinutukoy ng profile: isang CA certificate, kung minsan ay hiwalay na client certificate at key, at maaaring isang file na tls-auth o tls-crypt. Ang profile na tumutukoy sa apat na file pero dumarating na may dalawa ay hindi kumpleto, at walang dami ng pagturo sa mga field ang makakapag-ayos niyon. Humingi sa operator ng kulang na bahagi sa halip na palitan ito ng certificate na nagkataong mayroon ka.

Paghiwalayin ang apat na uri ng materyal

Ang CA certificate ay pampublikong materyal na ginagamit upang i-verify ang pagkakakilanlan ng server. Ang client certificate ay kumikilala sa user o device sa server. Ang pribadong key ay ang lihim na kalahati ng client certificate na iyon, at hindi ito dapat maging signing key ng CA o server key. Ang materyal na tls-auth o tls-crypt ay hiwalay na shared secret na nagpoprotekta sa control channel. Hindi mapagpapalit ang apat na ito, at ang pagturo sa CA field sa isang client certificate ay gumagawa ng verification failure na mukhang problema sa tiwala.

Authentication na password lang ang nagbabago ng kung alin sa apat ang kailangan mo, hindi ang kahulugan nila. Sa auth-user-pass at remote-cert-tls server bino-verify pa rin ng client ang server laban sa isang CA, kaya lumilitaw ang CA field kahit walang client certificate. Ang patakaran ng operator ang nagpapasya kung kailangan din ng client certificate, at walang dialog ang makapagsasabi sa iyo niyon.

Ituro ang client sa trust file

Piliin ang CA certificate file mismo, hindi ang folder na naglalaman nito at hindi ang bundle na .p12 na may pagkakakilanlan ng client. Sa Windows iba ang ugali ng path syntax at file picker kaysa sa mga halimbawang Linux sa karamihan ng gabay, kaya gamitin ang tinatanggap ng naka-install na client at tiyakin na nababasa ng account na nagpapatakbo nito ang file. Magkamukha sa dialog ang problema sa permiso at ang nawawalang file pero iba ang log line na nalilikha. Pagkatapos pumili, muling buksan ang settings ng profile upang matiyak na itinago ng client ang pagpili.

<ca>
-----BEGIN CERTIFICATE-----
...operator-provided public CA...
-----END CERTIFICATE-----
</ca>

Kung sinusuportahan ng client ang naka-embed na bloke, mas mainam ang naka-embed na profile ng operator kaysa sa manu-manong buo. Ang naka-embed na materyal ay sumasama sa profile at nakakaligtas sa muling pag-import, samantalang ang absolute path ay nasisira sa sandaling ilipat ang profile sa ibang makina.

Basahin ang susunod na error, hindi ang pareho

Ang layunin ng pagbibigay ng tamang CA ay baguhin ang error, hindi ito papawiin. Ang pagkabigo sa pagkakakilanlan ng server pagkatapos ma-load ang CA ay nangangahulugang hindi tumugma ang certificate sa inaasahang pangalan o sa inaasahang remote-cert-tls, na ibang pagkukumpuni kaysa pagtanggi sa password. Ang pagtanggi sa password ay nangangahulugang nagtagumpay ang TLS layer at mali ang kredensyal. Itago ang unang bagong mensahe; iyon ang kapaki-pakinabang.

Ang client na kumokonekta pero walang naaabot ay lampas na nang lubos sa tiwala at ngayon ay humaharap sa tanong ng routing o DNS.

Huwag kailanman i-disable ang verification para makalampas sa dialog na iyon. Ang client na tumatanggap ng kahit anong certificate ay walang dahilan para humingi ng CA, at ang tunnel na itinatayo nito ay hindi ang nilayon ng operator.