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 վերադառնում է առանց սխալի։ Այնուհետև վերականգնեք պլանավորված թողարկումը և հետևեք առաջին գործարկմանը, քանի որ երկրորդ աղավաղված տողն անմիջապես կհայտարարի իրեն։