openssl ca: index.txt-এ অবৈধ মেয়াদ শেষের তারিখ, এবং এটি কীভাবে ঠিক করবেন

একটি ইস্যু রান থেমে যায় entry 22: invalid expiry date দিয়ে, অথচ আপনার সামনে থাকা অনুরোধটি সম্পূর্ণ ঠিক আছে। অভিযোগটি আসে CA ডাটাবেস পার্সারের কাছ থেকে, CSR থেকে নয় এবং যে VPN ক্লায়েন্ট শেষে সার্টিফিকেটটি উপস্থাপন করবে তার থেকেও নয়। এই পার্থক্যই পরের সবকিছু নির্ধারণ করে: রেকর্ডটি বিকৃত, তাই মেরামতের জায়গা CA-এর অবস্থায়, অনুরোধে বা পিয়ার কনফিগারেশনে নয়। সংখ্যাযুক্ত এন্ট্রিটিকে index.txt-এর একটি লাইন হিসেবে ধরুন, তাহলে সমস্যাটি যাচাইযোগ্য উত্তরসহ একটি সীমিত ডেটা প্রশ্নে নেমে আসে।

ত্রুটিটিকে ডাটাবেসের অভিযোগ হিসেবে পড়ুন

প্রতিটি openssl ca আহ্বান কিছু স্বাক্ষর করার আগে নিজের টেক্সট ডাটাবেস ঘেঁটে দেখে। প্রতিটি লাইনে থাকে একটি স্ট্যাটাস অক্ষর, একটি মেয়াদ শেষের টাইমস্ট্যাম্প, ঐচ্ছিক একটি রিভোকেশন টাইমস্ট্যাম্প, হেক্সে একটি সিরিয়াল, একটি ফাইলনাম এবং সাবজেক্ট। কোনো একটি ফিল্ড পার্স না হলে কমান্ডটি লাইন নম্বর জানিয়ে থেমে যায়, বাকি রেকর্ড নিয়ে অনুমান করার বদলে।

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

কিছু স্পর্শ করার আগে CA-এর অবস্থার কপি নিন

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

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

এন্ট্রিটি খুঁজুন এবং তার তারিখ ফিল্ড ডিকোড করুন

যে লাইন নম্বরটি জানানো হয়েছে তা প্রথম রেকর্ড থেকে গণনা করা হয়, তাই sed -n '22p' index.txt সমস্যা তৈরি করা এন্ট্রিতেই পড়ে, একবার আপনি নিশ্চিত করার পরে যে তার ওপরে কোনো ফাঁকা বা মন্তব্য লাইন নেই। লাইনটি দৃশ্যমান ডেলিমিটারসহ প্রিন্ট করুন, কারণ ট্যাব ও শেষে থাকা স্পেস সাধারণ এবং সাধারণ এডিটর উইন্ডোতে অদৃশ্য।

মেয়াদ ফিল্ডটি একটি টাইমস্ট্যাম্প যার প্রস্থ নির্ভর করে বছরের ওপর। 2049 পর্যন্ত মান UTCTime-এ YYMMDDHHMMSSZ আকারে লেখা হয়, আর পরের মানগুলো চার-সংখ্যার বছরসহ GeneralizedTime-এ চলে যায়। যে রেকর্ড দুই রূপ মিশিয়ে দেয়, বা যেখানে পার্সার এখন চার অঙ্ক আশা করে সেখানে দুই-অঙ্কের বছর বহন করে, সেটি ঠিক এই জায়গাতেই ব্যর্থ হয়। কোনো বিচ্ছিন্ন লেখার ফলে পিছনে পড়ে থাকা ছোট হয়ে যাওয়া ফিল্ডও তেমনই।

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

স্বাক্ষরিত সার্টিফিকেটের বিপরীতে রেকর্ডটি মেরামত করুন

আসল তারিখগুলো পড়ুন openssl x509 -in issued.pem -noout -dates -serial -subject দিয়ে। notAfter কে সেই বছরের জন্য আপনার বিল্ড যে প্রস্থের টাইমস্ট্যাম্প লেখে তাতে রূপান্তর করুন, এবং একটি অক্ষরও বদলানোর আগে নিশ্চিত করুন যে সিরিয়ালটি আপনি যে এন্ট্রি সম্পাদনা করতে চলেছেন তার সঙ্গে মেলে।

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

বছর নিয়ে অনুমানের সঙ্গে মেলাতে তারিখ কেটে ছোট করে মেরামত করবেন না। দুই অক্ষরের কাটছাঁট বিল্ডগুলোর মধ্যে বহনযোগ্য নয়, এবং এটি নিরবে সেই বৈধতা বদলে দেয় যা ডাটাবেস ভবিষ্যতের ডুপ্লিকেট-সাবজেক্ট ও CRL যাচাইকে জানায়। মূল মানটি যদি পুনরুদ্ধারযোগ্য না হয়, তবে নতুন সিরিয়ালে পুনরায় ইস্যু করুন এবং পুরোটিকে কেন পরিত্যাগ করা হলো তা লিখে রাখুন। অডিট ট্রেইল মেরামতেরই অংশ, তার চারপাশের কাগজপত্র নয়।

যাওয়ার আগে ইস্যু ও CRL তৈরি যাচাই করুন

একই কনফিগারেশন দিয়ে একটি ইস্যু চালান এবং নিশ্চিত করুন যে এটি লাইন নম্বরের অভিযোগ ছাড়াই শেষ হয়। তারপর openssl ca -gencrl -config openssl.cnf দিয়ে একটি CRL তৈরি করুন এবং দেখুন এটি পার্স হয় কি না, কারণ ক্ষতিগ্রস্ত রেকর্ড প্রায়ই স্বাক্ষরের সময় নয়, বরং ঠিক সেখানেই সামনে আসে।

নতুন সার্টিফিকেটটি পরীক্ষা করুন openssl x509 -noout -dates -serial দিয়ে এবং CA এইমাত্র যে লাইন লিখেছে তার সঙ্গে মিলিয়ে দেখুন। নিশ্চিত করুন যে স্ট্যাটাস অক্ষর ও মেয়াদ সার্টিফিকেটের সঙ্গে মেলে, এবং নিশ্চিত করুন যে openssl verify -CAfile ca.pem issued.pem ত্রুটি ছাড়াই ফিরে আসে। তারপর নির্ধারিত ইস্যু ফিরিয়ে আনুন এবং প্রথম রানটি লক্ষ্য করুন, কারণ দ্বিতীয় বিকৃত লাইন সঙ্গে সঙ্গে নিজের কথা জানিয়ে দেবে।