strongSwan: բանալու տեսակը, բեռնիչը և սխալ backend

Ֆայլերի ընդլայնումները չեն նույնականացնում բանալու ալգորիթմները, և .pem պատյանը կարող է պարունակել RSA կամ ECDSA նյութ։ PEM-ը նկարագրում է, թե ինչպես են բայթերը փաթաթվում, մինչդեռ RSA-ն և ECDSA-ն տարբեր ալգորիթմներ են անվանում, իսկ PKCS12 ֆայլը երրորդ բանն է։ strongSwan-ը բեռնում է հավատարմագրերը plugin-ների և կարգավորման backend-ի միջոցով, ուստի վկայագիրը կարող է հայտնվել ցանկում, մինչդեռ մասնավոր բանալին երբեք օգտագործելի չի դառնում։ Առանձնացրեք այդ շերտերը ցանկացած գաղտնիք խմբագրելուց առաջ։

Կոդավորումը, ալգորիթմը և փաթեթավորումը երեք շերտ են

Բանալու ֆայլն ունի կոդավորում, ալգորիթմ և հաճախ տարա։ PEM-ը ծանոթ base64 պատյանն է, DER-ը՝ դրա երկուական համարժեքը, PKCS12-ը միավորում է վկայագիրն իր բանալու և շղթայի հետ։ Վկայագրերի շղթայի ֆայլը ևս մեկ տարա է և սովորաբար ընդհանրապես մասնավոր բանալի չի պարունակում։ Այս պիտակներից ոչ մեկը չի ասում՝ ներսի նյութը RSA է, թե ECDSA։

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

Համեմատեք հանրային բանալիները, նախքան բեռնիչին մեղադրելը

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

openssl x509 -in server.crt -pubkey -noout |
    openssl pkey -pubin -outform DER |
    openssl dgst -sha256

openssl pkey -in server-key.pem -pubout -outform DER |
    openssl dgst -sha256

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

Հին ipsec.secrets կամ swanctl հավատարմագրեր

strongSwan-ն ունի հավատարմագրերի երկու սովորաբար օգտագործվող ուղի։ Հին starter կույտը կարդում է տիպին հատուկ գրառումներ ipsec.secrets-ից, և յուրաքանչյուր գրառում պետք է նշի նյութի ճիշտ տեսակը։ swanctl և vici կույտը բանալիները բեռնում է իր հավատարմագրերի գրացուցակից իր սեփական կարգավորմամբ։ Փոփոխելով այն ֆայլը, որը գործող backend-ը չի կարդում, ոչինչ չի փոխվում։

: ECDSA "/etc/ipsec.d/private/server-key.pem"

Պարզեք, թե որ backend-ն է իրականում աշխատում, ապա տեղադրեք բանալին այնտեղ, որտեղ նայում է այդ backend-ը։ strongSwan 5.9 հին ձեռնարկը սահմանում է տիպին հատուկ գաղտնիքների գրառումները, և սա swanctl փաստաթղթեր չեն։ Երկուսը խառնելը ստեղծում է daemon, որը անտեսում է մի ֆայլ, որը ադմինիստրատորը համարում է հեղինակավոր։ Վերբեռնումը, որը սխալ չի հաղորդում, միայն նշանակում է, որ կարգավորումը վերլուծվել է։

Կարդացեք բեռնման իրադարձությունը և նույնականացման արդյունքը

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

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