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 се враќа без грешка. Потоа вратете го закажаното издавање и набљудувајте го првото извршување, зашто втора деформирана линија веднаш ќе се најави.