hindi suportadong layunin ng sertipiko: bakit nabibigo ang intermediate na CA

Mukhang tama ang layunin ng sertipiko ng server, tumutugma ang susi, maayos ang mga petsa, at nabibigo pa rin ang koneksyon sa unsupported certificate purpose. Ang detalyeng lumulutas dito ay karaniwang nasa parehong linya ng error: isang halaga ng lalim at isang subject na nagpapangalan ng sertipiko na mas mataas sa chain. Dalawang magkaibang pagsubok ang tumatakbo, at isa lamang sa kanila ang tungkol sa leaf. Ang paghahambing sa kanila ay nagpapaliwanag kung bakit walang nababago kapag pinalitan ang sertipiko ng server.

Aling sertipiko ang talagang tinanggihan ng verifier

Ang chain ay hindi isang bagay na inulit nang tatlong beses. Dinadala ng leaf ang pangalan at susi ng server, ikinakabit ng mga intermediate ang leaf sa isang root, at bawat isa ay may sariling panahon ng validity, mga hadlang at gamit. Kapag tinukoy ng error ang isang lalim, ang numerong iyon ay tumutukoy sa isang posisyon sa chain na ginawa ng verifier, at maaaring hindi ito ang posisyong inaasahan mo kung nagpapadala ang server ng hindi inaasahang chain.

Basahin ang mga field ng sertipiko sa lalim na iyon, hindi ang sertipikong inakala mong may kasalanan. Hilingin ang dalawang extension na naghihigpit sa paglabas sa halip na ilabas ang bawat field, dahil halos palaging nasa isa sa kanila ang sagot. Ligtas ibahagi ang output ng extension; ang mga private key ay hindi kailanman.

openssl x509 -in issuing-ca.pem -noout -subject -issuer -ext basicConstraints -ext extendedKeyUsage

Kung ang tinukoy na sertipiko ay isang intermediate na ang extended key usage ay nagbabanggit ng isang bagay na walang kaugnayan sa TLS server authentication, ang natitirang bahagi ng pagpalya ay sumusunod nang mekanikal. Hindi magagamit ang chain para sa layuning hiniling ng OpenVPN.

Ang layunin ng leaf at ang patakaran ng chain ay dalawang pagsubok

Ang pagsubok sa leaf ay nagtatanong ng makitid na tanong: pinapayagan ba ng end-entity certificate na ito ang server authentication para sa pangalang ito? Ang pagsubok sa chain ay nagtatanong ng mas malawak: maaari bang maglingkod sa layuning iyon ang bawat sertipiko sa landas? Ang isang certificate authority na pinapayagang maglabas lamang ng client certificates ay papasa sa sarili nitong mga pagsusuri ng lagda at babagsak pa rin sa ikalawang pagsubok, dahil ang landas na pinapahintulutan nito ay hindi kasama ang layuning kailangan ng application. Parehong nabibigo ang dalawang pagsubok sa parehong mga salita at may ganap na magkaibang mga pag-aayos.

Kaya naman ang bagong labas na leaf, tama sa bawat nakikitang field, ay maaaring agad na mabigo. Kaya naman karaniwang kabilang ang pag-aayos sa profile ng issuing authority at hindi sa configuration ng VPN.

Ang kulang na EKU ay hindi restrictive na EKU

Ginagawang opsyonal ng RFC 5280 ang extended key usage extension at, kapag naroroon, naghihigpit ito. Kaya ang CA certificate na walang extension ay hindi nagsabi ng «hindi» sa server authentication, samantalang ang isa na naglilista lamang ng walang kaugnayang layunin ay nagsabi ng isang bagay na napaka-espesipiko. Ang pagtrato sa dalawang estadong ito bilang magkatumbas ay nagbubunga ng maling diagnosis at, mas masahol, maling pag-aayos. Ipinapaliwanag din ng pagkakaiba kung bakit ang dalawang authority na magkamukha sa isang console ay ganap na magkaiba ang kilos sa isang chain.

Hindi rin pantay ang pag-uugali ng mga library dito. Inilalarawan ng dokumento ng OpenSSL tungkol sa mga opsyon sa verification ang sarili nitong pagtrato sa mga pagsusuri ng layunin sa CA certificates, at ang pagtratong iyon ay patakaran ng implementasyon, hindi isang tuntuning sinusunod nang magkapareho ng bawat TLS stack. Ilarawan ang ginagawa ng iyong verifier, pagkatapos ay kumpirmahin ito sa bersyong talagang pinapatakbo mo.

Kopyahin muli ang pagpalya offline bago muling maglabas

Inaalis ng offline verification ang application sa equation. Kung nabibigo ang chain sa parehong paraan sa ilalim ng parehong layunin, ang sertipiko ang problema at walang configuration ng server ang makakapagtago nito. Kung pumasa ang chain offline habang tumatanggi pa rin ang serbisyo, ibang layunin ang hinihiling ng application o gumagamit ito ng ibang chain kaysa sa sinubukan mo.

openssl verify -purpose sslserver -show_chain -CAfile root-ca.pem -untrusted issuing-ca.pem vpn-server.pem

-show_chain mahalaga dahil ipinapakita nito ang landas na ginawa ng tool, at kadalasan hindi iyon ang pagkakasunod-sunod ng file na ibinigay mo. Ang output na iyon ang pinakamabilis na paraan upang matuklasan na may ikalawang intermediate certificate na hinihila mula sa trust store, na nagpapadala ang server ng cross-signed variant na hindi mo sinadya, o na ang layunin flag na kinopya mo mula sa tutorial ay kabilang sa ibang role kaysa sa sineserbisyuhan.

Ayusin ang patakaran sa paglabas, hindi ang tawag sa verification

Ang matibay na pag-aayos ay isang intermediate certificate na inilabas sa ilalim ng patakarang pumapayag sa mga layuning dapat nitong pagsilbihan, na nakasulat at nasuri ang hadlang. Ang pagdaragdag ng bawat layunin sa bawat authority ay hindi patakaran; inaalis nito ang hadlang na nagbigay ng kahulugan sa extension, at kadalasan ay mas humahaba pa kaysa sa insidenteng nagdulot nito. Ang maikling tala sa profile na naglalarawan kung aling mga role ang maaaring sertipikahin ng authority ay pumipigil sa susunod na muling paglabas na ulitin ang parehong pagtatalo.

Ang pagpapatay sa verification ay ang isa pang tuksong shortcut, at ginagawang problema ng tiwala ang problema ng sertipiko. Panatilihin ang pagsusuri sa layunin, ayusin ang chain, at patakbuhin muli ang parehong offline verification upang kumpirmahin na ang landas ay naglilingkod na sa nilalayong role bago muling hawakan ang serbisyo.