Ոչ ոք չի դիպչել պրոֆիլին, բայց նույն հաճախորդը այժմ ամեն գործարկման ժամանակ պահանջում է գաղտնաբառ մասնավոր բանալու համար։ Երբ այդ փոփոխությունը տեղի է ունենում բաշխման թարմացումից մի քանի օր հետո, թարմացումն է հավանական պատճառը՝ OpenSSL 3-ը վերակազմավորեց իր ալգորիթմների աջակցությունը, և բանալին, որը հին գրադարանը հեշտությամբ կարդում էր, կարող է դառնալ անընթեռնելի՝ առանց նույնիսկ մեկ բայթ փոխելու։ Կատարեք ստուգումները հերթականությամբ, որովհետև դրանցից երկուսը նույնական են թվում, եթե նայեք միայն հարցմանը։

Առաջին հարցն այն է՝ արդյոք բանալին գաղտնագրված է, իսկ երկրորդը՝ արդյոք այս կառուցումը կարող է վերծանել այն։ Կազմաձևի փոփոխությունները իմաստ ունեն միայն այն ժամանակ, երբ հայտնի են երկու պատասխանները։

Ստուգեք՝ արդյոք բանալին գաղտնագրված է

Կարդացեք ֆայլի առաջին տողը և հետո թույլ տվեք գրադարանին վերլուծել այն, որովհետև ֆայլի անունը ոչինչ չի ապացուցում։ PEM բլոկը՝ ENCRYPTED PRIVATE KEY պիտակով գաղտնագրված PKCS#8 է, իսկ ավելի հին RSA PRIVATE KEY բլոկը՝ Proc-Type: 4,ENCRYPTED պիտակով, ավանդական ձևն է, և երկուսն էլ գաղտնաբառ են սպասում։ Չգաղտնագրված PRIVATE KEY բլոկը ընդհանրապես չպետք է պահանջի այն։ Կատարեք վերլուծությունը այն հաշվով, որին պատկանում է ֆայլը, որովհետև թույլտվության խնդիրը տալիս է այլ և շատ ավելի քիչ հետաքրքիր սխալ։

Եթե բանալին իսկապես գաղտնագրված չէ, բայց հաճախորդը դեռ հարցնում է, դադարեք նայել գաղտնագրությանը և ստուգեք՝ արդյոք պրոֆիլը նշում է askpass ֆայլ, որը ծառայությունը դեռ կարող է կարդալ։

Ստուգեք՝ արդյոք այս կառուցումը կարող է վերծանել այն

OpenSSL 3-ը իր ալգորիթմների աջակցությունը բաժանեց մատակարարների, և հին ծածկագրերի մի շարք այժմ գտնվում է legacy մատակարարում, ոչ թե լռելյայնում։ Այդ ծածկագրերից մեկով գաղտնագրված բանալին մնում է վավեր, սակայն առանց legacy մատակարարի բեռնված գրադարանը չի կարող վերծանել այն։ Որոշ հաճախորդներում դա երևում է որպես կրկնվող հարցում, մյուսներում՝ որպես կոշտ ձախողում գաղտնաբառից անմիջապես հետո։

Վերլուծեք նույն բանալին երկու անգամ նույն բինարով՝ սկզբում միայն լռելյայն մատակարարով, ապա legacy-ով և լռելյայնով՝ երկուսն էլ հրամանի տողում պահանջելով։ Եթե երկրորդ փորձը հաջողվում է այնտեղ, որտեղ առաջինը ձախողվեց, ախտորոշումը հիմնված է ապացույցի վրա, ոչ թե թարմացման ժամանակի։ Եթե երկուսն էլ ձախողվում են նույնությամբ, գաղտնաբառը սխալ է կամ ֆայլը վնասված է, և ոչ մի մատակարարի կարգավորում չի ուղղում դրանցից ոչ մեկը։

Ստուգեք ամենանեղ հասանելի ուղղումը

Նախընտրեք հաճախորդով սահմանափակված փոփոխությունը համակարգայինից։ Որոշ 2.6 կառուցումներ ընդունում են պրոֆիլի ընտրանք, որը բեռնում է երկու մատակարարներն էլ այդ դեյմոնի պրոցեսի համար, ուստի նախքան դրա վրա հենվելը հաստատեք հրահանգը ձեր ճշգրիտ տարբերակի ձեռնարկում, փոխարենը համակարգի openssl.cnf ֆայլը խմբագրելը ազդում է հոսթի բոլոր OpenSSL ծրագրերի վրա։ Ավելի նեղ կարգավորումը նաև շատ ավելի հեշտ է հետարկել բանալին վերակոդավորելուց հետո։

Մի՛ ջնջեք գաղտնաբառը, որպեսզի հարցումը անհետանա։ Դա պաշտպանված հավատարմագրերը վերածում է բաց տեքստի ֆայլի և լուռ փոխում է յուրաքանչյուր պահուստի, պատճենի և աջակցության փաթեթի ռիսկը, որտեղ այն հայտնվում է։ Կարևոր տարբերությունն այն բանալու միջև է, որն իր գաղտնաբառի կարիքն ունի, և այն բանալու, որը այս գրադարանը չի կարող վերծանել։

Ստուգեք ծառայության համատեքստը, ապա վերակոդավորեք

Երբ բանալին հնարավոր լինի բացել, կրկին գաղտնագրեք այն ժամանակակից ալգորիթմով որպեսզի կախվածությունը վերանա։ Գրեք նոր ֆայլը ժամանակակից ծածկագրով, ստուգեք, որ այն վերլուծվում է, թարմացրեք պրոֆիլը և պահեք հին պատճենը միայն մինչև կապի հաջողությունը։ Երբեք մի դրեք գաղտնաբառը հրամանի տողում, որտեղ ցանկացած տեղական օգտատեր կարող է կարդալ այն պրոցեսների ցանկից։ Հեռացրեք հին ֆայլը միայն այն բանից հետո, երբ նորը միացել է ծառայության հաշվից, ոչ միայն ձեր shell-ից։

Այնուհետև ստուգեք այն միավորը, որն իրականում գործարկում է հաճախորդը։ Ձեր shell-ում ընթեռնելի բանալին կարող է անընթեռնելի լինել այլ հաշվով կամ կարծրացված տնային թղթապանակի կարգավորումով աշխատող ծառայության համար։

Գրանցեք մատակարարի կարգավորումը պրոֆիլի կողքին և պահեք երկու հրամանի թեստը դրա հետ։ Երբ ավելի ուշ թարմացումը հեռացնի legacy մատակարարին, կրկին գործարկեք այդ թեստը՝ տեսնելու համար՝ արդյոք բանալուն դեռ դա է պետք, թե պրոֆիլը կարելի է հանել ժամանակավոր լուծումից։

Հարցումը ախտանիշ է առնվազն երեք պատճառով, և դրանցից միայն մեկն է բացակայող գաղտնաբառը։

Առնչվող հոդվածներ