প্ৰক্সিৰ জৰিয়তে ক্লায়েন্ট চাৰ্টিফিকেট কোনে প্ৰেৰণ কৰে?

সাধাৰণ CONNECT-ৰ যোগেদি HTTPS-ত, এপ্লিকেচনে নিজৰ গন্তব্য TLS হেণ্ডশ্বেকৰ সময়ত ৱেবছাইটৰ ক্লায়েন্ট চাৰ্টিফিকেট প্ৰেৰণ কৰে। প্ৰক্সিয়ে বাইটসমূহ আগবঢ়াই দিয়ে; সি স্বয়ংক্ৰিয়ভাৱে ৱেবছাইটৰ TLS ক্লায়েন্ট নহয়।

এই ভূমিকাসমূহ একেলগে থাকিব পাৰে। গন্তব্য mTLS কাম কৰাবলৈ ৱেবছাইটৰ ব্যক্তিগত কী সাধাৰণ টানেলিং প্ৰক্সিলৈ আপলোড কৰাৰ প্ৰয়োজন নাই। CONNECT হস্তান্তৰৰ পিছত, এপ্লিকেচনৰ সাধাৰণ গন্তব্য ক্লায়েন্ট-চাৰ্টিফিকেট সংৰচনা ব্যৱহাৰ কৰক আৰু ৱেবছাইট চাৰ্ভাৰ চাৰ্টিফিকেট সত্যাপন কৰি থাকক।

Apache-ৰ SSLProxyMachineCertificateFile-এ প্ৰমাণপত্ৰ যোগান ধৰে যেতিয়া Apache-এ নিজৰ আপষ্ট্ৰিম TLS অধিবেশন সৃষ্টি কৰে। সেই ফাইলৰ বিষয়ে পৰামৰ্শই এইটো প্ৰমাণ নকৰে যে অস্বচ্ছ ফৰৱাৰ্ড টানেল ব্যৱহাৰ কৰা প্ৰতিজন ক্লায়েন্টে ইয়াক সংৰচনা কৰিবই লাগিব।

TLS বাধাই মধ্যস্থতাকাৰীত অধিবেশন সমাপ্ত কৰে আৰু এই গৰাকীত্ব সলনি কৰে। চাৰ্টিফিকেট কপি কৰিলে প্ৰান্ত-ৰ পৰা-প্ৰান্ত প্ৰমাণীকৰণ ৰক্ষা হয় বুলি ধৰি লোৱাৰ পৰিৱৰ্তে প্ৰয়োজনীয় ক্লায়েন্ট পৰিচয়ই সেই ব্যৱস্থাৰ মাজেৰে পাৰ হ'ব পাৰে নে নাই সেয়া নিৰ্ধাৰণ কৰক।

বিফলতাৰ ক্ষেত্ৰত, অনুৰোধটো প্ৰক্সি লগইনত, গন্তব্য TLS-ত বা পিছৰ এপ্লিকেচন বিনিময়ত ৰ'ল নে নাই সেয়া লিপিবদ্ধ কৰক। প্ৰমাণপত্ৰটো যি সংযোগে প্ৰকৃততে বিচাৰে তাৰ ওপৰত ৰাখক।