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-ს. დაგეგმეთ შეცვლა და კლიენტის განახლება ერთად და არასოდეს გამორთოთ გადამოწმება გადასვლის დროს.
აირჩიეთ ის იდენტობა, რომელსაც მომხმარებლები აკრეფენ ან აპლიკაციები დააკონფიგურირებენ, შემდეგ მის გარშემო გაასწორეთ გაცემა, ნდობა, განლაგება და განახლება. ხელმისაწვდომი გვერდი უარყოფილი გაფრთხილებით არ არის იგივე შედეგი, რაც სერვისი, რომლის იდენტობასაც კლიენტი ამოწმებს.