Nabibigo ang pagbawi ng sertipiko: aling host ang hindi maabot ang ano

Maaaring nasa loob ng validity window ang mga sertipiko habang ang VPN ay nag-uulat pa rin ng authentication failure, at may maghihinuhang binawi na ang sertipiko. Tatlong magkaibang katotohanan iyon. Ang data ng pagbawi ay dapat kunin ng device na gumagawa ng validation, mula sa publication endpoint na nakasaad sa loob mismo ng sertipiko. Kapag hindi maabot ng device na iyon ang endpoint, nabibigo ang pagsusuri dahil sa mga dahilan na walang kaugnayan sa status ng sertipiko.

Pag-aari ng validator ang daan ng pagkuha

Magsimula sa pagtukoy ng validator. Kapag sinusuri ng laptop ang sertipiko ng gateway, ang laptop ang kumukuha; kapag sinusuri ng gateway ang sertipiko ng client, ang gateway ang gumagawa nito. Maaaring magdagdag ang isang authentication service sa backend ng pangatlong validator na may sariling posisyon sa network. Bawat isa ay may ibang ruta patungo sa internet at ibang proxy configuration. Walang sinasabi ang ebidensiyang nakalap sa workstation ng administrator tungkol sa isang server sa loob ng DMZ.

Isulat ang sertipiko, ang validator, ang oras ng pagtatangka at ang eksaktong status code bago baguhin ang anuman.

Basahin ang publication endpoint mula sa sertipiko

Tinutukoy ng sertipiko kung saan naroon ang status nito. Basahin ang mga field na iyon sa halip na hulaan ang isang CA address.

openssl x509 -in gateway.cer -noout -text | grep -A3 "CRL Distribution Points"
openssl x509 -in gateway.cer -noout -text | grep -A2 "Authority Information Access"

Inililista ng unang extension ang mga CRL distribution point, at ang pangalawa ay naglilista ng mga paraan ng pag-access sa impormasyon ng issuer, na maaaring sumaklaw sa OCSP status at pagkuha ng sertipiko ng issuer. Magkaibang mekanismo ang mga ito, at ang OCSP responder ay hindi CRL file. Ang publication host ay madalas na ordinaryong web server at hindi ang CA machine, dahil ang offline na issuer ay makakapirma ng CRL na ipinapamahagi ng ibang server. Kaya ang firewall rule na inilalarawan bilang access sa CA ay masyadong malabo upang ipatupad o suriin.

Subukan ang pagkuha mula sa device na nagbe-verify

Patakbuhin ang pagsubok sa pagkuha sa kapaligirang aktuwal na gumagawa ng validation, gamit ang aprubadong certificate material at walang private key.

certutil -urlfetch -verify .\client-test.cer
curl -sS -o /dev/null -w "%{http_code}\n" http://crl.example.com/ca.crl

Bine-verify ng certutil run ang chain at iniuulat kung aling mga URL fetch ang nagtagumpay o nabigo, habang ang curl call ay sumusubok ng isang publication address mula sa parehong host at nagbabalik lamang ng status code. Ang bigong pagkuha mula sa maabot na address ay tumutukoy sa mga problema sa nilalaman o pirma; ang error sa koneksiyon ay tumutukoy sa routing, DNS o proxy. Itago ang parehong resulta, dahil ang isang matagumpay na pagkuha ay hindi nagpapatunay na magagamit ang buong chain. Palitan ang halimbawang host at path ng distribution point na natagpuan sa sertipiko.

Ihiwalay ang kulang na data sa binawing status

Apat na kinalabasan ang magkamukha mula sa labas: hindi maabot ang endpoint, luma na ang listahan, napirmahan ang listahan ng maling issuer, o tunay na binawi ang sertipiko. Ang huli lamang ang resulta ng status, at iyon lamang ang nagbibigay-katwiran sa pag-alis ng access. Mas pinapalubha pa ng caching ang larawan, dahil maaaring itago ng dating nakuhang data ang sirang publication path hanggang sa susunod na refresh. Ang pag-disable ng revocation checking, pagtanggal ng walang kaugnayang sertipiko o pag-reboot ng gateway ay pumapalit sa diagnosis ng aktibidad.

Pagkatapos ng pagwawasto, pilitin ang bagong authentication at kumpirmahin na nagtagumpay ang sinadyang pagkuha ng status. Kung may kontroladong test identity, kumpirmahin na tinatanggihan pa rin ito, dahil ang availability na nag-aalis ng pagsusuri ay hindi pagkukumpuni.