IKEv2 სერტიფიკატის SAN: რატომ ჩავარდება იდენტობის შემოწმება
მოქმედი IKEv2 სერტიფიკატი მაინც ჩავარდება, როცა მოსალოდნელი იდენტობა და SAN-ის ტიპი არ ემთხვევა. შეადარეთ DNS DNS-ს, IP IP-ს და ჯერ პროფილი შეამოწმეთ.
თქვენი სერტიფიკატი სანდო CA-ს ჯაჭვს ეკუთვნის, თარიღები რიგზეა და პირი მაინც უარყოფს 1-ლი ფაზის დასრულებას იდენტობის შეცდომით. ხელმისაწვდომობა და მოქმედი ხელმოწერა მხოლოდ ნახევარია იმისა, რასაც IKEv2 კლიენტი ამოწმებს. მეორე ნახევარია, ჩნდება თუ არა მოსალოდნელი იდენტობა სერტიფიკატში სწორ ველში, და ამ მოლოდინს პროფილი ადგენს, არა სერტიფიკატის ფაილის სახელი.
სიმპტომი ყოველთვის ერთი და იმავე ფორმისაა
კავშირის პროფილი იცვლება ჰოსტის სახელიდან IP მისამართზე, ან განახლდება სერტიფიკატიდან, რომელიც DNS სახელს ატარებდა, იმ სერტიფიკატზე, რომელიც მხოლოდ მისამართებს ატარებს, დაგვირაბი წყვეტს მოლაპარაკებას. ქსელის გზაზე არაფერი შეცვლილა. კლიენტი აღწევს პირს, იღებს სერტიფიკატს და უარყოფს პირის იდენტობას, რადგან ის იდენტიფიკატორი, რომლის მოლოდინიც უთხრეს, არ არის წარმოდგენილი მის მისაღებ ველში. განახლებები ჩვეულებრივი გამომწვევია, რადგან შემცვლელი სერტიფიკატი ხშირად სხვა შაბლონიდან მოდის, ვიდრე ის, რომელსაც ანაცვლებს.
ორივე მხარე შემდეგ რაღაც უსარგებლოს აღრიცხავს, ამიტომაც ჩავარდნა ჩვეულებრივ სერტიფიკატის პრობლემად მოხსენდება. კლიენტის ჟურნალმა შეიძლება დაასახელოს სასურველი იდენტობა, და ეს სახელია თქვენი მინიშნება, არა ვადის გასვლის თარიღი.
შეადარეთ იდენტიფიკატორის ტიპი, არა მხოლოდ მნიშვნელობა
dNSName SAN და iPAddress SAN სხვადასხვა ველებია სხვადასხვა შესაბამისობის წესებით, ამიტომ სერტიფიკატი, რომელიც 203.0.113.10-ს DNS სტრიქონად ატარებს, არ აკმაყოფილებს IP იდენტობის მომლოდინე კლიენტს. თანამედროვე დამამოწმებლები დიდწილად უგულებელყოფენ საერთო სახელს, ამიტომ სერტიფიკატის დეტალებში მოცემული მეგობრული ეტიკეტი არაფერს ამტკიცებს იმაზე, თუ რა დაემთხვევა. თუ პრობლემების მოგვარებისას ჰოსტის სახელი მისამართით შეიცვალა, ჩათვალეთ, რომ მოსალოდნელი იდენტობა მასთან ერთად გადაადგილდა, სანამ არ შეამოწმებთ. შეადარეთ პროფილში არსებული სტრიქონი SAN-ში არსებულს სიმბოლო-სიმბოლოდ, რადგან ბოლოში წერტილი ან ზედმეტი გამოტოვება საკმარისია.
ნაკვალეტი სიმბოლოები მხოლოდ DNS-ის კომფორტია და საკუთარ შესაბამისობის წესებს მიჰყვება, რაც კიდევ ერთი მიზეზია იმისა, რომ IP-ზე დაფუძნებულმა პროფილმა არასოდეს უნდა დაეყრდნოს მათ.
იპოვეთ, სად ინახავს თითოეული კლიენტი მოლოდინს
strongSwan-ში სერტიფიკატთან შედარებული მნიშვნელობა პირის იდენტობის პარამეტრიდან მოდის: rightid კლასიკურ კონფიგურაციაში, ან id swanctl-ის დისტანციური კავშირის სექციის id-იდან. მისი დოკუმენტაცია Apple IKEv2-ის თავსებადობაზე აქ სასარგებლოა, რადგან განმარტავს იმ იდენტობის კონვენციებს, რომლებსაც პროფილით მართული კლიენტი იყენებს, და ეს კონვენციები ხსნიან შეუსაბამობების კლასს, რომელიც ხაზზე შემთხვევითი ჩანს.
Apple-ის კონფიგურაციის პროფილები ატარებენ დისტანციური იდენტიფიკატორის ველს, და სწორედ იქ არსებული მნიშვნელობა ამოწმებს კლიენტი და არა კავშირის პარამეტრებში არსებული სერვერის მისამართი. Windows-ისა და მოწყობილობების კლიენტებს თითოეულს აქვს საკუთარი ველი და საკუთარი ნაგულისხმევი, და ნაგულისხმევი ხშირად მიჰყვება თქვენ მიერ აკრეფილ მისამართს. სადაც ორი ველი არ ეთანხმება, იმარჯვებს ის, რასაც კლიენტი რეალურად კითხულობს, და ეს იშვიათად არის ის, რაც თქვენ შეასწორეთ.
შეაკეთეთ პროფილი ან სერტიფიკატი, განზრახ
ნებისმიერი ცვლილების წინ დამტკიცებული ხელსაწყოებით შეამოწმეთ პირის სერტიფიკატი და ჩამოთვალეთ SAN ჩანაწერები მათი ტიპებით. ეს შემოწმება არ საჭიროებს პირად გასაღებს და ატვირთვას, და რამდენიმე წამში წყვეტს საკითხს. თუ განლაგება ერთ DNS იდენტობას გულისხმობს, სერტიფიკატმა ის უნდა ატაროს dNSName ჩანაწერად, და თუ განლაგება მისამართს გულისხმობს, სერტიფიკატს სჭირდება iPAddress ჩანაწერი ზუსტად იმ მისამართისთვის.
როცა სერტიფიკატი არასწორია, ოპერატორისგან მოითხოვეთ გასწორებული, კონკრეტული მოსალოდნელი იდენტიფიკატორით. როცა პროფილი არასწორია, გაასწორეთ პროფილი და სერტიფიკატს ხელი არ ახლოთ. იდენტობის ვალიდაციის გამორთვა შეცდომას აქრობს და აცილებს იმ შემოწმებას, რომ გვირაბი თქვენ მიერ განზრახულ პირთან საუბრობს.
დააფიქსირეთ მოსალოდნელი იდენტობა თითოეული კლიენტის პლატფორმისთვის, რადგან ერთი კლიენტის მიერ ავტომატურად გამოყვანილი მნიშვნელობა შეიძლება მეორეზე ცხადად იყოს საჭირო.
მიეცით განახლების მოთხოვნას ოთხი ფაქტი
ჩაწერეთ მოსალოდნელი იდენტიფიკატორი და მისი ტიპი, ჩანაწერები SAN, რომლებიც ამჟამინდელ სერტიფიკატს რეალურად აქვს, შემოწმების შემსრულებელი კლიენტი და ვერსია, და შეცდომის ზუსტი ტექსტი. ამ ოთხი ხაზიდან აწყობილი განახლების მოთხოვნა პირველივე ჯერზე იღებს სწორ სერტიფიკატს, ნაცვლად იმავე ნაცნობი ფაილის სახელის მქონე სხვა სერტიფიკატის.