সার্টিফিকেট প্রত্যাহার ব্যর্থ: কোন হোস্ট কী পর্যন্ত পৌঁছাতে পারে না

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

আনয়নের পথ যাচাইকারীর হাতেই

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

কিছু বদলানোর আগে সার্টিফিকেট, যাচাইকারী, প্রচেষ্টার সময় এবং সঠিক স্টেটাস কোড লিখে রাখুন।

সার্টিফিকেট থেকে প্রকাশনা এন্ডপয়েন্ট পড়ুন

সার্টিফিকেটই বলে দেয় তার অবস্থা কোথায় থাকে। CA ঠিকানা অনুমান না করে ওই ফিল্ডগুলি পড়ুন।

openssl x509 -in gateway.cer -noout -text | grep -A3 "CRL Distribution Points"
openssl x509 -in gateway.cer -noout -text | grep -A2 "Authority Information Access"

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

যে ডিভাইস যাচাই করে সেখান থেকেই আনয়ন পরীক্ষা করুন

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

certutil -urlfetch -verify .\client-test.cer
curl -sS -o /dev/null -w "%{http_code}\n" http://crl.example.com/ca.crl

certutil চালানো চেইন যাচাই করে এবং কোন URL আনয়ন সফল বা ব্যর্থ হয়েছে তা জানায়, আর curl কল একই হোস্ট থেকে একটি প্রকাশনা ঠিকানা পরীক্ষা করে কেবল একটি স্টেটাস কোড ফেরত দেয়। পৌঁছানো যায় এমন ঠিকানা থেকে ব্যর্থ আনয়ন সামগ্রী বা সইয়ের সমস্যার দিকে ইঙ্গিত করে; সংযোগ ত্রুটি রাউটিং, DNS বা প্রক্সির দিকে। দুটি ফলাফলই রাখুন, কারণ একটি সফল আনয়ন পুরো চেইন ব্যবহারযোগ্য বলে প্রমাণ করে না। উদাহরণের হোস্ট ও পথ বদলে সার্টিফিকেটে পাওয়া বিতরণ পয়েন্ট বসান।

অনুপস্থিত তথ্য আর প্রত্যাহৃত অবস্থা আলাদা করুন

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

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