SSTP վկայագրի անհամապատասխանություն. այն անունը, որը ձեր սերվերը պետք է ներկայացնի
Հաճախորդը համեմատում է պրոֆիլի հոսթի անունը վկայագրի հետ, ապա ստուգում շղթան և նպատակը։ Ուղղեք պրոֆիլը կամ վկայագիրը, երբեք՝ ստուգումը։
SSTP հաճախորդը սերվերն ընդունում է միայն TLS ստուգման հաջողումից հետո, և այդ ստուգումը համեմատում է անուն, շղթա և նպատակ։ Անունը գալիս է միացման պրոֆիլից, ոչ այն հասցեից, որը պատահաբար կարող եք փինգել։ Երբ երեքից մեկը չի համապատասխանում, հաճախորդը հայտնում է վկայագրի խնդրի մասին և երբեք չի հասնում մուտքի հուշմանը։
Պրոֆիլի անունն է որոշում, թե ինչ է ստուգվում
SSTP-ն TLS-ը գործարկում է TCP 443-ի վրա, ուստի հաճախորդը վարվում է ինչպես ցանկացած այլ TLS հաճախորդ՝ վերցնում է հոսթի անունը պրոֆիլից, պահանջում այդ անունը և համեմատում վկայագիրը դրա հետ։ Եթե պրոֆիլում մուտքագրեք IP հասցե, համեմատությունը դառնում է IP հասցեների համեմատություն, որը սերվերի վկայագրերի մեծ մասը չի բավարարում։
Այդ պատճառով զննարկիչի թեստը կարող է հաջողվել, մինչ VPN-ը ձախողվում է, որովհետև զննարկիչն օգտագործել է պրոֆիլից տարբեր անուն։ Նույն բաժանումը երևում է, երբ split-horizon DNS-ը VPN-ի հոսթի անունը լուծում է ներքին հասցեի, մինչ զննարկիչը հասել է հանրայինի։ Նախ համապատասխանեցրեք պրոֆիլը փաստաթղթավորված հոսթի անվան հետ, ապա համեմատեք վկայագրերը։ Այլ ամեն ինչ, որ փոխեք դրանից առաջ, ենթադրություն է։
Ինչ պետք է պարունակի սերվերի վկայագիրը
Ժամանակակից հաճախորդները համեմատում են սուբյեկտի այլընտրանքային անունների ընդլայնման հետ, ուստի հոսթի անունը պետք է այնտեղ լինի որպես DNS գրառում։ Միայն ընդհանուր անունը բավարար չէ ներկայիս ստուգման կույտերի համար, և նիշանշանը ծածկում է մեկ պիտակ, ոչ թե ձեր հորինած ցանկացած ենթադոմեն։ Երեք վկայագիր ցույց են տալիս սահմանը՝ ճիշտ անունը սխալ նպատակով հաստատում է ինքնությունը և ապա ձախողվում նպատակի ստուգմանը, ճիշտ անունն ու նպատակը բացակայող միջանկյալ վկայագրի հետ ձախողվում են շղթայում, և անունը, որը կա միայն ընդհանուր անվան մեջ, ձախողվում է նախքան այդ երկուսից որևէ մեկի կարևոր լինելը։
Վկայագիրն անհրաժեշտ է նաև սերվերի նույնականացման նպատակին՝ ընդլայնված բանալու օգտագործման արժեքը, որը նշված է Microsoft-ի SSTP բնութագրում, այսինքն serverAuth՝ 1.3.6.1.5.5.7.3.1 օբյեկտի նույնացուցիչով։ Բանալու օգտագործումը և վավեր շղթան ամբողջացնում են հավաքածուն։ Սերվերի վրա գոյություն ունեցող, ճիշտ անվան համար թողարկված, բայց միայն հաճախորդի նույնականացման համար վկայագիրը դեռ ձախողվում է։
Ստուգեք շղթան և ժամացույցը մինչև մուտքի տվյալները
Ժամանակի և վստահության խափանումներ տալիս են նույն տեսանելի արդյունքը, ինչ անվան անհամապատասխանությունը, և երկուսն էլ ավելի էժան են ախտորոշել, քան գաղտնաբառի խնդիրը։ Ստուգեք սերվերի ժամացույցը և հաճախորդի ժամացույցը, ապա կարդացեք շղթան այնպես, ինչպես հաճախորդը տեսնում է այն:
# from the client, or any host that runs openssl
openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts </dev/null 2>/dev/null | openssl x509 -noout -subject -dates -ext subjectAltName
openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -verify_return_error </dev/null
# on the Windows server that holds the SSTP listener
w32tm /query /statusԱռաջին հրամանը տպում է անունը, վավերականության պատուհանը և այլընտրանքային անունները, որոնց հետ հաճախորդը կհամեմատի։ Երկրորդը հայտնում է ստուգման սխալները ներկայացված շղթայի հետ, և հենց այնտեղ է երևում բացակայող միջանկյալ վկայագիրը։ Windows-ում ժամանակի ծառայության հարցումը ձեզ ասում է՝ ժամացույցը շտկվում է, թե պարզապես շեղվել է։
Ներքին CA-ն ավելացնում է ևս մեկ պայման՝ հաճախորդը պետք է վստահի այդ CA-ին։ Տեղադրեք կազմակերպության արմատը դրա հաստատված բաշխման ուղով, ոչ թե փոխարինող վկայագիր առաջարկող էջից, որովհետև այդ որոշումը ողջ վստահության մոդելն է փոքր տեսքով։
Սերվերի ստուգումը և օգտատիրոջ նույնականացումը հաջորդական փուլեր են՝ տարբեր խափանումներով։ Վկայագրի սխալը նշանակում է, որ հաճախորդը երբեք չի վստահել սերվերին, մինչդեռ մերժված գաղտնաբառը նշանակում է, որ վստահել է սերվերին և տվյալները սխալ էին։ Վկայագրի ստուգումն անջատելը՝ գաղտնաբառի հուշմանը հասնելու համար, հեռացնում է երաշխիքը՝ այն վերանորոգելու փոխարեն։ Ուղու մնացած մասի աշխատանքն ապացուցելու համար փորձարկեք նույն հոսթի անունը և պորտը հաճախորդից, որն արդեն վստահում է շղթային, և թողեք տեղակայված պրոֆիլը անփոփոխ։
Ուղղեք անունը կամ վկայագիրը և նորից փորձարկեք
Երեք պայման են որոշում վերանորոգումը։ Եթե պրոֆիլի անունը սխալ է, ուղղեք պրոֆիլը կամ ավելացրեք բացակայող անունը վկայագրին։ Եթե շղթան թերի է, տեղադրեք միջանկյալ վկայագիրը սերվերի վրա։ Եթե նպատակը սխալ է, նորից թողարկեք՝ դրա շուրջ կարկատելու փոխարեն։
Փոփոխությունից հետո նորից միացեք աջակցվող հաճախորդով և հաստատեք, որ մուտքի հուշումը հայտնվում է, ապա որ թունելը բարձրանում է։ Գրեք տոմսում օգտագործված հոսթի անունը, թողարկողին և վաղեմության ամսաթիվը։ Այդ գրառումն է, որ հաջորդ նորացումը դարձնում է պլանավորված խնդիր՝ ևս մեկ ընդհատման փոխարեն, և նաև ցույց է տալիս հաջորդ մարդուն, թե երեք պայմաններից որն էր իրականում խախտված։