openssl ca: di-wastong petsa ng pag-expire sa index.txt at paano ito ayusin

Isang pagtakbo ng pag-isyu ang humihinto sa entry 22: invalid expiry date, samantalang ang kahilingan sa harap mo ay ganap na maayos. Ang reklamo ay nagmumula sa parser ng database ng CA, hindi sa CSR at hindi sa VPN client na sa huli ay maghaharap ng sertipiko. Ang pagkakaibang iyon ang magtatakda ng lahat ng sumusunod: ang rekord ay depektibo, kaya ang pag-aayos ay pag-aari ng estado ng CA at hindi ng kahilingan o ng configuration ng peer. Ituring ang numeradong entry bilang isang linya sa index.txt, at ang problema ay lumiliit sa isang limitadong tanong sa datos na may masusuri na sagot.

Basahin ang error bilang reklamo tungkol sa database

Bawat openssl ca pagtawag ay dumadaan sa text database nito bago pumirma ng anuman. Bawat linya ay may letra ng estado, isang timestamp ng pag-expire, opsyonal na timestamp ng pagbawi, serial number sa hex, pangalan ng file at subject. Kapag isang field ang hindi ma-parse, iniuulat ng command ang numero ng linya at humihinto sa halip na hulaan ang natitirang bahagi ng rekord.

Ang paghinto na iyon ay proteksiyon at hindi pagiging pilosopo. Ang rekord na hindi mabasa ng tool ay nag-iiwan dito na hindi makapagpasya kung mayroon na ang hinihiling na subject, kung naibigay na ang serial number, o ano ang dapat taglayin ng susunod na CRL. Ang pagpapatuloy lampas sa isang sirang linya ay lilikha ng eksaktong tahimik na inkonsistensiyang iyon na lumilitaw pagkalipas ng mga buwan, kadalasan habang isang pagbawi na walang makapagpapaliwanag. Basahin ang mensahe bilang reklamo tungkol sa datos, at ang pagsisiyasat ay mananatili sa loob ng direktoryo ng CA.

Kopyahin ang estado ng CA bago hawakan ang anuman

Kumuha ng snapshot ng buong direktoryo ng CA, hindi lamang ng file ng database. Ang index, ang file ng mga katangian nito, ang mga file ng serial number at CRL number, ang pribadong susi at ang mga inisyung sertipiko ay lahat kasama sa mga susunod na operasyon, at ang pag-aayos na nagbabalik ng isa habang nalalaktawan ang iba ay lumilikha ng ikalawang insidente. Gamitin ang sariling routine ng backup ng CA kung mayroon, at itigil ang naka-iskedyul na pag-isyu habang tumatagal ang trabaho.

Itala ang build ng OpenSSL at ang configuration file na aktwal na na-load ng nabigong command. Ang mga installation ay madalas na nagtatago ng higit sa isang direktoryo ng CA, at ang error ay may kahulugan lamang laban sa database na pinangalanan ng napiling configuration.

Hanapin ang entry at i-decode ang field ng petsa nito

Ang iniulat na numero ng linya ay binibilang mula sa unang rekord, kaya sed -n '22p' index.txt ay tumatama sa problemang entry kapag nakumpirma mo nang walang blangkong linya o komento sa itaas nito. I-print ang linyang iyon na may nakikitang delimiter, dahil ang mga tab at puwang sa dulo ay karaniwan at hindi nakikita sa ordinaryong window ng editor.

Ang field ng pag-expire ay isang timestamp na ang lapad ay nakasalalay sa taon. Ang mga halaga hanggang 2049 ay isinusulat sa UTCTime bilang YYMMDDHHMMSSZ, samantalang ang mga susunod na halaga ay lumilipat sa GeneralizedTime na may apat na digit na taon. Ang rekord na naghahalo ng dalawang anyo, o may dalawang digit na taon sa lugar kung saan inaasahan ng parser ang apat, ay nabigo nang eksakto sa puntong ito. Gayundin ang isang pinutol na field na iniwan ng isang naantala na pagsulat.

Ihambing ang rekord sa sertipikong tinutukoy nito at hindi sa file ng ibang CA. Ang pinirmahang sertipiko ang awtoridad sa kung ano ang dapat sabihin ng validity, at mayroon na itong bilang object na maaaring i-parse.

Ayusin ang rekord ayon sa pinirmahang sertipiko

Basahin ang tunay na mga petsa gamit ang openssl x509 -in issued.pem -noout -dates -serial -subject. I-convert ang notAfter sa lapad ng timestamp na isinusulat ng build mo para sa taong iyon, at kumpirmahin na ang serial number ay tumutugma sa entry na iyong i-edit bago ka magpalit ng isang karakter.

I-edit lamang ang sirang field, panatilihin ang letra ng estado at ang serial number, at iwanan ang natitirang bahagi ng linya. Kung ang rekord ay hindi ma-reconcile sa anumang pinirmahang sertipiko, ituring ito bilang ligaw na entry at iretiro ito sa sariling landas ng pagbawi ng CA sa halip na burahin ang linya sa kamay.

Huwag ayusin sa pamamagitan ng pagputol ng petsa upang umangkop sa isang hula tungkol sa taon. Ang pagputol ng dalawang karakter ay hindi portable sa pagitan ng mga build, at tahimik nitong binabago ang validity na iniuulat ng database sa mga susunod na pagsusuri ng duplicate na subject at CRL. Kapag ang orihinal na halaga ay hindi na mababawi, muling mag-isyu sa ilalim ng bagong serial number at isulat kung bakit inabandona ang luma. Ang audit trail ay bahagi ng pag-aayos, hindi papeles sa paligid nito.

I-verify ang pag-isyu at pagbuo ng CRL bago ka umalis

Magpatakbo ng isang pag-isyu gamit ang parehong configuration at kumpirmahing natatapos ito nang walang reklamo sa numero ng linya. Pagkatapos ay bumuo ng CRL gamit ang openssl ca -gencrl -config openssl.cnf at tingnan kung ito ay na-parse, dahil ang nasirang rekord ay madalas na lumilitaw doon at hindi habang pumipirma.

Suriin ang bagong sertipiko gamit ang openssl x509 -noout -dates -serial at ihambing ito sa linyang isinulat lang ng CA. Kumpirmahin na ang letra ng estado at ang petsa ng pag-expire ay sumasang-ayon sa sertipiko, at kumpirmahin na openssl verify -CAfile ca.pem issued.pem ay bumabalik nang walang error. Pagkatapos ay ibalik ang naka-iskedyul na pag-isyu at panoorin ang unang pagtakbo, dahil ang ikalawang depektibong linya ay agad na magpapahayag ng sarili nito.