Ինչպես ստեղծել VPN հաճախորդի բանալի և CSR ներկայացնել ստորագրման

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

Քայլ 1: ստեղծեք բանալին այնտեղ, որտեղ այն կապրի

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

Ծրագրային ընթացքն այսպիսի տեսք ունի՝ բանալին և հարցումը ստեղծվում են մեկ նստաշրջանում:

umask 077
openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:3072 -out client.key
openssl req -new -key client.key -out client.csr -subj "/CN=alice-vpn/O=Example"

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

Քայլ 2: ինքնությունը դրեք հարցման մեջ, ոչ էլփոստում

Որոշեք, թե VPN-ն իրականում ինչն է վավերացնում, մինչև հարցումը ստեղծվելը, որովհետև այդ պատասխանը պատկանում է CSR-ի ներսում։ OpenVPN ավանդաբար հաճախորդի ինքնությունը կապում է վկայագրի ընդհանուր անվան հետ, և strongSwan-ի նման գործիքները ինքնության տողը համեմատում են սուբյեկտի կամ սուբյեկտի այլընտրանքային անվան հետ։ Էլփոստը, որն ասում է՝ իմ անունը alice է, ապացույց չէ, և հարցումը, որի սուբյեկտն ասում է նույնը, միայն մի փոքր ավելի լավն է։

Ավելացրեք սուբյեկտի այլընտրանքային անուն, երբ ձեր ստուգիչը մեկը ստուգում է, քանի որ ժամանակակից համեմատությունը հաճախ անտեսում է հին CN-ը:

openssl req -new -key client.key -out client.csr \
  -subj "/CN=alice-vpn/O=Example" \
  -addext "subjectAltName=DNS:alice-vpn"

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

Քայլ 3: ստուգեք հարցումը մինչև ստորագրելը

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

Մեխանիկական մասը մեկ հրաման է, և այն պետք է տպի ստուգման արդյունքը սուբյեկտի հետ միասին:

openssl req -in client.csr -noout -verify -subject
openssl req -in client.csr -noout -pubkey | openssl pkey -pubin -noout -text

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

Քայլ 4: լիազորեք, ապա ստորագրեք հստակ ընդլայնումներով

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

cat > client.ext <<'EOF'
basicConstraints = CA:FALSE
keyUsage = digitalSignature
extendedKeyUsage = clientAuth
EOF
openssl x509 -req -in client.csr -CA ca.crt -CAkey ca.key \
  -CAcreateserial -days 365 -extfile client.ext -out client.crt

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

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

Քայլ 5: տեղադրեք այն համապատասխան բանալու կողքին և ապացուցեք զույգը

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

openssl x509 -in client.crt -noout -pubkey | openssl pkey -pubin -outform DER | openssl sha256
openssl pkey -in client.key -pubout -outform DER | openssl sha256

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