Parehong pangalan ng file na ca.crt, ibang sertipiko: ano ang ihahambing

Dalawang profile ang parehong nagdadala ng file na tinatawag na ca.crt, isang tunnel ang tumataas at ang isa ay nabigo sa error sa chain. Ang pagbukas ng dalawang file nang magkatabi ay bihirang nagtatakda nito, at ang pag-off ng verification ay nagtatakda nito sa maling direksyon. Ang tanong na talagang itinatanong ng error ay mas makitid: aling sertipiko ang nilo-load ng bawat proseso bilang anchor ng tiwala nito, at ang dalawa ba ay parehong bagay? Sagutin muna iyon at ang natitirang diagnosis ay magkakaroon ng direksyon. Ang pangalan ng file ay isang label ng packaging, at ang path na nakasulat sa profile ay hindi rin authoritative, kaya nakasalalay ang lahat sa kung ano ang aktwal na binabasa ng proseso.

Hanapin ang sertipiko na aktwal na nilo-load ng client

OpenVPN ay tumatanggap ng awtoridad sa dalawang anyo, at ang anyo ang nagtatakda kung aling bytes ang mahalaga. Ang isang profile ay maaaring tumuro sa panlabas na file gamit ang ca, o i-embed ang sertipiko sa loob ng bloke na <ca> sa profile mismo. Kapag mayroon ang dalawa, ang naka-embed na bloke ang nananalo at ang file sa tabi ng profile ay hindi kailanman binubuksan.

Basahin ang nabigong profile at alamin kung aling anyo ang ginagamit nito bago ihambing ang anuman. Ang kopyang kinuha mula sa katabing direktoryo, o mula sa package na pinanggalingan ng isa pang profile, ay walang sinasabi sa iyo tungkol sa kung ano ang pinagkakatiwalaan ng prosesong ito. Gayundin ang path sa configuration: nireresolba ito kaugnay ng lugar kung saan sinimulan ang client, na hindi palaging ang direktoryo na tinitingnan mo. Basahin ang profile, hindi ang folder.

Ang mga sertipiko ay nakikilala sa pamamagitan ng nilalaman: ang public key, ang subject at issuer, ang window ng validity, at ang lagda sa lahat ng iyon. Ang dalawang file na may magkaparehong bytes ay parehong sertipiko anuman ang tawag sa kanila, at ang dalawang file na may parehong pangalan ay maaaring hindi magkakaugnay na awtoridad. Ang pangalan ay isang label ng packaging, hindi pagkakakilanlan.

Kunin ang fingerprint ng dalawang kopya gamit ang openssl

Ang fingerprint ay isang hash sa DER encoding ng sertipiko, ang anyo na sinasaklaw ng lagda, kaya hindi ito maaapektuhan ng dulo ng linya at teksto ng header. Kalkulahin ito para sa bawat file at mayroon kang dalawang hex string na pinaghihiwalay ng colon na tumutugma o hindi. Wala nang iba sa sertipiko ang kailangang basahin para sagutin ang tanong ng paghahambing.

openssl x509 -in /etc/openvpn/office/ca.crt -noout -fingerprint -sha256
openssl x509 -in ~/profiles/lab-ca.pem -noout -fingerprint -sha256

Nakakatukso na ituro ang openssl sa profile mismo, ngunit binabasa nito ang unang bloke ng sertipiko na lumilitaw sa file, at ang profile ay karaniwang may <cert> bago ang <ca>. Kunin ang bloke ng awtoridad, pagkatapos ay kunin ang fingerprint ng kinuhang file, dahil iyon ang kopyang aktwal na gagamitin ng client.

sed -n '/^<ca>$/,/^<\/ca>$/p' office.ovpn | sed '1d;$d' > /tmp/office-ca.pem
openssl x509 -in /tmp/office-ca.pem -noout -fingerprint -sha256

Ang magkaparehong fingerprint ay nangangahulugang pareho ang materyal ng tiwala at ang error sa chain ay may ibang dahilan, na ibang imbestigasyon. Ang magkaibang fingerprint ay nangangahulugang magkaibang sertipiko, at doon nagsisimula ang susunod na seksyon.

Basahin ang pagkakaiba bago ipalagay ang isang pag-atake

Ang magkaibang fingerprint ay nangangahulugang magkaibang sertipiko at wala nang iba pa. Ang muling pag-isyu, pag-ikot, pinalitan ng pangalan na awtoridad, o lumang bundle ay lahat gumagawa ng magkaibang file na may ganap na lehitimong kasaysayan. Alin ang kabilang sa deployment ay tanong para sa operator o para sa rekord ng deployment, hindi para sa oras ng pagbabago ng file. Kinokopya ng mga archive ang timestamp, kaya ang mas bagong file ay hindi awtomatikong ang tamang anchor.

Ang root na pumipirma sa sarili nito ay normal, kaya ang makahanap ng isa ay hindi patunay ng problema. Ang trabaho ng verifier ay bumuo ng landas mula sa sertipiko ng server hanggang sa anchor na ibinigay dito, at ang error sa chain ay karaniwang nangangahulugang hindi natapos ang landas na iyon.

Tingnan kung ang anchor ng nabigong profile ay isang awtoridad na pinag-iisyuan pa ng deployment. Kung ang fingerprint ay hindi tumutugma sa anuman sa rekord ng deployment, ang profile ay luma lang, at walang tuning sa panig ng client ang makakapag-ayos nito.

Ayusin ang tiwala nang hindi pinapatay ang verification

Ang panandaliang pag-aayos ay patayin ang verification o idagdag ang bawat sertipiko sa chain bilang anchor. Pareho nitong pinapawala ang mensahe, at pareho nitong binabago kung aling mga server ang tatanggapin ng client mula noon. I-on muli ang verification, i-install ang nilalayong anchor at subukan muli.

Kung ang chain ay nabuo na ngayon ngunit may ibang error na lumitaw, iyon ay pag-unlad: ang beripikasyon ng pangalan, mga petsa ng validity at pagbawi ay magkakahiwalay na pagsusuri na may magkakahiwalay na mensahe. Itago ang pares ng fingerprint at ang orihinal na teksto ng error nang magkasama sa ticket, upang makita ng susunod na tao kung aling anchor ang na-load at alin ang inaasahan. Ang isang pares ng fingerprint ay sapat na maliit upang i-paste sa isang handover note, at ang susunod na pangyayari ay tatagal ng limang minuto sa halip na isang hapon.

Kunin ang tamang awtoridad sa pamamagitan ng parehong authenticated na channel na naghatid ng profile. Ang paghila ng sertipiko mula sa server dahil mukhang pamilyar ang subject nito ay ibang kilos, at tahimik nitong pinalalawak kung ano ang pagtitiwalaan ng client.