სერტიფიკატის შეცდომები პროქსის გამოყენებისას
სერტიფიკატების პარამეტრების შეცვლამდე გაარკვიეთ, შემოწმება თავად პროქსის TLS კავშირზე ჩავარდა თუ სამიზნე საიტზე.
CA ნაკრების შეცვლამდე გაარკვიეთ, რომელი TLS ხელის ჩამორთმევა ვერ შესრულდა. პროქსისა და საიტის სერტიფიკატები შეიძლება სხვადასხვა კავშირზე მოწმდებოდეს.
| პროქსი და დანიშნულება | TLS შემოწმებები |
|---|---|
| HTTP პროქსი HTTPS დანიშნულებამდე | CONNECT-ის შემდეგ გვირაბის გავლით შეამოწმეთ დანიშნულების სერტიფიკატი. |
| HTTPS პროქსი HTTPS დანიშნულებამდე | ჯერ შეამოწმეთ TLS პროქსიმდე; გვირაბის გახსნის შემდეგ შეამოწმეთ დანიშნულებასთან ცალკე TLS სესია. |
დეტალური კვალის მიხედვით დაადგინეთ მოთხოვნილი ჰოსტის სახელი და ბოლო დასრულებული ხელის ჩამორთმევა. HTTPS პროქსის სერტიფიკატის შეცდომა შეიძლება საიტთან დაკავშირებამდე მოხდეს. შეამოწმეთ ამ კავშირის მოსალოდნელი სახელი, სერტიფიკატის მოქმედების პერიოდი, ადგილობრივი საათი, მოსალოდნელი ჯაჭვი და დამტკიცებული ნდობის საცავი. კვლევაში ჩართეთ განზრახ გამართული TLS ჩაჭრა ან დამატებული ძირეული სერტიფიკატიც.
curl ორ კავშირს ცალ-ცალკე CA პარამეტრებს სთავაზობს:
curl --proxy https://proxy.example:8443 --proxy-cacert proxy-ca.pem --cacert site-ca.pem https://example.com/--proxy-cacert ნდობას პროქსისთვის განსაზღვრავს, --cacert კი დანიშნულებისთვის. მაგალითის ბოლო წერტილი და ფაილები ჩაანაცვლეთ ნდობის სასურველი მოწყობის მნიშვნელობებით. საკუთარი ნაკრებები ზედმეტია, თუ სისტემის ნდობა უკვე საკმარისია.
ჰოსტის სახელის ნებისმიერი IP-ით ჩანაცვლება სერტიფიკატის დამთხვევის შემოწმებას ცვლის. შემოწმების გამოტოვებამ შეიძლება შეცდომა დამალოს მეორე მხარის ვინაობის დადგენის გარეშე. უცნობი პროქსის თხოვნა, დააყენოთ მისი ძირეული CA, მისდამი ნდობის საკმარისი მიზეზი არ არის.
პორტთან უარყოფილი კავშირი ან უარყოფილი CONNECT ადრინდელ ეტაპს ეკუთვნის; სერტიფიკატების შეცვლა ამას ვერ გამოასწორებს. პირიქით, დანიშნულების TLS შემოწმების შემდეგ საიტის HTTP შეცდომა მიღებულ პასუხს ეხება და არა კიდევ ერთ CA შესწორებას.