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

Երկու սեղմում, երկու բոլորովին տարբեր արտեֆակտ։

Կարդացեք արտահանման երկխոսությունը, ոչ թե ֆայլի վերջավորությունը

DER կամ PEM վկայագրի արտահանումը պարունակում է հանրային բանալի և ստորագրված ինքնության պնդումներ, ինչը սերվերին պետք է ձեզ վստահելու համար, իսկ հաճախորդին՝ սերվերը ստուգելու համար։ PKCS#12 փաթեթը տարա է, որը կարող է պարունակել վկայագիր, դրա շղթան և համապատասխան գաղտնի բանալին՝ պաշտպանված գաղտնաբառով, թեև այն կարելի է ստեղծել նաև առանց բանալու։

PEM-ը միայն տեքստային կոդավորում է, ոչ թե խոստում բովանդակության մասին։ Նույն վերջավորությունը կարող է նկարագրել մեկ վկայագիր կամ մի քանի պիտակավորված բլոկ ունեցող ֆայլ, և արտահանման ընտրանքներն են որոշում, թե որն է։

Այսպիսով, օգտակար հարցը երբեք այն չէ, թե որ ընդլայնումն եք ստացել, այլ այն, թե ինչ բլոկներ կան ֆայլում։ Առանց բանալու արտահանված փաթեթը դեռ փաթեթ է։ Ստուգեք բովանդակությունը, ոչ թե ձևաչափի ժողովրդականությունը։

Ուսումնասիրեք, թե ինչ եք իրականում ստացել

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

grep -E 'BEGIN (CERTIFICATE|PRIVATE KEY|ENCRYPTED PRIVATE KEY)' bundle.pem
openssl x509 -in client.crt -noout -subject -issuer -dates
openssl pkey -in client.key -noout -text | head -5
openssl pkcs12 -info -in client.p12 -noout

Միայն վկայագրի բլոկով արտահանումը հանրային օբյեկտ է և չի կարող նույնականացվել։ Առանց վկայագրի բանալու բլոկը ձեզ թողնում է առանց այն շղթայի, որը սերվերը սպասում է։ PKCS#12-ի տեղեկատվական ելքը նաև հաղորդում է՝ բանալի կա արդյոք, ինչը լուծում է այդ ձևաչափի հարցը։ Այն նաև նշում է ալգորիթմը և բանալու չափը, և ամբողջությամբ ձախողվում է, երբ բանալի չկա։

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

Բանալին կարող է լինել այնտեղ, որտեղից չեք կարող պատճենել

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

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

Պատճենելու փոխարեն գրանցեք նոր ինքնություն

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

Ստուգեք՝ նույնականացվելով ներմուծված ինքնությամբ, ոչ թե դիտելով ներմուծման հաջողությունը։ Հաճախորդը, որը հանրային վկայագիր է ընդունում իր պահոցում, բանալու մասին ոչինչ չի ապացուցել։

Ավարտեք՝ հաստատելով, որ սերվերն ընդունում է նոր ինքնությունը և որ հինը դեռ վարվում է այնպես, ինչպես նախատեսում է քաղաքականությունը։ Այսպիսով շրջայցը եզրափակվում է ապացույցով, ոչ թե ճիշտ թվացող ֆայլով։

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