অসমর্থিত সার্টিফিকেট উদ্দেশ্য: মধ্যবর্তী CA কেন ব্যর্থ হয়

সার্ভার সার্টিফিকেটের উদ্দেশ্য ঠিক দেখাচ্ছে, কী মিলছে, তারিখগুলোও ঠিক আছে, তবু সংযোগটি unsupported certificate purpose ত্রুটিসহ ব্যর্থ হয়। যে বিবরণটি এটি সমাধান করে তা সাধারণত ত্রুটির একই লাইনে থাকে: একটি ডেপথ মান এবং একটি সাবজেক্ট, যা চেইনের উপরে থাকা একটি সার্টিফিকেটের নাম দেয়। দুটি ভিন্ন পরীক্ষা চলছে, এবং তার মধ্যে কেবল একটি লিফ সম্পর্কে। সেগুলো তুলনা করলে বোঝা যায় কেন সার্ভার সার্টিফিকেট বদলালে কিছুই বদলায় না।

যাচাইকারী আসলে কোন সার্টিফিকেট প্রত্যাখ্যান করেছে

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

সেই ডেপথের সার্টিফিকেটের ফিল্ড পড়ুন, আপনি যেটিকে দোষী ভেবেছেন সেটির নয়। প্রতিটি ফিল্ড না ঢেলে যে দুটি এক্সটেনশন ইস্যুকে সীমাবদ্ধ করে সেগুলো চান, কারণ উত্তর প্রায় সবসময় তাদের একটিতেই থাকে। এক্সটেনশনের আউটপুট শেয়ার করা নিরাপদ; প্রাইভেট কী কখনোই নয়।

openssl x509 -in issuing-ca.pem -noout -subject -issuer -ext basicConstraints -ext extendedKeyUsage

যদি উল্লিখিত সার্টিফিকেটটি একটি মধ্যবর্তী সার্টিফিকেট হয় যার এক্সটেন্ডেড কী ব্যবহারে TLS সার্ভার প্রমাণীকরণের সঙ্গে অসম্পর্কিত কিছু উল্লেখ থাকে, তবে বাকি ব্যর্থতা যান্ত্রিকভাবে অনুসরণ করে। চেইনটি OpenVPN যে উদ্দেশ্য চেয়েছিল সেটির জন্য ব্যবহার করা যায় না।

লিফের উদ্দেশ্য ও চেইন নীতি দুটি পরীক্ষা

লিফ পরীক্ষা একটি সংকীর্ণ প্রশ্ন করে: এই এন্ড-এনটিটি সার্টিফিকেট কি এই নামের জন্য সার্ভার প্রমাণীকরণের অনুমতি দেয়? চেইন পরীক্ষা আরও বিস্তৃত প্রশ্ন করে: পথের প্রতিটি সার্টিফিকেট কি সেই উদ্দেশ্যে কাজ করতে পারে? যে সার্টিফিকেট কর্তৃপক্ষকে কেবল ক্লায়েন্ট সার্টিফিকেট ইস্যু করার অনুমতি আছে, সে নিজের স্বাক্ষর পরীক্ষায় পাস করবে এবং তবু দ্বিতীয় পরীক্ষায় ব্যর্থ হবে, কারণ যে পথটি সে অনুমোদন করে তাতে অ্যাপ্লিকেশনের প্রয়োজনীয় উদ্দেশ্য নেই। দুটি পরীক্ষা একই শব্দে ব্যর্থ হয় এবং তাদের প্রতিকার সম্পূর্ণ ভিন্ন।

এজন্যই সদ্য ইস্যু করা একটি লিফ, প্রতিটি দৃশ্যমান ফিল্ডে সঠিক হয়েও, সঙ্গে সঙ্গে ব্যর্থ হতে পারে। আর এজন্যই প্রতিকারটি সাধারণত VPN কনফিগারেশনে নয়, বরং ইস্যুকারী কর্তৃপক্ষের প্রোফাইলে থাকে।

অনুপস্থিত EKU কোনো সীমাবদ্ধ EKU নয়

RFC 5280 এক্সটেন্ডেড কী ব্যবহার এক্সটেনশনটিকে ঐচ্ছিক করে এবং উপস্থিত থাকলে সীমাবদ্ধকারী করে। তাই যে CA সার্টিফিকেটে এক্সটেনশনটি নেই সে সার্ভার প্রমাণীকরণকে 'না' বলেনি, আর যে কেবল অসম্পর্কিত একটি উদ্দেশ্য তালিকাভুক্ত করে সে বেশ নির্দিষ্ট কিছু বলেছে। এই দুটি অবস্থাকে সমতুল্য ধরা ভুল রোগনির্ণয় দেয় এবং আরও খারাপ, ভুল প্রতিকার দেয়। পার্থক্যটি এও ব্যাখ্যা করে কেন কনসোলে একই রকম দেখতে দুটি কর্তৃপক্ষ চেইনে সম্পূর্ণ ভিন্নভাবে আচরণ করে।

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

পুনরায় ইস্যু করার আগে অফলাইনে ব্যর্থতা পুনরুৎপাদন করুন

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

openssl verify -purpose sslserver -show_chain -CAfile root-ca.pem -untrusted issuing-ca.pem vpn-server.pem

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

ইস্যু নীতি ঠিক করুন, যাচাইয়ের কল নয়

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

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