সার্টিফিকেট ত্রুটিতে আমদানি ব্যর্থ হয়, তাই প্রথমেই যে পদক্ষেপটি স্বাভাবিক মনে হয় তা হলো রূপান্তর। এই প্রবণতা মানুষকে এমন পথে নেয় যেখানে ফাইলের এক্সটেনশন বদলায়, কিন্তু প্রত্যাখ্যান হুবহু একই থাকে। authorized_keys-এ একটি ssh-ed25519 লাইন আর একটি OpenVPN ক্লায়েন্ট সার্টিফিকেট আলাদা পরিচয়পত্র-বস্তু, যাদের ইস্যুকারী আলাদা, এনকোডিং আলাদা আর প্রত্যাহারের পথও আলাদা। এই যাচাইগুলো ক্রমে করলে এক মিনিটেই বোঝা যায় রূপান্তর আদৌ কাজে লাগবে কি না।

আপনার হাতে আসলে কোন বস্তু আছে?

মানুষ পাঁচটি জিনিসকে কী বলে, আর তার মধ্যে একটিই এমন যা একটি TLS প্রোফাইল চায়। একটি SSH পাবলিক কী হলো টাইপ প্রিফিক্স আর base64 পেলোডসহ এক লাইনের লেখা। একটি OpenSSH সার্টিফিকেট হলো সেই কী-এর সঙ্গে একটি স্বাক্ষর, প্রিন্সিপাল ও অপশন, যা ssh-keygen নিজেই ছোট CA হিসেবে তৈরি করে। একটি X.509 সার্টিফিকেট সম্পূর্ণ আলাদা গঠন, যাতে থাকে সাবজেক্ট, বৈধতার সময়সীমা, এক্সটেনশন আর সার্টিফিকেট কর্তৃপক্ষের স্বাক্ষর। প্রাইভেট কী হলো গোপন অর্ধাংশ, আর ইস্যু করা বান্ডল সাধারণত একটি ফাইলে সার্টিফিকেট, তার চেইন আর প্রাইভেট কী।

প্রথম পরীক্ষায় একটিই কমান্ড লাগে। openssl-কে ফাইলটির দিকে নির্দেশ করে সার্টিফিকেটের গঠন পার্স করতে বলুন:

openssl x509 -in client.crt -noout -subject -issuer

এটি যদি unable-to-load বা PEM ত্রুটিতে ব্যর্থ হয়, তবে ফাইলটির নাম যা-ই দিন না কেন, এটি X.509 সার্টিফিকেট নয়। নাম বদলালে ভেতরের ASN.1 পুনরায় লেখা হয় না, আর পাবলিক কী-এর লাইনকে PEM হেডার টেক্সটে মুড়লেও তা হয় না।

প্রোফাইলটি আদৌ সার্টিফিকেট চায় কি?

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

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

পুনরায় এনকোডিং কী করতে পারে আর কী পারে না

প্রাইভেট কী-এর সত্যিই বৈধ বিকল্প ধারক আছে। একই RSA বা EC কী ঐতিহ্যবাহী PEM হিসেবে, PKCS#8 হিসেবে, বা PKCS#12 বান্ডলের ভেতরে লেখা যায়, আর টুলগুলো আনন্দেই এদের মধ্যে রূপান্তর করে। পাবলিক কী-এরও একই গল্প: ssh-keygen একটি SSH কী-এর RFC 4716 রূপ তৈরি করতে পারে, আর OpenSSH নিজের সার্টিফিকেট ফরম্যাটও বোঝে। এসবই উপস্থাপন, আর উপস্থাপন বিশ্বাস নয়।

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

এই ধাপেই বেশিরভাগ চেষ্টা নীরবে ব্যর্থ হয়: ফাইলটি এখন .crt-তে শেষ হয়, ক্লায়েন্ট তা কোনো অভিযোগ ছাড়াই পড়ে, আর হ্যান্ডশেক তখনও ভেঙে যায় কারণ প্রতিপক্ষ বিশ্বস্ত ইস্যুকারী পর্যন্ত চেইন তৈরি করতে পারে না।

সার্টিফিকেট কর্তৃপক্ষ কোথায় আসে

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

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

SSH কী পুনরায় ব্যবহারের দাম

ধরে নিন একটি রূপান্তর সত্যিই গ্রহণযোগ্য কিছু তৈরি করেছে। SSH প্রবেশ আর VPN প্রমাণীকরণে একই কী জোড়া পুনরায় ব্যবহার করলে তবুও দুটি স্বাধীন নিরাপত্তা সিদ্ধান্ত জুড়ে যায়। authorized_keys থেকে একটি লাইন মুছলে SSH লগইন বন্ধ হয়, আর একই পাবলিক কী-এর জন্য VPN CA যে সার্টিফিকেট ইতিমধ্যে ইস্যু করেছে তাতে কিছুই হয় না। VPN দিকটি নিজের ব্যবস্থায় প্রত্যাহার হয়, অর্থাৎ সার্টিফিকেট প্রত্যাহার তালিকা বা অপারেটরের নিবন্ধন রেকর্ডের মাধ্যমে।

তাই চেকলিস্ট শেষ হয় থামার শর্তে, কোনো কৌশলে নয়। openssl যদি ফাইলটিকে সার্টিফিকেট হিসেবে পার্স না করে, রূপান্তর থামিয়ে বলুন আপনার কাছে কী আছে: SSH কী, SSH সার্টিফিকেট, X.509 সার্টিফিকেট, প্রাইভেট কী, বা বান্ডল। প্রোফাইল যদি ক্লায়েন্ট সার্টিফিকেট না চায়, থামুন এবং জিজ্ঞাসা করুন সার্ভার কোন প্রমাণীকরণ পদ্ধতি প্রত্যাশা করে। কেবল যখন দুটি উত্তরই X.509-এর দিকে নির্দেশ করে তখনই নিবন্ধন পরের ধাপ হয়, আর প্রথম বাক্যেই সঠিক বিশেষ্য থাকলে সেই কথাবার্তা অনেক দ্রুত হয়।

সম্পর্কিত নিবন্ধ