Նախքան այն փոխարկելը՝ SSH բանալի ընդդեմ OpenVPN վկայագրի

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

Ո՞ր օբյեկտն ունեք իրականում։

Հինգ բան կա, որ մարդիկ բանալի են անվանում, և դրանցից միայն մեկն է այն, ինչ ուզում է TLS պրոֆիլը։ SSH հանրային բանալին մեկ տող տեքստ է՝ տիպի նախածանցով և base64 բովանդակությամբ։ OpenSSH վկայագիրն այդ բանալին է՝ գումարած ստորագրություն, principals և ընտրանքներ, որոնք արտադրում է ssh-keygen-ը՝ հանդես գալով որպես իր փոքրիկ CA։ X.509 վկայագիրը բոլորովին այլ կառուցվածք է՝ կրում է սուբյեկտ, վավերականության պատուհան, ընդլայնումներ և վկայագրային մարմնի ստորագրություն։ Մասնավոր բանալին գաղտնի կեսն է, իսկ թողարկված փաթեթը սովորաբար վկայագիրն է՝ գումարած դրա շղթան և մասնավոր բանալին մեկ ֆայլում։

Առաջին փորձությունը մեկ հրահանգ արժե։ Ուղղեք openssl-ը ֆայլին և խնդրեք վերլուծել վկայագրի կառուցվածքը՝

openssl x509 -in client.crt -noout -subject -issuer

Եթե դա ձախողվի unable-to-load կամ PEM սխալով, ապա ֆայլը X.509 վկայագիր չէ, ինչ անուն էլ տվել եք։ Վերանվանումը չի վերագրում ներսի ASN.1-ը, և դա չի անում նաև հանրային բանալու տողը PEM վերնագրի տեքստում փաթաթելը։

Արդյո՞ք պրոֆիլը ընդհանրապես վկայագիր է պահանջում։

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

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

Ինչ կարող և ինչ չի կարող անել վերակոդավորումը

Մասնավոր բանալիներն իսկապես ունեն օրինական այլընտրանքային տարաներ։ Նույն RSA կամ EC բանալին կարելի է գրել որպես ավանդական PEM, որպես PKCS#8 կամ PKCS#12 փաթեթի ներսում, և գործիքները հաճույքով փոխարկում են դրանց միջև։ Հանրային բանալիներն ունեն նման պատմություն՝ ssh-keygen-ը կարող է արտածել SSH բանալու RFC 4716 ձևը, և OpenSSH-ը հասկանում է նաև իր սեփական վկայագրի ձևաչափը։ Այս ամենը ներկայացում է, և ներկայացումը վստահություն չէ։

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

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

Որտեղ է վկայագրային մարմինը մտնում պատկերի մեջ

Իսկական գրանցումը սկսվում է ձեր վերահսկողության տակ գտնվող բանալու զույգով և վկայագրի ստորագրման հայտով, որը կրում է օպերատորի սպասած սուբյեկտը։ Օպերատորը ստուգում է իրավունքը, ստորագրում հայտը CA բանալիով և վերադարձնում թողարկված վկայագիրը ցանկացած միջանկյալ շղթայի հետ, որը հաճախորդը պետք է ներկայացնի։ Այնուհետև հաճախորդին անհրաժեշտ է այն CA վկայագիրը, որը ստորագրել է այն, որովհետև հենց դա է թույլ տալիս հաստատել, որ սերվերը, որի հետ խոսում է, նույն տեղաբաշխմանն է պատկանում։

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

Ինչ արժե ձեզ SSH բանալու վերօգտագործումը

Ենթադրենք՝ փոխարկումն իսկապես ինչ-որ ընդունելի բան արտադրեց։ Մեկ բանալու զույգի վերօգտագործումը և՛ SSH մուտքի, և՛ VPN նույնականացման համար դեռ կապում է երկու անկախ անվտանգության որոշում։ authorized_keys-ի գրառման հեռացումը դադարեցնում է SSH մուտքերը և ոչինչ չի անում այն վկայագրին, որը VPN-ի CA-ն արդեն թողարկել է նույն հանրային բանալու համար։ VPN կողմը չեղարկվում է իր սեփական մեխանիզմով, այսինքն՝ վկայագրերի չեղարկման ցուցակով կամ օպերատորի գրանցման գրառումով։

Այսպիսով՝ ստուգաթերթը վերջանում է կանգառի պայմանով, ոչ թե հնարքով։ Եթե openssl-ը ֆայլը վկայագիր չվերլուծի, դադարեցրեք փոխարկումը և նկարագրեք, ինչ ունեք՝ SSH բանալի, SSH վկայագիր, X.509 վկայագիր, մասնավոր բանալի կամ փաթեթ։ Եթե պրոֆիլը հաճախորդի վկայագիր չի պահանջում, կանգ առեք և հարցրեք, թե ինչ նույնականացման մեթոդ է սպասում սերվերը։ Միայն այն ժամանակ, երբ երկու պատասխաններն էլ ցույց են տալիս X.509-ին, գրանցումը դառնում է հաջորդ քայլը, և այդ զրույցը շատ ավելի արագ է ընթանում առաջին նախադասության մեջ ճիշտ գոյականով։