HTTPS դեպի մասնավոր IP՝ վկայագրի ինքնություն, թե հոսթի անուն։
Մասնավոր IP-ն կարող է վավեր TLS ինքնություն լինել, եթե վկայագիրը դա ասում է։ Ընտրեք IP SAN-ի և կայուն հոսթի անվան միջև, ապա պլանավորեք հասցեի փոփոխությունը։
Ձեր ծառայությունը https://10.60.0.25 հասցեում կարող է ունենալ նույնականացված TLS նույնիսկ առանց DNS անվան։ Հասցեն այն ինքնությունն է, որը հաճախորդը պետք է վավերացնի, և վկայագիրը պետք է այն ճշգրիտ նկարագրի։ Որոշումն այն է՝ արդյոք հասցեն բավականաչափ կայուն է որպես ինքնություն, թե՞ հոսթի անունը ավելի հեշտ կլինի պահպանել։ VPN-ը պատասխանում է հասանելիությանը, բայց այս հարցին չի պատասխանում։
Ինքնությունը և վստահությունը ճիշտ դասավորեք, և IP-ի վրա հիմնված URL-ը օրինական լուծում է։
Ինչ է իրականում վավերացնում հաճախորդը
Հաճախորդը URL-ի հղումային ինքնությունը համեմատում է վկայագրի այլընտրանքային սուբյեկտային անունների հետ։ IP հասցեի համար դա նշանակում է հասցեին հավասար iPAddress գրառում։ Ընկերական ընդհանուր անունը դրա փոխարինողը չէ։
RFC 9525 առանձնացնում է IP հասցեի ինքնությունները DNS անուններից և սահմանում համապատասխանության կանոնը։ Հասցեն միայն սուբյեկտի պիտակում կամ DNS տիպի գրառումով դնելը համապատասխանություն չի առաջացնում։ Այդ պատճառով նախազգուշացման դեպքում SAN-ն է այն դաշտը, որ պետք է ստուգել։
Վստահությունը երկրորդ, անկախ ստուգումն է։ Անվան համապատասխանությունը չի շտկում անվստահելի շղթան, ժամկետանց վկայագիրը կամ այլ նպատակով տրված վկայագիրը։
Առաջին որոշումը՝ արդյոք հասցեն բավականաչափ կայուն է որպես ինքնություն
Եթե հասցեն ֆիքսված է տեղակայման ողջ կյանքի ընթացքում, IP SAN վկայագիրը պարզ է ու ազնիվ։ Եթե ծառայությունը կարող է տեղափոխվել, ամեն տեղափոխություն դառնում է վկայագրի փոխարինում և համակարգված հաճախորդի թարմացում։
Կայուն հոսթի անունը նվազեցնում է այդ կապը։ Հաճախորդները օգտագործում են անունը, հաստատված DNS-ը քարտեզագրում է այն ընթացիկ հասցեին, և հասցեի փոփոխությունը դադարում է ինքնության փոփոխություն լինել։ Վկայագիրը դեռ թարմացման կարիք ունի, բայց URL-ը չի փոխվում։
Կառավարվող hosts ֆայլի գրառումը կարող է ապահովել քարտեզագրումը փոքր միջավայրում։ Այն ավելացնում է բաշխման պատասխանատվություն, բայց չի փոխարինում TLS ստուգմանը։
Երկրորդ որոշումը՝ ինչպես հաճախորդը կվստահի թողարկողին
Մասնավոր CA-ի համար վստահության խարիսխը տարածեք նախատեսված սարքերին հաստատված մեխանիզմով։ Մի՛ սովորեցրեք օգտվողներին անցնել նախազգուշացումները կամ տեղադրել մուտքի էջի տված վկայագիրը։ Եթե ցանկանում եք հանրային վստահելի վկայագիր, նախքան դրա վրա պլանավորելը ստուգեք թողարկողի ընթացիկ կանոնները մասնավոր հասցեների համար։ Հանրային թողարկողների մեծ մասը մասնավոր IP-ն որպես հանրային ինքնություն չի վավերացնի։
Ուսումնասիրեք իրական զննարկիչը կամ հավելվածը։ Նրա վստահության պահոցը և վավերացման վարքը ավելի կարևոր են, քան օպերացիոն համակարգի վկայագրերի ընդհանուր փաստաթղթերը։ Ստուգեք այն իրական սարքում, ոչ միայն կոնսոլում։
Հնարավոր է, որ VPN դարպասը այն մեքենան չէ, որը գործարկում է վեբ հավելվածը, ուստի մի՛ ենթադրեք, որ թունելի վկայագիրն ինչ-որ կապ ունի այս մեկի հետ։
Պլանավորեք հասցեի փոփոխությունը նախքան այն տեղի կունենա
Եթե 10.60.0.25-ը դառնա 10.60.0.40, հին վկայագիրն այլևս չի նկարագրում URL-ը։ Պլանավորեք փոխարինումը և հաճախորդի թարմացումը միասին, և երբեք չանջատեք վավերացումը տեղափոխման ընթացքում։
Ընտրեք այն ինքնությունը, որը օգտվողները կգրեն կամ հավելվածները կկարգավորեն, ապա դրա շուրջ համաձայնեցրեք թողարկումը, վստահությունը, տեղակայումը և թարմացումը։ Հասանելի էջը մերժված նախազգուշացմամբ նույն արդյունքը չէ, ինչ ծառայությունը, որի ինքնությունը հաճախորդը վավերացնում է։