VPN վկայագրի թարմացում՝ առանց դրա ինքնությունը փոխելու

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

Երեք պայման որոշում են թարմացման ձևը

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

Սկսեք ձեր ունեցած վկայագրի ստուգմամբ։ openssl x509 -in server.crt -noout -subject -issuer -dates -ext subjectAltName տպում է սուբյեկտը, թողարկողին, վավերականության պատուհանը և այն անունները, որոնց համար վկայագիրն իրականում վավեր է։ Այդ վերջին դաշտը ամենակարևորն է և ամենից հաճախ ենթադրվում է՝ թարմացման հայտ, որը բաց է թողնում հաճախորդի վրա հենված SAN-ը, ստեղծում է տեխնիկապես վավեր, բայց ֆունկցիոնալ առումով սխալ վկայագիր։ Պատճենեք SAN-ների ցանկը հին վկայագրից հայտի մեջ՝ հիշողությունից նորից մուտքագրելու փոխարեն։

Առաջին պայման՝ ինչ-որ բան ամրացնում է տերևը

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

Պարզեք, թե որ դեպքում եք, նախքան որևէ բան պատվիրելը։ Փաստաթղթավորված չլինելը ամրացումը չի դադարում ամրացում լինելուց, երբ այն կոտրվում է։

Երկրորդ պայման՝ համեմատեք ամրացումները և շղթան

Մատնահետքերը ամրացումը ստուգելի են դարձնում՝ openssl x509 -noout -fingerprint -sha256 -in server.crt հին և նոր վկայագրի վրա, և openssl x509 -noout -pubkey հանրային բանալիները համեմատելու համար։ Եթե հաճախորդի կարգավորումը, բջջային պրոֆիլը կամ սարքի վստահության պահոցը պարունակում է այդ արժեքներից որևէ մեկը, դուք ամրացում ունեք։ Բջջային VPN պրոֆիլները թաքնվելու սովորական վայր են, քանի որ պրոֆիլը տարածվում է մեկ անգամ և այլևս երբեք չի ստուգվում։

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

Ստուգեք այն շղթան, որ սերվերն իրականում ուղարկում է՝ օգտագործելով openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts, և տեղային վավերացրեք այն՝ օգտագործելով openssl verify -CAfile ca.pem -untrusted chain.pem server.crt։ Դա փոփոխությունից առաջ անելը ձեզ ելակետ է տալիս հետագա համեմատության համար։

Երրորդ պայման՝ ով էլ է ստուգում անունը

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

Թվարկեք յուրաքանչյուր սպառողի փոփոխությունից առաջ և յուրաքանչյուրի համար որոշեք՝ արդյոք նրան թարմացում է պետք։ Նա, ում մոռանաք, նա է, ով կկանչի ձեզ։

Կա նաև ժամանակի թակարդ։ Ստուգեք վավերականության սկիզբը, ինչպես նաև ավարտը, քանի որ ավելի ուշ ակտիվացման համար նախապատրաստված վկայագիրը մերժվում է, եթե տեղադրվում է շատ շուտ, և սխալը նման է ժամացույցի խնդրի, այլ ոչ թե նախապատրաստման խնդրի։ Նոր ֆայլի վրա openssl x509 -noout -dates-ը տեղադրելուց առաջ երկու վայրկյանանոց ստուգում է։ Պահպանեք նաև աջակցվող վերականգնման ուղի և հայտնի լավ կոնֆիգուրացիա, որպեսզի սխալ ընթացող թարմացումը հնարավոր լինի հետ շրջել՝ վերականգնելով նախորդ վկայագիրն ու բանալին։

Տեղադրեք, ստուգեք նոր նույնականացմամբ, ապա դուրս բերեք

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

Ավարտեք հավելվածի մակարդակի այն ստուգումը, որը կարևոր է օգտվողին, և հաստատեք շղթայի հանձնումը հաճախորդի, այլ ոչ թե սերվերի տեսանկյունից։ Մի՛ ճնշեք անվան կամ վկայագրի ստուգումները՝ անցումը հանգիստ պահելու համար, դա ժամանակավոր համատեղելիության խնդիրը վերածում է մշտականի։

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