ვინ აგზავნის კლიენტის სერტიფიკატს პროქსის მეშვეობით?
დანიშნულების mTLS მონაცემები გამოყავით პროქსის მონაცემებისგან და იმ სერტიფიკატებისგან, რომლებსაც Apache იყენებს საკუთარი ზედა TLS სესიის შექმნისას.
ჩვეულებრივი HTTPS-ის CONNECT-ით გადაცემისას აპლიკაცია ვებსაიტის კლიენტის სერტიფიკატს აგზავნის თავისი დანიშნულების TLS ხელის ჩამორთმევის დროს. პროქსი მხოლოდ ბაიტებს გადასცემს; ის ავტომატურად არ ხდება ვებსაიტის TLS კლიენტი.
| მონაცემი | მფლობელი/კავშირი |
|---|---|
| პროქსის მომხმარებლის სახელი/პაროლი | კლიენტის წვდომა პროქსიზე. |
| ვებსაიტის კლიენტის სერტიფიკატი და კერძო გასაღები | აპლიკაციის TLS სესია დანიშნულებასთან. |
| პროქსი სერვერის ზედა კლიენტის სერტიფიკატი | TLS სესია, რომელსაც თავად პროქსი იწყებს. |
ეს როლები შეიძლება თანაარსებობდეს. დანიშნულების mTLS-ის მუშაობისთვის ვებსაიტის კერძო გასაღების უბრალო გვირაბის პროქსიზე ატვირთვა საჭირო არ არის. CONNECT-ის გადაცემის შემდეგ გამოიყენეთ აპლიკაციის ჩვეულებრივი დანიშნულების კლიენტის სერტიფიკატის კონფიგურაცია და გააგრძელეთ ვებსაიტის სერვერის სერტიფიკატის შემოწმება.
Apache-ის SSLProxyMachineCertificateFile მონაცემებს აწვდის მაშინ, როცა Apache საკუთარ ზედა TLS სესიას ქმნის. რჩევა ამ ფაილზე არ ამტკიცებს, რომ გაუმჭვირვალე გადამისამართების გვირაბის ყოველმა კლიენტმა ის უნდა დააკონფიგურიროს.
TLS-ის ჩარევა სესიას შუამავალთან ამთავრებს და ამ საკუთრებას ცვლის. დაადგინეთ, შეუძლია თუ არა საჭირო კლიენტის იდენტობას ამ სქემაში გავლა, იმის ნაცვლად რომ ჩათვალოთ, თითქოს სერტიფიკატის კოპირება ინარჩუნებს ავთენტიფიკაციას ბოლოდან ბოლომდე.
წარუმატებლობისას ჩაწერეთ, გაჩერდა თუ არა მოთხოვნა პროქსიში შესვლისას, დანიშნულების TLS-ზე თუ აპლიკაციის შემდგომ გაცვლაზე. განათავსეთ მონაცემი იმ კავშირზე, რომელიც მას ნამდვილად ითხოვს.