Издавање се зауставља на entry 22: invalid expiry date, а захтев пред вама је потпуно исправан. Притужба долази од рашчлањивача базе података CA, не од CSR-а и не од VPN клијента који ће на крају представити сертификат. Та разлика одређује све што следи: запис је деформисан, па поправка припада стању CA, а не захтеву или конфигурацији партнера. Нумерисани запис третирајте као линију у index.txt, и проблем се своди на ограничено питање о подацима са проверљивим одговором.

Читајте грешку као притужбу на базу података

Сваки openssl ca позив пролази кроз своју текстуалну базу пре него што било шта потпише. Свака линија носи слово стања, временски жиг истека, опциони жиг опозива, серијски број у хексадецималном облику, назив датотеке и субјекат. Када се једно поље не може рашчланити, команда пријављује број линије и зауставља се уместо да погађа остатак записа.

То заустављање је заштитно, а не педантно. Запис који алат не може да прочита оставља га без могућности да одлучи да ли тражени субјекат већ постоји, да ли је серијски број додељен или шта следећи CRL треба да садржи. Наставак преко лоше линије произвео би управо ону тиху недоследност која избија месецима касније, обично током опозива који нико не може да објасни. Читајте поруку као притужбу на податке, и истрага остаје унутар директоријума CA.

Копирајте стање CA пре него што било шта дотакнете

Направите снимак целог директоријума CA, не само датотеке базе. Индекс, његова датотека атрибута, датотеке серијског броја и броја CRL-а, приватни кључ и издати сертификати сви учествују у каснијим операцијама, а поправка која враћа једно, а прескаче остало ствара други инцидент. Где постоји, користите сопствену рутину за резервну копију CA, и паузирајте планирано издавање током трајања посла.

Забележите градњу OpenSSL-а и конфигурациону датотеку које је неуспела команда стварно учитала. Инсталације често држе више од једног директоријума CA, а грешка има смисла само према бази коју наводи изабрана конфигурација.

Пронађите запис и декодирајте његово поље датума

Пријављени број линије броји се од првог записа, па sed -n '22p' index.txt пада на проблематични запис када потврдите да изнад њега нема празних линија ни коментара. Одштампајте ту линију са видљивим раздвајачима, јер су табулатори и размаци на крају чести и невидљиви у обичном прозору уређивача.

Поље истека је временски жиг чија ширина зависи од године. Вредности до 2049 записују се у UTCTime као YYMMDDHHMMSSZ, док касније вредности прелазе на GeneralizedTime са четвороцифреном годином. Запис који меша два облика, или носи двоцифрену годину тамо где рашчлањивач сада очекује четири, пада управо на овом месту. Исто важи и за одсечено поље које је оставило прекинуто писање.

Упоредите запис са сертификатом на који се односи, а не са датотеком другог CA. Потписани сертификат је ауторитет за то шта важење треба да каже, и он већ постоји као објекат који се може рашчланити.

Поправите запис према потписаном сертификату

Прочитајте стварне датуме помоћу openssl x509 -in issued.pem -noout -dates -serial -subject. Претворите notAfter у ширину жига коју ваша градња пише за ту годину, и пре него што промените иједан знак потврдите да се серијски број поклапа са записом који ћете уређивати.

Уређујте само покварено поље, задржите слово стања и серијски број, а остатак линије оставите на миру. Ако запис не може да се усклади ни са једним потписаним сертификатом, третирајте га као залутали запис и повуците га сопственим путем опозива CA, уместо да линију бришете ручно.

Не поправљајте тако што ћете скратити датум да би одговарао претпоставци о години. Рез од два знака није преносив међу градњама и тихо мења важење које база пријављује будућим проверама дупликата субјекта и CRL-а. Када се изворна вредност не може повратити, поново издајте под новим серијским бројем и запишите зашто је стари напуштен. Ревзијски траг је део поправке, а не папирологија око ње.

Проверите издавање и генерисање CRL-а пре него што одете

Покрените једно издавање са истом конфигурацијом и потврдите да се завршава без притужбе на број линије. Затим генеришите CRL помоћу openssl ca -gencrl -config openssl.cnf и проверите да се може рашчланити, јер оштећени запис често избије управо тамо, а не током потписивања.

Прегледајте нови сертификат помоћу openssl x509 -noout -dates -serial и упоредите га са линијом коју је CA управо написала. Потврдите да се слово стања и датум истека слажу са сертификатом, и потврдите да openssl verify -CAfile ca.pem issued.pem враћа без грешке. Затим вратите планирано издавање и посматрајте прво покретање, јер ће се друга деформисана линија одмах најавити.

Повезани чланци