Pagsusuri ng Sertipiko ng VPN Nang Hindi Inilalabas ang Susi

Ang pagbasa ng mga pampublikong field ng isang sertipiko ay hindi kailanman nangangailangan ng pagpapakita ng pribadong susi na katugma nito, at ang mga kagamitan para gawin iyon ay kasama sa bawat sistemang nagtatapos ng VPN. Ang panganib ay nasa isang hakbang bago pa iyon: ang file na ibinigay sa iyo ay maaaring hindi sertipiko. Ang PEM certificate, DER blob, PKCS#12 bundle at profile ng OpenVPN ay maaaring dumating na magkapareho ang pangalan ngunit magkaiba ang laman, kaya tukuyin ang container bago pumili ng command.

Tatlong katotohanan ang nagtatakda kung aling command ang ligtas: kung ano ang laman ng file, kung ano ang kailangan mong basahin mula rito, at kung sino ang makakakita ng output. Kapag nagkamali ka sa kahit isa, ang inspeksyon mismo ang magiging insidente.

Alin sa tatlong file ang ibinigay sa iyo

Ang PEM certificate ay teksto na may nakikitang BEGIN at END marker, ang DER file ay binary na kailangan ng input-format flag, at ang bundle ay container na maaaring may susi sa tabi ng sertipiko. file server.crt ay naghihiwalay ng teksto sa binary sa isang segundo, at ang isang tingin sa unang linya ay naghihiwalay ng hubad na sertipiko sa profile na may nakapaloob na sertipiko. Ang paghula rito ang nagpapasama sa inspeksyon.

Kung ang file ay profile at hindi sertipiko, ituring itong credential hanggang mapatunayan ang kabaligtaran. Walang gastos ang palagay na ito, at pinipigilan nito ang pinakakaraniwang pagkakamali sa buong gawaing ito.

Pagbasa ng mga pampublikong field ng isang PEM certificate

Para sa sertipikong awtorisado kang siyasatin, ang x509 subcommand na may -noout ay naglilimbag lamang ng mga field na pinili mo at wala nang iba. Ang pagsugpo sa katawan ang nagpapanatili ng output sa metadata, at iyon din ang nagpapaligtas nito para i-paste sa ticket. Ang mga selector sa ibaba ay ang mga pampubliko, at ang dokumentasyon ng openssl x509 ay naglilista ng iba pa.

openssl x509 -in server.crt -noout -subject -issuer -dates -fingerprint -sha256

Sa isang test certificate na ginawa sa lokal, ang command na iyon ay naglilimbag ng subject at issuer line, ang notBefore at notAfter pair, at isang SHA-256 fingerprint. Tinutukoy ng mga field na iyon ang object; hindi nila itinatag ang isang valid na trust path, na hiwalay na gawain ng verification na may sariling command at sariling sagot. Ang chain file ay maaaring maglimbag lamang ng unang sertipiko maliban kung ikaw mismo ang mag-loop sa file. Ang paghahambing ng dalawang file sa ganitong paraan ay isang command lang at ito ang magpapasya kung alin ang talagang ipinapakita ng peer.

Mga bundle na may susi sa tabi ng sertipiko

Ang .p12 o .pfx na file ay maaaring magdala ng pribadong susi, at ang parsing command ay naglilimbag nito maliban kung sugpuin mo ang bahaging iyon ng output. Sa -nokeys, ang parehong command ay nag-uulat pa rin ng istruktura ng container, kasama ang shrouded key bag, nang hindi naglalabas ng anumang key material; alisin ang flag na iyon at lalabas ang key block sa iyong terminal at sa shell history.

openssl pkcs12 -in bundle.p12 -nokeys -info -passin env:P12PASS

Ang profile ng OpenVPN ay naglalaman ng parehong materyal bilang teksto, kaya nakikita ang hangganan kung alam mo kung saan titingin. Ang pampublikong materyal ay nasa pagitan ng BEGIN CERTIFICATE at END CERTIFICATE, habang ang nasa pagitan ng BEGIN PRIVATE KEY at ng katugmang END line ay ang susi at hindi dapat lumabas ng host. Ang pagkopya ng buong profile ay naglalathala ng dalawa.

Pagkuha ng reference value mula sa ibang lugar

Ang fingerprint na binasa mula sa koneksyong sinusubukan mong i-verify ay walang pinapatunayan, dahil ang partidong hindi mo pinagkakatiwalaan ang nagbigay nito. Hindi ito argumento laban sa fingerprint; argumento ito tungkol sa pinagmulan. Ihambing ang halaga sa isang nakuha sa channel na hindi maisusulat ng peer, tulad ng sertipikong inilathala sa internal repository o ang hash na nakalimbag sa isang signed change record.

Kung saan may trust store na gumaganap ng validation, hayaan itong gawin iyon, at basahin ang error na inilalabas nito sa halip na ipalit ang sarili mong paghahambing. Ang mahalagang pagkakaiba ay kung sino ang nagbigay ng reference, hindi kung aling hash function ang ginamit.

Pagbabahagi ng resulta, at ano ang gagawin pagkatapos ng pagkakamali

Ipadala ang eksaktong validation error, ang mga kaugnay na petsa at tanging mga detalye ng pagkakakilanlan na kailangan ng tatanggap. Ang mga internal hostname at account identifier ay nananatiling sensitibo kahit walang susi, at ang pampublikong paste service ay maling destinasyon para sa alinman sa mga iyon. I-paste sa ticket, hindi sa scratch buffer na ibinabahagi ng iba.

Kung ang key material ay lumitaw sa screen o sa isang file, ituring itong nakompromiso at paikutin ito sa halip na umasang walang tumingin. Pagkatapos, isulat ang file na siniyasat, ang command na ginamit at kung saan napunta ang output, dahil ang rekord na iyon ang nagpapalit ng takot tungo sa pamamaraan. Mura ang rotation kumpara sa halaga ng pagpapalagay na walang nagtago ng screenshot, at sinasabi rin ng parehong rekord sa susunod na engineer kung aling mga file ang nagalaw. Gawin ang dalawa bago isara ang ticket.