পরিদর্শন প্রক্সির কোন দিকটি শংসাপত্র প্রত্যাখ্যান করেছে?

ক্লায়েন্ট অনুমোদিত পরিদর্শন প্রক্সিকে বিশ্বাস করে। তবুও শংসাপত্রের ত্রুটির কারণে অনুরোধটি ব্যর্থ হয়। দুটি তথ্যই সত্য হতে পারে: সেই প্রক্সির যাচাই করার আরেকটি TLS সম্পর্ক রয়েছে।

client -- TLS to approved intermediary -- proxy -- TLS to website -- destination

ইন্টারসেপশন ব্যবস্থায় মধ্যবর্তী ক্লায়েন্টের TLS সমাপ্ত করে এবং তার নিজের সংযোগ সামনের দিকে তৈরি করে। ক্লায়েন্ট তার দিকে উপস্থাপিত শংসাপত্র গ্রহণ করতে পারে, অথচ প্রক্সি ওয়েবসাইট থেকে পাওয়া শংসাপত্র প্রত্যাখ্যান করে।

যাচাইকারীর ত্রুটি পড়ুন

কোন প্রক্রিয়া ব্যর্থ চেইন বা হোস্টনাম রিপোর্ট করেছে তা নির্ধারণ করুন। প্রক্সি-উৎপন্ন ত্রুটি পৃষ্ঠা একটি বৈধ সংযোগের মাধ্যমে ক্লায়েন্টের কাছে সফলভাবে পৌঁছাতে পারে। ক্লায়েন্টের CA ফাইল আবার বদলালে প্রক্সির আপস্ট্রিম বিশ্বাস কনফিগারেশন আপডেট হয় না।

উদাহরণস্বরূপ Mitmproxy আলাদা আপস্ট্রিম বিশ্বাস বিকল্প নথিভুক্ত করে, যার মধ্যে ssl_verify_upstream_trusted_ca রয়েছে। উপযুক্ত প্রশাসক যাচাই বজায় রেখে আপস্ট্রিম পরিষেবার জন্য অনুমোদিত বিশ্বাস কনফিগার করতে পারেন। অন্য একটি প্রক্সি পণ্যের তার নিজস্ব সংশ্লিষ্ট ইন্টারফেস প্রয়োজন।

প্রকৃত গন্তব্য নাম ও চেইনও পরীক্ষা করুন। মধ্যবর্তী শংসাপত্র ছাড়া একটি ব্যক্তিগত পরিষেবা, মেয়াদোত্তীর্ণ শংসাপত্র এবং অপরিচিত ব্যক্তিগত ইস্যুকারীর জন্য ভিন্ন মেরামত প্রয়োজন। একটি ব্যক্তিগত পরিষেবার জন্য অভিপ্রেত ব্যতিক্রম নীরবে প্রতিটি শংসাপত্রের বৈশ্বিক গ্রহণযোগ্যতায় পরিণত হওয়া উচিত নয়।

সাধারণ CONNECT টানেল আলাদা

অস্বচ্ছ ফরওয়ার্ড টানেল এইভাবে গন্তব্য TLS বিভক্ত করে না। অ্যাপ্লিকেশন সাধারণত সেই এন্ড-টু-এন্ড TLS সেশন নিজেই আলোচনা ও যাচাই করে। যেকোনো মধ্যবর্তীর উপর পরিদর্শন-প্রক্সি সেটিংস প্রয়োগ করার বদলে প্রথমে নির্ধারণ করুন ইন্টারসেপশন সত্যিই পথের অংশ কি না।

দুটি যাচাই ফলাফল আলাদাভাবে রেকর্ড করুন। “প্রক্সির শংসাপত্র বিশ্বাসযোগ্য” — এটি ক্লায়েন্টের দিকের প্রশ্নের উত্তর দেয়; প্রক্সি সামনে সংযোগ করার সময় কী দেখেছে তা এটি প্রত্যয়িত করে না।