VPN সার্টিফিকেট এখনো বৈধ নয়: তিন কারণ, এক পরীক্ষার ক্রম
এখনো বৈধ নয় মানে ডিভাইসের ঘড়ি পিছিয়ে আছে, উইন্ডোটি সত্যিই পরে শুরু হয়, বা একটি মধ্যবর্তী সার্টিফিকেট এখনো খোলেনি। এই ক্রমে সেগুলো পরীক্ষা করুন।
আপনি ক্লায়েন্ট খোলেন, মাসের পর মাস ব্যবহার করা প্রোফাইলটি বেছে নেন, আর এটি "certificate is not yet valid" বলে থেমে যায়। আপনার সাইন-ইনে কিছুই বদলায়নি, আর ট্রাস্ট স্টোর সম্ভবত ঠিকই আছে: হ্যান্ডশেকে উপস্থাপিত সার্টিফিকেটের বৈধতার উইন্ডোটি যাচাইকারীর ব্যবহৃত মুহূর্তের চেয়ে পরে শুরু হয়। তিনটি ভিন্ন পরিস্থিতি ঠিক এই বার্তাটিই তৈরি করে, এবং তাদের জন্য ভিন্ন পদক্ষেপ দরকার। নিচের ক্রমটি ঘড়ি বা সার্টিফিকেট ফাইলে হাত দেওয়ার আগেই বলে দেবে আপনার কোনটি আছে।
তিন কারণের মধ্যে কোনটি আপনি দেখছেন
প্রথম কারণটি স্থানীয়: যে ডিভাইস যাচাই করছে তার ঘড়ি সার্টিফিকেটের শুরুর তারিখের চেয়ে আগে। এটি দেখা যায় মৃত CMOS ব্যাটারিওয়ালা হার্ডওয়্যারে, পুরোনো স্ন্যাপশট থেকে পুনরুদ্ধার করা ভার্চুয়াল মেশিনে, যথেষ্ট সময় বন্ধ থাকায় সময় হারানো অ্যাপ্লায়েন্সে, এবং এমন নেটওয়ার্কে যেখানে আউটবাউন্ড NTP ব্লক করা আর কেউ খেয়াল করেনি। সার্টিফিকেট পুরোপুরি বৈধ হয়েও এভাবে ব্যর্থ হতে পারে।
দ্বিতীয় কারণটি ইস্যুকারীর, কারণ সার্টিফিকেটটি সত্যিই ভবিষ্যতে শুরু হয়: আগেভাগে ইস্যু করা, স্পষ্ট শুরুর সময় দিয়ে তৈরি, বা এখনো না-চলা কোনো অ্যাক্টিভেশন ধাপের অংশ হিসেবে স্বাক্ষরিত। তৃতীয় কারণটি সবচেয়ে বেশি সময় নষ্ট করে, কারণ লিফ সার্টিফিকেটটি চলমান থাকলেও উপস্থাপিত চেইনের আরেকটি সার্টিফিকেট নয়, তাই ত্রুটিটি এমন উপাদানের নাম বলে যা আপনি কখনো ইনস্টল করেননি।
একটি প্রশ্নই এদের আলাদা করে। ব্যর্থতাটি কি ডিভাইসকে অনুসরণ করে নাকি সার্ভিসকে? একই নেটওয়ার্কে দুটি মেশিন ভিন্নভাবে আচরণ করলে তা ঘড়ির দিকে ইঙ্গিত করে। প্রতিটি ক্লায়েন্ট একইভাবে ব্যর্থ হলে তা সার্টিফিকেটের উইন্ডো ও তার পেছনের চেইনের দিকে ইঙ্গিত করে।
যে সার্টিফিকেটটি সত্যিই উপস্থাপিত হয়েছে সেখান থেকেই উইন্ডো পড়ুন
আগের কোনো ডিপ্লয়মেন্ট থেকে পড়ে থাকা PEM ফাইল পরীক্ষা করবেন না; সার্ভিসের কাছে এখন যে চেইন পাঠাচ্ছে তা চান। openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts চেইনের প্রতিটি সার্টিফিকেট প্রিন্ট করে। আপনার দরকারি ব্লকটি সংরক্ষণ করুন এবং openssl x509 -noout -subject -issuer -dates চালান; শেষটি notBefore ও notAfter প্রিন্ট করে, আর এই দুটি মানই সিদ্ধান্ত দেয়। Windows-এ সংযোগের সার্টিফিকেট ডায়ালগ এবং রপ্তানি করা ফাইলে certutil -dump একই ফিল্ড দেখায়।
উইন্ডোর দুই প্রান্তই পড়ুন, শুধু শুরু নয়। দুই ঘণ্টা পরে খোলা একটি সার্টিফিকেট আর দুই ঘণ্টা পরে বন্ধ হওয়া একটি ভিন্ন বার্তায় ব্যর্থ হয় এবং ভিন্ন দল জড়িত করে। ত্রুটি কোন সার্টিফিকেটের নাম নেয় তা লক্ষ করুন — লিফ, মধ্যবর্তী নাকি রুট — কারণ এটাই ঠিক করে ক্লায়েন্টের দিকে আদৌ কিছু ঠিক করা সম্ভব কি না।
উইন্ডোর জন্য অপেক্ষা না করেও পরীক্ষা করা যায়। যাচাই একটি স্পষ্ট সময় গ্রহণ করে: openssl verify -attime 1793600000 -CAfile ca.pem -untrusted intermediate.pem leaf.pem সেই টাইমস্ট্যাম্প অনুযায়ী চেইন মূল্যায়ন করে। ব্যর্থতা পুনরুৎপাদন করতে বর্তমান সময় দিয়ে চালান, তারপর সার্টিফিকেটের শুরুর সময় দিয়ে নিশ্চিত করুন যে উইন্ডো খোলার পর একই চেইন পাস করে। RFC 5280 বৈধতা ফিল্ড এবং এর বাইরে সার্টিফিকেট ব্যবহার না করার নিয়ম সংজ্ঞায়িত করে, আর আপনার ক্লায়েন্ট এইমাত্র সেই নিয়মই প্রয়োগ করেছে।
আপনার ঘড়ি, নাকি তাদের
বিশ্বস্ত উৎস থেকে ডিভাইসের ঘড়িকে UTC-তে সার্টিফিকেটের শুরুর সঙ্গে তুলনা করুন। date -u মুহূর্তটি দেয়, আর systemd হোস্টে timedatectl status ঘড়িটি সিঙ্ক্রোনাইজড কি না তাও জানায়। Windows-এ w32tm /query /status বর্তমান উৎস ও সর্বশেষ সফল সিঙ্ক্রোনাইজেশন দেখায়। ট্রেতে দেখানো টাইমজোন একটি প্রদর্শন-পছন্দ, ভুল ঘড়ি নয়; যাচাইকারী UTC মুহূর্ত তুলনা করে।
| What you see | Most likely reading | Next step |
|---|---|---|
| Clock behind, one device affected | Local time fault | Resync time, keep validation on, retest |
| Clock correct, window opens soon | Certificate staged early | Wait for the window or follow the cutover plan |
| Clock correct, intermediate not yet valid | Chain material mismatch | Operator replaces the intermediate |
| Some peers pass, others do not | Inconsistent nodes | Record each peer's chain before changing anything |
ঘড়ি পিছিয়ে থাকলে, কোনো সার্টিফিকেট উপাদান বদলানোর আগে পুনঃসিঙ্ক্রোনাইজ করে আবার পরীক্ষা করুন। কয়েক মিনিট বা কয়েক ঘণ্টা ভুল থাকা ডিভাইস তার সামনে আসা প্রতিটি সদ্য ইস্যু করা সার্টিফিকেট প্রত্যাখ্যান করে, শুধু একটি সার্ভিস নয়, তাই এক-সার্ভিস ব্যাখ্যা সাধারণত ভুল ব্যাখ্যা। ঘড়ি সঠিক ও সিঙ্ক্রোনাইজড হলে ডিভাইসের দিকে তাকানো বন্ধ করুন: উইন্ডোটি ইস্যুকারীর, আর এটি পাস করানোর জন্য কোনো স্থানীয় সেটিং বদলানো উচিত নয়।
ওই টেবিলটাই পুরো সিদ্ধান্ত। সার্টিফিকেট যা আশা করে সেখানে ঘড়ি সরানো কোনো মেরামত নয়, সময়-পরীক্ষা বন্ধ করাও মেরামত নয়, কারণ দুটোই ত্রুটি তৈরি করা অবস্থাটি লুকায়।
লিফ ঠিক থাকলেও চেইন কেন ব্যর্থ হয়
নবায়ন করা লিফ ও প্রতিস্থাপনকারী মধ্যবর্তী সার্টিফিকেট সাধারণত একসঙ্গে পাঠানো হয়, আর সবসময় একই মুহূর্তে পৌঁছায় না। একটি সার্ভিস এমন মধ্যবর্তী দিয়ে স্বাক্ষরিত নতুন লিফ পাঠাতে পারে যার নিজের উইন্ডো পরে শুরু হয়, বা নতুন লিফের অধীনে পুরোনো মধ্যবর্তী পরিবেশন চালিয়ে যেতে পারে। দুই ক্ষেত্রেই লিফের নিজের তারিখ যুক্তিসঙ্গত দেখালেও চেইন ব্যর্থ হয়।
লোড-ব্যালান্সড এন্ডপয়েন্ট এটি ভাঙা থেকে অসামঞ্জস্যপূর্ণে বদলে দেয়। পুনরায় চেষ্টা সফল হলে, বা একটি নেটওয়ার্ক চললেও অন্যটি না চললে, সেটিংস বদলানোর আগে কোন পিয়ার উত্তর দিয়েছে ও কোন চেইন পাঠিয়েছে তা লিখে রাখুন। openssl s_client সংযুক্ত ঠিকানাটি প্রিন্ট করে, তাই কয়েকটি চেষ্টাই প্রকাশ করে প্রতিটি নোড একই চেইন পরিবেশন করে কি না।
যে মেরামত-পথ যাচাই অক্ষত রাখে
ঘড়ির সমস্যা ডিভাইসেই ঠিক হয়, যাচাই চালু রেখেই। সার্টিফিকেটের সমস্যা অপারেটর ঠিক করেন এখনকার সময় অন্তর্ভুক্ত উইন্ডোর জন্য ইস্যু করা উপাদান দিয়ে। কোনো ক্লায়েন্ট সেটিং এখনো-অবৈধ সার্টিফিকেটকে বৈধ করে না; সময়-পরীক্ষা এড়ানো ফ্ল্যাগগুলো রোগনির্ণয় নিশ্চিত করার জন্য, সেগুলো চালু রাখার জন্য নয়।
সার্টিফিকেট পরিকল্পিত অ্যাক্টিভেশনের জন্য প্রস্তুত করা হলে কাটওভার পরিকল্পনা অনুসরণ করুন। উইন্ডো খোলার সময় এটি ইনস্টল করুন, বা প্রোভাইডার যে ওভারল্যাপ পদ্ধতি নথিভুক্ত করেছে তা ব্যবহার করুন, আগেভাগে ইনস্টল করে ব্যবহারকারীদের সতর্কবার্তা ডিঙাতে শেখানোর বদলে। মানুষ যেসব সতর্কবার্তা উপেক্ষা করতে শেখে সেগুলো সামান্য বিলম্বের চেয়ে বেশি খরচ করায়।
শেষে, যে ভাবে ব্যর্থতা ঘটেছিল সেই ভাবেই আবার পরীক্ষা করুন: নতুন সেশন, একই ক্লায়েন্ট, আপনার সত্যিই দরকারি রিসোর্স। TLS লাইব্রেরি সংযোগের আয়ু পর্যন্ত যাচাই করা চেইন ক্যাশে রাখতে পারে, আর পুনরায় শুরু করা সেশন সেটি আবার পরীক্ষা করে না, তাই পুরোনো সেশন মেরামতের পরেও ব্যর্থ হতে পারে বা রিগ্রেশনের পরেও কাজ করতে পারে। ভিউয়ারে খোলা ফাইল শুধু প্রমাণ করে ফাইলটি পাঠযোগ্য; সম্পূর্ণ হ্যান্ডশেক প্রমাণ করে চেইনটি যাচাই হয়।
টিকিট বন্ধ করার আগে চারটি বিষয় নিশ্চিত করুন: ব্যর্থ ডিভাইসের UTC সময় ও সিঙ্ক অবস্থা, উপস্থাপিত চেইনের প্রতিটি সার্টিফিকেটের notBefore ও notAfter, দ্বিতীয় ক্লায়েন্ট থেকে একই চেইন, এবং ত্রুটি সার্টিফিকেটকে যে নাম দেয় তা। ঘড়ি সঠিক হলে ও উইন্ডো না খুললে বাকিটা অপারেটরের কাজ, আর আপনার দিকের সঠিক পদক্ষেপ হলো যাচাই দুর্বল করার বদলে উইন্ডোর জন্য অপেক্ষা করা।