ჩვეულებრივი HTTPS-ის CONNECT-ით გადაცემისას აპლიკაცია ვებსაიტის კლიენტის სერტიფიკატს აგზავნის თავისი დანიშნულების TLS ხელის ჩამორთმევის დროს. პროქსი მხოლოდ ბაიტებს გადასცემს; ის ავტომატურად არ ხდება ვებსაიტის TLS კლიენტი.

მონაცემიმფლობელი/კავშირი
პროქსის მომხმარებლის სახელი/პაროლიკლიენტის წვდომა პროქსიზე.
ვებსაიტის კლიენტის სერტიფიკატი და კერძო გასაღებიაპლიკაციის TLS სესია დანიშნულებასთან.
პროქსი სერვერის ზედა კლიენტის სერტიფიკატიTLS სესია, რომელსაც თავად პროქსი იწყებს.

ეს როლები შეიძლება თანაარსებობდეს. დანიშნულების mTLS-ის მუშაობისთვის ვებსაიტის კერძო გასაღების უბრალო გვირაბის პროქსიზე ატვირთვა საჭირო არ არის. CONNECT-ის გადაცემის შემდეგ გამოიყენეთ აპლიკაციის ჩვეულებრივი დანიშნულების კლიენტის სერტიფიკატის კონფიგურაცია და გააგრძელეთ ვებსაიტის სერვერის სერტიფიკატის შემოწმება.

Apache-ის SSLProxyMachineCertificateFile მონაცემებს აწვდის მაშინ, როცა Apache საკუთარ ზედა TLS სესიას ქმნის. რჩევა ამ ფაილზე არ ამტკიცებს, რომ გაუმჭვირვალე გადამისამართების გვირაბის ყოველმა კლიენტმა ის უნდა დააკონფიგურიროს.

TLS-ის ჩარევა სესიას შუამავალთან ამთავრებს და ამ საკუთრებას ცვლის. დაადგინეთ, შეუძლია თუ არა საჭირო კლიენტის იდენტობას ამ სქემაში გავლა, იმის ნაცვლად რომ ჩათვალოთ, თითქოს სერტიფიკატის კოპირება ინარჩუნებს ავთენტიფიკაციას ბოლოდან ბოლომდე.

წარუმატებლობისას ჩაწერეთ, გაჩერდა თუ არა მოთხოვნა პროქსიში შესვლისას, დანიშნულების TLS-ზე თუ აპლიკაციის შემდგომ გაცვლაზე. განათავსეთ მონაცემი იმ კავშირზე, რომელიც მას ნამდვილად ითხოვს.

დაკავშირებული სტატიები