লিফ সার্টিফিকেট বৈধ, চেইন মেয়াদোত্তীর্ণ: গভীরতা পড়ুন

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

গভীরতা ব্যর্থ সার্টিফিকেটের নাম বলে

OpenSSL ডায়াগনস্টিকসে গভীরতা 0 হলো লক্ষ্য সার্টিফিকেট এবং গভীরতা 1 হলো তাতে স্বাক্ষরকারী ইস্যুয়ার, আর বড় সংখ্যাগুলো ট্রাস্ট অ্যাঙ্করের দিকে চলতে থাকে। গভীরতা 1-এ রিপোর্ট করা মেয়াদোত্তীর্ণতা লিফের চলমান notAfter দ্বারা খণ্ডন হয় না, তাই দৃশ্যমান সার্টিফিকেট আবার পরীক্ষা করলে ত্রুটিটি কখনো ব্যাখ্যা হবে না।

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

একাধিক সার্টিফিকেট ভূমিকা থাকা পণ্যেও খেয়াল রাখুন। OpenVPN Access Server-এ ওয়েব ইন্টারফেস রক্ষা করা সার্টিফিকেটগুলো VPN সংযোগের জন্য ব্যবহৃতগুলো থেকে আলাদা, তাই অ্যাডমিন পৃষ্ঠা খোলা একটি ব্রাউজার টানেলের পথ সম্পর্কে কিছুই প্রমাণ করে না।

ট্রাস্ট ইনপুট আর চেইন প্রার্থী এক নয়

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

$ openssl verify -verbose -show_chain -purpose sslserver \
    -CAfile trusted-roots.pem -no-CApath -no-CAstore \
    -untrusted intermediates.pem server.pem

-no-CApath -no-CAstore দিয়ে ডিফল্ট পথ ও স্টোর বন্ধ রাখা পরীক্ষাটিকে সৎ রাখে: ফলাফল তখন আপনার নাম দেওয়া ফাইলগুলোর উপর নির্ভর করে, ওয়ার্কস্টেশন দৈবক্রমে যা বিশ্বাস করে তার উপর নয়। OpenSSL যাচাই রেফারেন্স এই অপশনগুলো এবং সেগুলো যে ডায়াগনস্টিকস তৈরি করে তা নথিভুক্ত করে।

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

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

পরীক্ষাটি কী প্রমাণ করে আর কী বাদ দেয়

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

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

প্রতিটি সার্টিফিকেটের জানালা একবারে একটি করে না দেখে সেট হিসেবে দেখতে এভাবে ছাপুন:

$ openssl x509 -in server.pem -noout -subject -dates
$ openssl crl2pkcs7 -nocrl -certfile intermediates.pem \
    | openssl pkcs7 -print_certs -noout

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

যাচাই দুর্বল না করেই পথ মেরামত করুন

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

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

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