Ang sertipiko ng dahon ay wasto, ang kadena ay nag-expire: basahin ang lalim

Sinusuri mo ang sertipiko ng server, nakikita mong may mga buwan pang natitira sa orasan, at tinatanggihan pa rin ng client ang koneksyon gamit ang mensahe ng pag-expire. Ang petsang binabasa mo ay sa dahon, at ang reklamo ay maaaring tungkol sa mas malalim sa landas. Dumadaan ang verification sa isang kadena, at anumang sertipikong pinili ng paglalakbay na ito ay maaaring mabigo sa sarili nitong window ng validity. Basahin kung alin ang nabigo bago mag-renew ng kahit ano.

Pinapangalanan ng lalim ang sertipikong nabigo

Sa diagnostics ng OpenSSL, ang lalim 0 ay ang target na sertipiko at ang lalim 1 ay ang issuer na pumirma dito, na ang mas matataas na numero ay nagpapatuloy patungo sa anchor ng tiwala. Ang pag-expire na iniulat sa lalim 1 ay hindi sinasalungat ng kasalukuyang notAfter sa dahon, kaya ang muling pagsuri sa nakikitang sertipiko ay hindi kailanman magpapaliwanag ng error.

Itala ang fingerprint ng nabigong sertipiko kasama ang subject nito, dahil ang magkaibang sertipiko ay maaaring magdala ng parehong pangalan ng CA. Ang cross-signing ay lumilikha ng eksaktong sitwasyong iyon: lumilitaw ang parehong awtoridad nang higit sa isang beses, na may magkaibang petsa ng validity, at pinili ng verifier ang hindi mo inaasahan. Ang pamilyar na label ay hindi identifier, at ang fingerprint ang nagtatangi sa dalawang bagay na nagbabahagi ng pangalan.

Pansinin din ang mga produktong may higit sa isang papel sa sertipiko. Sa OpenVPN Access Server, ang mga sertipikong nagpoprotekta sa mga web interface ay hiwalay sa mga ginagamit para sa mga koneksyon ng VPN, kaya ang browser na nagbubukas ng admin page ay walang pinapatunayan tungkol sa landas ng tunnel.

Ang mga input ng tiwala ay hindi katulad ng mga kandidato ng kadena

Ibigay sa verifier ang dalawang input nang hiwalay at tahasan. Ang file ng tiwala ay naglalaman ng mga anchor na tinatanggap mo; ang hindi pinagkakatiwalaang bundle ay naglalaman ng mga intermediate na sertipikong iniaalok para sa pagbuo ng landas. Ang paghahalo sa kanila ay kung paano aksidenteng itinataas ng mga tao ang isang intermediate bilang root at pagkatapos ay nagtataka kung bakit sinusundan sila ng parehong error sa pagitan ng mga makina.

$ openssl verify -verbose -show_chain -purpose sslserver \
    -CAfile trusted-roots.pem -no-CApath -no-CAstore \
    -untrusted intermediates.pem server.pem

Ang pag-disable ng default na landas at imbakan gamit ang -no-CApath -no-CAstore ay nagpapanatili ng tapat na pagsubok: ang resulta ay nakasalalay sa mga file na pinangalanan mo, hindi sa kung ano ang sinasampalatayanan ng workstation nang nagkataon. Ang reference ng verification ng OpenSSL ay nagdodokumento ng mga opsyong ito at ng diagnostics na ginagawa nila.

Ang -show_chain ay nagpi-print ng itinayong kadena kapag matagumpay ang verification, na kapaki-pakinabang upang kumpirmahin na ang landas ay ang sinadya mo. Kapag nabigo ito, panatilihin ang iniulat na lalim at subject; sinasabi ng dalawang field na iyon sa susunod na mambabasa kung aling sertipiko ang susuriin.

Ang hindi ginagawa nito ay kopyahin ang patakaran ng bawat client. Ang pin, paghihigpit sa layunin o check ng pagkakakilanlan na partikular sa client ay naninirahan sa client, hindi sa utos na ito. Iyon ang mga setting na susuriin kapag pumasa ang verification sa server at nabigo pa rin ang koneksyon. Panatilihing hiwalay ang dalawang diagnosis, o magre-renew ka ng malusog na sertipiko habang hinahabol ang error sa pinning.

Ano ang pinapatunayan ng check at ano ang iniiwan

Ito ay check ng landas at layunin laban sa file ng tiwala na ibinigay mo. Para sa check ng pangalan sa HTTPS, idagdag ang inaasahang hostname sa pamamagitan ng naaangkop na opsyon; para sa koneksyon ng VPN, panatilihin ang mga naka-configure na check ng pagkakakilanlan ng client at gamitin ang materyal ng tiwala na aktwal na binabasa ng client na iyon.

Ang ipinapadala ng server ay isang set ng mga kandidato, hindi ang landas na bubuuin ng iyong client sa huli. Ang lokal na tiwala at ang mga tuntunin ng pagbuo ng library ay parehong humuhubog sa resulta, kaya ang parehong tugon ay maaaring mag-verify sa isang makina at mabigo sa isa pa. Ihambing ang pinapanatili na imbakan ng tiwala at implementasyon ng TLS ng nabigong client sa ng gumaganang client bago ipagpalagay ang magkatulad na pagsusuri. Ang pagkakaiba doon ay nagpapaliwanag ng maraming ulat na „tanging laptop na ito ang nabigo“.

Upang makita ang window ng bawat sertipiko sa halip na isa-isa, i-print ang mga ito bilang isang set:

$ openssl x509 -in server.pem -noout -subject -dates
$ openssl crl2pkcs7 -nocrl -certfile intermediates.pem \
    | openssl pkcs7 -print_certs -noout

Ang ikalawang utos na iyon ay naglilista ng mga subject at issuer nang hindi kinakailangang i-decode ang bawat file sa pamamagitan ng kamay, kaya napapansin mo ang isang intermediate na ang petsa ay lumipas habang ang dahon ay mukhang maayos pa.

Ayusin ang landas nang hindi hinihinaan ang verification

Kapag may ibinibigay na nag-expire na intermediate o lipas na cross-signed na sertipiko, kunin ang kasalukuyang sinusuportahang kadena ng issuer at i-deploy ito sa pamamagitan ng dokumentadong workflow ng sertipiko ng serbisyo. Kapag kulang ang client sa sinadyang pinapanatiling anchor, i-update ang pinamamahalaang configuration ng tiwala nito o ang software ng client. Labanan ang shortcut na markahan ang bawat sertipiko sa bundle bilang root para lang patahimikin ang mensahe.

Ang paghawak sa root ay kailangang ng tala, dahil madalas itong labis na pinapalaki ng mga buod. Itinuturing ng RFC 5280 ang anchor bilang input na nasa labas ng inaasahang landas, samantalang idinodokumento ng OpenSSL ang mga check ng validity na kasama ang root CA certificate nito. Ang parehong pahayag ay totoo para sa kani-kanilang sistema; ang pag-generalize ng pag-uugali ng pag-expire ng root ng isang library sa bawat client ay nagbubunga ng kumpiyansang maling sagot.

Pagkatapos ng pagbabago, pilitin ang bagong authentication sa apektadong client at kumpirmahin na nawala ang partikular na mensahe ng pag-expire. I-renew ang dahon lamang kung ang dahon mismo ay hindi angkop. Ang pag-disable ng mga check ng oras o pagbalik ng makasaysayang cross certificate ay hindi lumilikha ng wastong kasalukuyang landas; pinalaliban lamang nito ang susunod na pagkabigo.