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

Վստահությունն ապրում է սերվերում, ոչ թե ձեր պրոֆիլում

Վկայականով նույնականացումը համեմատություն է։ Հաճախորդը ներկայացնում է վկայական. դարպասը ստուգում է՝ արդյոք այն ստորագրվել է իր կազմաձևի CA-ներից մեկի կողմից։

Ձեր պրոֆիլը նշում է CA ֆայլը, որը հաճախորդը պետք է օգտագործի սերվերը ստուգելու համար։ Այն չի կարող նշել CA, որը սերվերը պետք է օգտագործի ձեզ ստուգելու համար։ Կազմաձևի այդ կեսը ձերը չէ։

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

Ինչու ինքնաստորագրված վկայականը չի կարող փոխարինել

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

Դարպասը չի հարցնում՝ արդյոք վկայականը ներքին համահունչ է։ Այն հարցնում է՝ արդյոք վստահելի թողարկողը ստորագրել է այն։

Այդ պատճառով սխալի հաղորդագրությունները շփոթեցնում են։ Հաճախորդը կարող է հայտնել ստուգման ձախողման մասին, որը հնչում է որպես սերվերի խնդիր, մինչ սերվերը գրանցում է անհայտ թողարկող։ Երկուսն էլ նկարագրում են նույն անհամապատասխանությունը հակադիր ծայրերից։

CSR ուղին պահպանում է ձեր մասնավոր բանալին

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

openssl req -new -newkey rsa:3072 -nodes -keyout client.key -out client.csr -subj "/CN=laptop-01"

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

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

Փաթեթները ներմուծվում են, ոչ թե տեղադրվում

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

Վարման կանոնը բխում է բովանդակությունից։ Եթե պրոֆիլը ներկառուցում է մասնավոր բանալի, դա վկայաթուղթ է և արժանի է նույն հոգատարությանը, ինչ գաղտնաբառը. ոչ էլ. փոստ, ոչ պահոց, ոչ ընդհանուր ներբեռնումների թղթապանակ։ Երբ օպերատորը տրամադրում է ca.crt, client.crt և client.key առանձին, պահեք դրանք միասին սահմանափակ թույլտվություններով և ուղղեք պրոֆիլը դեպի դրանք։

Ավելացրեք այն ստուգումները, որոնք օպերատորը կարող էր բաց թողնել

Երթուղիչով ստեղծված պրոֆիլը երբեմն զուրկ է գործընկերոջ ստուգումից։ remote-cert-tls server պահանջում է, որ գործընկերոջ վկայականը կրի սերվերի նույնականացման նպատակը, որպեսզի հաճախորդի վկայականը հնարավոր չլինի կրկնարկել որպես սերվեր։ Այդ մեկ տողը փոքր փոփոխություն է՝ հստակ հիմնավորմամբ։

verify-x509-name ավելի հեռուն է գնում, երբ օպերատորը կարող է նշել սպասվող սուբյեկտը կամ SAN-ը։ Երկուսն էլ փոքր հավելումներ են պրոֆիլին, և երկուսն էլ պաշտպանելի են։ Ստուգեք, թե ինչ եք ստացել, նախքան ներմուծելը։

openssl x509 -in client.crt -noout -issuer -subject -dates
openssl verify -CAfile ca.crt client.crt

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

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

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