ca md too weak: সার্টিফিকেট পুনরায় ইস্যু করবেন নাকি লেভেল কমাবেন?
ত্রুটিটি এখন ক্লায়েন্ট যে সিগনেচার ডাইজেস্ট প্রত্যাখ্যান করছে তার নাম দেয়, দুর্বল পাসওয়ার্ড নয়। চেইন পুনরায় ইস্যু, ইস্যুকারীকে জিজ্ঞাসা, নাকি নীতি কমানো — সিদ্ধান্ত নিন।
OpenVPN ক্লায়েন্ট গত মাসে কাজ করত, এখন স্টার্টআপের সময় ca md too weak নিয়ে ব্যর্থ হচ্ছে, অথচ ডিস্কে থাকা প্রোফাইলটি বাইটে বাইটে সেই একই যা কাজ করত। বার্তাটি একটি সার্টিফিকেট অথরিটির সার্টিফিকেটের সিগনেচার নিয়ে, ডেটা সাইফার, auth ডাইজেস্ট বা অ্যাকাউন্ট পাসওয়ার্ড নিয়ে নয়। তিনটি শর্ত ঠিক করে সমাধানটি নতুন পরিচয় উপাদান, নতুন চেইন, নাকি ইচ্ছাকৃত নীতি পরিবর্তন। ক্রম অনুসারে এগুলো কাজে লাগান, তাহলে হোস্টের প্রতিটি TLS সংযোগ দুর্বল করে টানেল ফিরিয়ে আনার চেনা পরিণতি এড়াতে পারবেন।
ত্রুটি আসলে কী নির্দেশ করে
OpenSSL এই যাচাই ত্রুটিটি তোলে যখন এটি চেইন তৈরি করে, যদি CA হিসেবে কাজ করা সার্টিফিকেটে এমন সিগনেচার ডাইজেস্ট থাকে যা লাইব্রেরির নিরাপত্তা স্তর আর গ্রহণ করে না। ডিফল্ট স্তরে MD5 প্রত্যাখ্যাত হয়, আর স্তর বাড়ালে SHA-1 প্রত্যাখ্যাত হয়। এখানে লিফ সার্টিফিকেটের ডাইজেস্টের চেয়ে এটি যে ইস্যুকারী সাইন করে তার ডাইজেস্ট বেশি গুরুত্বপূর্ণ। একই নীতি এমন রুটও প্রত্যাখ্যান করতে পারে যা ইস্যুর দিন সম্পূর্ণ সাধারণ ছিল।
তাই auth বা data-ciphers সম্পাদনা করলে এই ব্যর্থতায় কিছুই হয় না। ওই সেটিংস নিয়ন্ত্রণ করে হ্যান্ডশেকের পরে প্যাকেট কীভাবে সুরক্ষিত হয়, অথচ প্রত্যাখ্যাত বস্তুটি এমন এক পরিচয়পত্র যা টানেল তৈরির আগেই যাচাই করা হয়। একটি সার্টিফিকেট তার বৈধতার সময়সীমার ভেতরে আরামে থাকতে পারে এবং তবুও এমন সিগনেচার বহন করতে পারে যা লাইব্রেরি গ্রহণ করবে না।
যাচাইগুলো আলাদা করে মনে রাখুন, ত্রুটিটি রহস্যময় দেখানো বন্ধ করবে। বৈধতার তারিখ, কী ব্যবহার এবং সিগনেচার ডাইজেস্ট স্বতন্ত্র পরীক্ষা, আর তাদের ঠিক একটি এইমাত্র ব্যর্থ হয়েছে।
প্রথম শর্ত: প্রত্যাখ্যাত বস্তুটি কি রুট?
প্রোফাইলের প্রতিটি সার্টিফিকেট প্রিন্ট করুন এবং subject ও issuer ফিল্ড পড়ুন। স্ব-স্বাক্ষরিত রুটে দুটিতেই একই মান দেখায়, আর তার সিগনেচার অ্যালগরিদমই সেইটি যার ওপর গোটা চেইন দাঁড়িয়ে। দুর্বল ডাইজেস্ট সেখানেই থাকলে তার নিচের প্রতিটি লিফ সমস্যাটি উত্তরাধিকার সূত্রে পায়। subject-এর পাশে অ্যালগরিদমটি লিখে রাখুন, যাতে পরের তুলনাটি মনে রাখার বদলে যান্ত্রিক হয়।
একত্রিত CA ফাইলে প্রায়ই কয়েকটি ব্লক থাকে, তাই প্রথমটিই দোষী ধরে নেওয়ার বদলে আসলে যে ব্লকটি লোড হয় তা চিহ্নিত করুন। কমান্ডটি openssl x509 -in ca.pem -noout -subject -issuer -text একবারে একটি সার্টিফিকেট বর্ণনা করে, অর্থাৎ বান্ডলে বেশি থাকলে আগে তা ভাগ করতে হবে। প্রিন্ট হওয়া সিগনেচার অ্যালগরিদমটি রুট তৈরি হওয়ার যুগে আপনি যে ডাইজেস্ট আশা করবেন তার সাথে মেলান।
দুর্বল রুটের অধীনে SHA-256 দিয়ে স্বাক্ষরিত লিফও ব্যর্থ হয়, কারণ চেইন যাচাই পুরোটা ওপরে ওঠে। এই ক্রমটিই পরের শর্তটিকে গুরুত্বপূর্ণ করে তোলে।
দ্বিতীয় শর্ত: ইস্যুকারী কি আপনার নিয়ন্ত্রণে?
রুট যদি আপনার প্রতিষ্ঠানের হয়, টেকসই সমাধান হলো আধুনিক ডাইজেস্টসহ নতুন রুট এবং পুনরায় ইস্যু করা লিফ, যা একটিমাত্র প্রোফাইল আপডেট হিসেবে দেওয়া হয়। এতে লাগে একটি রক্ষণাবেক্ষণ সময় এবং এমন ডিভাইসের পরিকল্পনা যেগুলো একই দিনে আপডেট নিতে পারে না।
চেইন যদি তৃতীয় পক্ষ ইস্যু করে, সমাধান হলো সেই অপারেটরের কাছে অনুরোধ, আর একমাত্র কাজের স্থানীয় পদক্ষেপ হলো পুরোনো উপাদানের ওপর নির্ভরতা বন্ধ করা। PEM টেক্সট সম্পাদনা বা ফাইলটি আবার সংরক্ষণ করলে সিগনেচার যা ঢাকে তার কিছুই বদলায় না।
একটি মধ্যবর্তী ঘটনা নাম পাওয়ার যোগ্য: অভ্যন্তরীণ রুট যা বর্তমান ডিফল্টের চেয়ে পুরোনো কিন্তু এখনো এমন উপাদানে স্বাক্ষর করে যা অন্য সিস্টেম বিশ্বাস করে। এটি বদলানো মানে প্রতিটি ব্যবহারকারীর নিরীক্ষা, যার মধ্যে সেই অ্যাপ্লায়েন্সগুলোও আছে যারা পুরোনো সার্টিফিকেট ফিঙ্গারপ্রিন্ট দিয়ে পিন করে। পরিবর্তন নির্ধারণের আগে সেই ব্যবহারকারীদের গুনুন, কারণ একটি বাদ পড়া রুট অদলবদল স্টার্টআপ ত্রুটির বদলে বিভ্রাট ডেকে আনে।
তৃতীয় শর্ত: লেভেল কমানো আর কী গ্রহণ করে
নিরাপত্তা স্তর কমানো, বা OpenVPN-এর লিগ্যাসি সার্টিফিকেট প্রোফাইল বেছে নেওয়া, ক্লায়েন্টকে আবার পুরোনো ডাইজেস্ট গ্রহণ করতে দেয়। এটি একই লাইব্রেরির অন্য যাচাইগুলোও শিথিল করে, ওই প্রসেসের প্রতিটি সংযোগের জন্য।
ল্যাবে বা প্রতিস্থাপন উপাদান প্রস্তুত হওয়ার সময় সংক্ষিপ্ত সেতু হিসেবে এটি যুক্তিযুক্ত হতে পারে, যদি ব্যতিক্রমটি একটিমাত্র প্রোফাইলে সীমাবদ্ধ থাকে এবং শেষ তারিখ বহন করে। ভাগ করা হোস্টে স্থায়ী সেটিং হিসেবে এটি নিঃশব্দে বাড়িয়ে দেয় সেখানকার প্রতিটি TLS ক্লায়েন্ট কী বিশ্বাস করবে।
ব্যতিক্রমটি মালিক ও অপসারণের ধাপসহ লিখে রাখুন। নথিভুক্ত না করা লেভেল পরিবর্তন ছয় মাস পরে ভুল থেকে আলাদা করা যায় না, আর পরের প্রকৌশলী জানবেন না এটি কখনো একটি সিদ্ধান্ত ছিল।
সিদ্ধান্তটি, নিয়ম হিসেবে লেখা
ইস্যুকারী আপনার নিয়ন্ত্রণে থাকলে এবং তার ব্যবহারকারীদের তালিকা করতে পারলে চেইনটি প্রতিস্থাপন করুন। না পারলে ইস্যুকারীর কাছে এস্কেলেট করুন। লেভেল কমান শুধু তারিখযুক্ত, সীমিত ব্যতিক্রম হিসেবে, প্রতিস্থাপন আগেই নির্ধারিত থাকলে। অন্য যেকোনো পথ একই সার্টিফিকেট জায়গায় রেখে ঝুঁকিটিকে কম দৃশ্যমান জায়গায় সরিয়ে দেয়।
তারপর পরিষ্কার ক্লায়েন্ট থেকে প্রোফাইলটি আবার পরীক্ষা করুন, হ্যান্ডশেক সম্পূর্ণ হচ্ছে নিশ্চিত করুন, আর এখনো ব্যর্থ হলে প্রত্যাখ্যানের হুবহু লেখাটি রাখুন। একটি নির্ভুল ত্রুটি বার্তাই পরের স্তরের মালিককে দেওয়ার সবচেয়ে সস্তা জিনিস।