কে প্রক্সির মাধ্যমে ক্লায়েন্ট সার্টিফিকেট পাঠায়?
গন্তব্য mTLS শংসাপত্রগুলিকে প্রক্সি শংসাপত্র থেকে এবং Apache তার নিজস্ব আপস্ট্রিম TLS সেশন তৈরি করার সময় যে সার্টিফিকেট ব্যবহার করে তা থেকে আলাদা রাখুন।
সাধারণ CONNECT-এর মাধ্যমে HTTPS-এ, অ্যাপ্লিকেশনটি নিজের গন্তব্য TLS হ্যান্ডশেকের সময় ওয়েবসাইটের ক্লায়েন্ট সার্টিফিকেট পাঠায়। প্রক্সি বাইটগুলি রিলে করে; এটি স্বয়ংক্রিয়ভাবে ওয়েবসাইটের TLS ক্লায়েন্ট হয়ে যায় না।
| শংসাপত্র | মালিক/সংযোগ |
|---|---|
| প্রক্সি ব্যবহারকারীর নাম/পাসওয়ার্ড | প্রক্সিতে ক্লায়েন্টের প্রবেশ। |
| ওয়েবসাইট ক্লায়েন্ট সার্টিফিকেট ও ব্যক্তিগত কী | গন্তব্যের সাথে অ্যাপ্লিকেশনের TLS সেশন। |
| প্রক্সি সার্ভারের আপস্ট্রিম ক্লায়েন্ট সার্টিফিকেট | প্রক্সি নিজে যে TLS সেশন শুরু করে। |
এই ভূমিকাগুলি একসাথে থাকতে পারে। গন্তব্য mTLS কাজ করার জন্য ওয়েবসাইটের ব্যক্তিগত কী সাধারণ টানেলিং প্রক্সিতে আপলোড করার প্রয়োজন নেই। CONNECT হস্তান্তরের পরে, অ্যাপ্লিকেশনের স্বাভাবিক গন্তব্য ক্লায়েন্ট-সার্টিফিকেট কনফিগারেশন ব্যবহার করুন এবং ওয়েবসাইট সার্ভার সার্টিফিকেট যাচাই চালিয়ে যান।
Apache-এর SSLProxyMachineCertificateFile শংসাপত্র সরবরাহ করে যখন Apache নিজের আপস্ট্রিম TLS সেশন তৈরি করে। সেই ফাইল সম্পর্কে পরামর্শ প্রমাণ করে না যে অস্বচ্ছ ফরওয়ার্ড টানেল ব্যবহারকারী প্রতিটি ক্লায়েন্টকে এটি কনফিগার করতে হবে।
TLS হস্তক্ষেপ একটি মধ্যবর্তী স্থানে সেশন শেষ করে এবং এই মালিকানা পরিবর্তন করে। সার্টিফিকেট কপি করলে প্রান্ত-থেকে-প্রান্ত প্রমাণীকরণ সংরক্ষিত থাকে বলে ধরে নেওয়ার বদলে নির্ধারণ করুন প্রয়োজনীয় ক্লায়েন্ট পরিচয় সেই ব্যবস্থার মধ্য দিয়ে যেতে পারে কি না।
ব্যর্থতার ক্ষেত্রে, অনুরোধটি প্রক্সি লগইনে, গন্তব্য TLS-এ নাকি পরবর্তী অ্যাপ্লিকেশন বিনিময়ে থেমেছিল তা লিপিবদ্ধ করুন। শংসাপত্রটি যে সংযোগ সত্যিই তা চায় তার উপর রাখুন।