openssl ca: несапраўдная дата заканчэння ў index.txt і як яе выправіць

Прагон выпуску спыняецца на 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 вяртаецца без памылкі. Затым аднавіце планавы выпуск і паназірайце за першым прагонам, бо другі пашкоджаны радок абвясціць пра сябе адразу.