প্রক্সি ব্যবহারের সময় সার্টিফিকেটের ত্রুটি
সার্টিফিকেটের সেটিং বদলানোর আগে জানুন, যাচাই ব্যর্থ হয়েছে প্রক্সির নিজস্ব TLS সংযোগে, নাকি গন্তব্য ওয়েবসাইটে।
CA বান্ডল বদলানোর আগে খুঁজে বের করুন কোন TLS হ্যান্ডশেক ব্যর্থ হয়েছে। প্রক্সির সার্টিফিকেট ও ওয়েবসাইটের সার্টিফিকেট আলাদা সংযোগে যাচাই হতে পারে।
| প্রক্সি ও গন্তব্য | TLS যাচাই |
|---|---|
| HTTPS গন্তব্যের জন্য HTTP প্রক্সি | CONNECT-এর পরে টানেল দিয়ে গন্তব্যের সার্টিফিকেট যাচাই করুন। |
| HTTPS গন্তব্যের জন্য HTTPS প্রক্সি | আগে প্রক্সি পর্যন্ত TLS যাচাই করুন; টানেল খোলার পরে গন্তব্যের আলাদা TLS সেশন যাচাই করুন। |
বিস্তারিত ট্রেসে অনুরোধ করা হোস্টনাম এবং শেষ সম্পূর্ণ হওয়া হ্যান্ডশেক খুঁজুন। HTTPS প্রক্সির সার্টিফিকেটের ব্যর্থতা ওয়েবসাইটে যোগাযোগের আগেই ঘটতে পারে। ওই সংযোগের উদ্দেশ্য করা নাম, সার্টিফিকেটের মেয়াদ, স্থানীয় ঘড়ি, প্রত্যাশিত চেইন এবং অনুমোদিত ট্রাস্ট স্টোর যাচাই করুন। ইচ্ছাকৃতভাবে কনফিগার করা TLS ইন্টারসেপশন বা যোগ করা রুট সার্টিফিকেটও অনুসন্ধানে ধরুন।
curl দুটি সংযোগের জন্য আলাদা CA বিকল্প দেয়:
curl --proxy https://proxy.example:8443 --proxy-cacert proxy-ca.pem --cacert site-ca.pem https://example.com/--proxy-cacert প্রক্সির জন্য আস্থার ভিত্তি দেয়; --cacert গন্তব্যের জন্য। উদাহরণের এন্ডপয়েন্ট ও ফাইলগুলো আপনার কাঙ্ক্ষিত আস্থার ব্যবস্থার মান দিয়ে বদলান। সিস্টেমের আস্থা যথেষ্ট হলে নিজস্ব বান্ডলের দরকার নেই।
হোস্টনামের বদলে ইচ্ছেমতো IP বসালে সার্টিফিকেট মেলানো বদলে যায়। যাচাই এড়িয়ে গেলে ব্যর্থতা লুকাতে পারে, কিন্তু অপর প্রান্তের পরিচয় প্রতিষ্ঠা হয় না। অপরিচিত প্রক্সির নিজের রুট CA ইনস্টল করতে বলা সেটিকে বিশ্বাস করার যথেষ্ট কারণ নয়।
পোর্টে সংযোগ প্রত্যাখ্যান বা CONNECT প্রত্যাখ্যান আগের ধাপের ব্যাপার; সার্টিফিকেট বদলে তা সারানো যায় না। উল্টো দিকে, গন্তব্যের TLS যাচাই হয়ে গেলে ওয়েবসাইটের HTTP ত্রুটি পাওয়া রেসপন্সের বিষয়, আরেক দফা CA বদলের নয়।