PKCS12, PEM թե DER՝ ինչ է իրականում անհրաժեշտ VPN հաճախորդին
Փաթեթավորումը որոշում է՝ հաճախորդը կներմուծի ինքնությունը, թե ոչ, այլ ոչ թե այն վստահելի է։ Համեմատեք PKCS12-ը, PEM-ը և DER-ը, ապա ստուգեք։
Վկայագրերի շուրջ քննարկումներում երկու պնդում է շրջանառվում։ Առաջինը՝ .p12-ը ուժեղ տարբերակն է, իսկ .pem-ը՝ թույլը, երկրորդը՝ տեքստային ֆայլը պետք է անվտանգ լինի ուղարկելու համար, քանի որ կարող եք կարդալ այն։ Ոչ մեկը մեկ րոպե ստուգում չի դիմանում։
PKCS12-ը, PEM-ը և DER-ը նկարագրում են, թե ինչպես են վկայագրային օբյեկտները փաթեթավորվում և կոդավորվում։ Դրանք չեն որոշում, թե ով է մյուս կողմը, արդյոք թողարկողին վստահում են, կամ արդյոք ֆայլին գաղտնաբառ է պետք։
Այն, ինչ հաճախորդը ընդունում է, համատեղելիության հարց է։ Այն, ինչ պարունակում է ֆայլը, ինքնության հարց է։ Առանձնացրեք դրանք, և ներմուծման սխալների մեծ մասը կդադարի առեղծված լինելուց։
Երեք բեռնարկղ, մեկ օբյեկտի մոդել
Սկսեք նրանից, ինչ իրականում ունեք։ Վկայագիրը ստորագրված հայտարարություն է հանրային բանալու մասին։ Մասնավոր բանալին առանձին նյութ է, որն ապացուցում է, որ դուք վերահսկում եք այդ բանալին։ Շղթան թողարկողների ամբողջությունն է, որոնք ձեր վկայագիրը կապում են արմատի հետ, որին վստահում է հաճախորդը։ Երեքն էլ գոյություն ունեն անկախ փաթեթավորումից։
PKCS12 ֆայլը, սովորաբար .p12 կամ .pfx, RFC 7292-ում սահմանված բեռնարկղ է, որը կարող է կրել մասնավոր բանալի, մեկ կամ ավելի վկայագիր և շղթան մեկ գաղտնաբառով պաշտպանված բլոկում, ինքնությունը անվանող այլանունով։ PEM ֆայլը RFC 7468-ում սահմանված տեքստային շրջանակ է՝ base64 մարմին BEGIN և END տողերի միջև, և մեկ ֆայլը կարող է պարունակել մի քանի բլոկ հաջորդաբար։ DER-ը նույն ASN.1 կառույցների երկուական կոդավորումն է, իսկ PEM մարմինը բառացիորեն base64-ով փաթաթված DER է։
Այդ վերջին նախադասությունն արժե հիշել։ PEM-ը DER-ի վերածելը վերագրում է շրջանակը, ոչ թե բովանդակությունը, իսկ հակառակ փոխարկումը վերադարձնում է սկզբնական բայթերը։
| Container | Can hold | Does not decide |
|---|---|---|
| PKCS12 (.p12, .pfx) | Key, leaf certificate, chain, alias, password | Which root the client trusts |
| PEM (.pem, .crt, .cer) | Any number of base64 blocks | Whether the private key is present |
| DER (.der, .cer) | One binary structure | The object type, whatever the extension says |
Կոդավորումը գաղտնագրում չէ
base64-ը փոխադրման այբուբեն է։ Այն ոչինչ չի թաքցնում, և ցանկացած ոք կարող է վերծանել PEM բլոկը shell-ում։ DER ֆայլը երկուական է և հավասարապես հրապարակային։ Ոչ մի հատկություն պաշտպանություն չէ, և ոչ մեկը չի ենթադրում, որ գաղտնաբառ գոյություն ունի։
Իրական պաշտպանությունը բանալու նյութի մեջ է։ PKCS12 փաթեթը կարող է գաղտնագրել իր բովանդակությունը գաղտնաբառից ստացված բանալիով։ PEM մասնավոր բանալին կարելի է գաղտնագրել հին վերնագրային բլոկով կամ պահել PKCS#8 EncryptedPrivateKeyInfo-ում։ Վկայագիրն ինքնին ոչինչ գաղտնի չի պահում, դրա համար էլ միայն վկայագիր տված արտահանումը հաճախորդին թողնում է առանց նույնականացման հնարավորության՝ ինչ ձևաչափով էլ փաթաթեք այն։
Ընդլայնումը հուշում է, ոչ պայմանագիր։ .cer և .crt վերջացող ֆայլերը հանդիպում են երկու կոդավորումներում էլ, և սարքերը բավական հաճախ են DER վկայագրերը .pem անուններով արտահանում, որ վերջավորությունից գուշակելը կես օր արժենա։ Փոխարենը կարդացեք առաջին բայթերը՝ PEM ֆայլը բացվում է BEGIN տողով, իսկ DER-ը սկսվում է 0x30-ով, քանի որ արտաքին կառույցը SEQUENCE է։
Ինչու է ներմուծումն իրականում ձախողվում
Հաճախորդի սխալի հաղորդագրությունները մի քանի տարբեր խնդիր են սեղմում անվավեր վկայագրի մասին մեկ նախադասության մեջ, ուստի բաժանեք դրանք ըստ պատճառի։ Ամենատարածվածը կոդավորման անհամապատասխանությունն է. PEM վերլուծող հաճախորդը DER ֆայլի վրա վերլուծության սխալ է վերադարձնում, և լուծումը փոխարկումն է, ոչ նոր վկայագիր։ Երկրորդը բացակայող բանալին է, երբ վկայագիրը կարգին է, և ինքնությունը հնարավոր չէ ապացուցել։ Երրորդը շղթան է, երբ առանց միջանկյալ վկայագրի փաթեթը ներմուծման երկխոսության մեջ ճիշտ է թվում և ձախողվում է ձեռքսեղմման ընթացքում։
Գաղտնագրման պարամետրերը չորրորդն են առաջացնում, և այն ճիշտ սխալ գաղտնաբառի տեսք ունի։ Հին սարքերը PKCS12 ֆայլեր արտահանում էին RC2-40 և 3DES-ով, որոնք OpenSSL 3-ը մերժում է, եթե legacy մատակարարը բեռնված չէ։ Սարքից AES-256-CBC և PBKDF2-ով վերաարտահանումը կայուն լուծումն է։ Հին ծածկագրերը հաճախորդի մեքենայի վրա մշտապես միացված թողնելը մեկ ֆայլի համար վատ գործարք է։
Հինգերորդը երկիմաստությունն է։ Երկու բանալի և երկու վկայագիր պարունակող բեռնարկղը, կամ երեք CERTIFICATE բլոկով PEM ֆայլը, հաճախորդին ստիպում է ընտրել, և նրա ընտրությունը հաճախ ուղղակի առաջին տարրն է։ Երբ թունելը բարձրանում է սխալ ինքնությամբ, դա սովորաբար պատճառն է։
Ստուգեք փոխարկելուց առաջ
Կարդացեք կառույցը առանց գաղտնիքներ տպելու։ openssl pkcs12 -in bundle.p12 -info -noout հաղորդում է գաղտնագրման ալգորիթմները և այլանունները՝ ճնշելով բանալու և վկայագրի արտածումը, և openssl-pkcs12 ձեռնարկը փաստաթղթավորում է դրոշակները։ -noout-ը հանելը և -nodes-ը ավելացնելը նախատեսված է այն ֆայլերի համար, որոնք մտադիր եք պահել, ոչ արագ հայացքի համար, քանի որ այն գրում է մասնավոր բանալին բաց տեքստով։
Վկայագրի համար openssl x509 -in cert.pem -noout -subject -issuer -dates պատասխանում է այն, ինչին ներմուծման երկխոսությունը չի պատասխանի, և -ext subjectAltName ավելացնելով՝ ցույց է տալիս այն անունները, որոնց համար վկայագիրն իրականում վավեր է։ Եթե ֆայլը DER է, ավելացրեք -inform DER. այդ մեկ դրոշակը լուծում է unable-to-load սխալների մեծ մասը։
Բանալին վկայագրի հետ համադրելը մեխանիկական աշխատանք է և արժե անել ցանկացած ներմուծումից առաջ։
openssl x509 -in cert.pem -noout -pubkey | openssl sha256openssl pkey -in key.pem -pubout | openssl sha256
Նույնական ամփոփումները նշանակում են, որ զույգը միասին է։ Տարբեր ամփոփումները նշանակում են, որ դուք սխալ բանալի ունեք, և ոչ մի ձևաչափի փոխարկում դա չի փոխի։
Ինչը ձևաչափը երբեք չի փոխում
Վստահության որոշումները կայացվում են բեռնարկղից վեր։ Հաճախորդը անցնում է շղթայով մինչև իր պահոցի արմատը, ստուգում է վավերականության պատուհանը, ստուգում է ընդլայնված բանալու օգտագործումը հաճախորդի նույնականացման համար, և սերվերի կողմում ստուգում է, որ զանգահարած անունը առկա է վկայագրում։ Այս քայլերից ոչ մեկը չի կարդում ֆայլի ընդլայնում։
Դրա համար էլ ֆայլի անունը փոխելը, մինչև սխալը անհետանա, ժամանակ կորցնելու այդքան հուսալի միջոց է։ Ներմուծումը հաջողվում է, ինքնությունը դեռ սխալ է, և ձախողումը նորից ի հայտ է գալիս ձեռքսեղմման ընթացքում, որտեղ հաղորդագրությունն ավելի քիչ օգտակար է։ Դրա համար էլ երկու տարի առաջ արտահանված փաթեթը մաքուր ներմուծվում է և այնուամենայնիվ մերժվում. ժամկետը ճամփորդել է վկայագրի ներսում, ոչ թե ֆայլի անվան մեջ։
Հերթականություն, որը խուսափում է վերամշակումից
Հարցրեք հաճախորդի փաստաթղթերին, թե որ կոդավորումներն է ընդունում և ինչ բեռնարկղ է սպասում հաճախորդի ինքնության համար, ապա նայեք, թե ինչ են ձեզ տվել։ Եթե հաճախորդը ցանկանում է մեկ ներմուծելի ինքնություն, և դուք ունեք առանձին PEM ֆայլեր, կառուցեք փաթեթը մեկ անգամ ձեր վերահսկած գաղտնաբառով և պահեք աղբյուրները։ Եթե PEM է ուզում, հանեք բանալին և շղթան, ապա հեռացրեք միջանկյալ ֆայլերը ձեր թիմի արդեն օգտագործած հավատարմագրերի կառավարման գործընթացով։
Ներմուծումից հետո ստուգեք ինքնությունը, ոչ թե երկխոսությունը. սուբյեկտ, թողարկող, ժամկետ և այն անունը, որը հաճախորդը կներկայացնի։ Ցանկում բարեկամական անունը պիտակ է, ոչ հաստատված ինքնություն։ Եթե հետո թունելը ձախողվի, դուք վրիպազերծում եք նույնականացում կամ երթուղավորում՝ փաթեթավորման փոխարեն, ինչը շատ ավելի կարճ զրույց է։