HTTPS პროქსიმაც უნდა გაგზავნოს საკუთარი სერტიფიკატების ჯაჭვი
დაადგინეთ კლიენტიდან Squid-მდე TLS მსმენელზე დაკარგული შუალედური სერტიფიკატები დანიშნულების ვებსაიტის სერტიფიკატისგან ცალკე.
თუ კლიენტები HTTPS პროქსის უარყოფენ ვებსაიტზე მისვლამდე, შეამოწმეთ ჯაჭვი, რომელსაც პროქსის მსმენელი აგზავნის. მხოლოდ სწორი ფოთლის სერტიფიკატმა შეიძლება ვერ მოგვცეს კლიენტისთვის საჭირო შუალედური სერტიფიკატები.
- განსაზღვრეთ შესამოწმებელი ბოლო წერტილი. წაიკითხეთ ჰოსტის სახელი კონფიგურირებულ პროქსის URL-ში და ამ კავშირის შეცდომა. მსმენელის სერტიფიკატმა უნდა დაფაროს ეს სახელი. ვებსაიტის სერტიფიკატი ან სხვა IP ფსევდონიმის სერტიფიკატი ვერ შეცვლის მას.
- შეამოწმეთ მსმენელის ჯაჭვის კონფიგურაცია. Squid-ის მხარდაჭერილი OpenSSL კონფიგურაცია შეიძლება მოიცავდეს შუალედურ სერტიფიკატებს სერტიფიკატის ფაილში. დაადასტურეთ განლაგება მსმენელის ცნობარში დაყენებული Squid-ის ვერსიისა და TLS backend-ისთვის; პაკეტების ქცევა ერთგვაროვანი არ არის. Squid 6.13-ის TLS მსმენელის მაგალითი მსმენელის ნდობას დანიშნულების TLS-ისგან ცალკე ინახავს.
- ცალკე შეამოწმეთ კლიენტის ნდობა. შუალედური სერტიფიკატების გაგზავნა ეხმარება ჯაჭვის აგებას, მაგრამ კლიენტს კვლავ სჭირდება განზრახული ძირეული ნდობის სამაგრი. მთელი სერვერის ჯაჭვის ძირეულ საცავში განურჩევლად იმპორტი განსხვავებული ცვლილებაა, ვიდრე სერვერის მიერ გაგზავნილის გასწორება.
დატოვეთ გადამოწმება ჩართული. ის ამოიცნობს HTTPS პროქსის, რომლის გამოყენებასაც კლიენტი აპირებდა. ამ კავშირის გადამოწმების შემდეგ, მოგვიანებით ვებსაიტის სერტიფიკატის შეცდომა ეკუთვნის დანიშნულების TLS სესიას პროქსის მეშვეობით, საკუთარი ჰოსტის სახელისა და ნდობის გამოკვლევით.