PKCS12, PEM নাকি DER: VPN ক্লায়েন্টের আসলে কী দরকার
মোড়ক ঠিক করে আপনার ক্লায়েন্ট পরিচয়টি আমদানি করবে কি না, তা নয় যে পরিচয়টি বিশ্বাসযোগ্য। PKCS12, PEM ও DER তুলনা করুন তারপর যাচাই করুন।
সার্টিফিকেট আলোচনায় দুটি দাবি ঘোরে। প্রথমটি, .p12 শক্তিশালী বিকল্প আর .pem দুর্বল; দ্বিতীয়টি, একটি টেক্সট ফাইল পাঠানো নিরাপদ কারণ আপনি তা পড়তে পারেন। কোনোটিই এক মিনিটের পরীক্ষায় টেকে না।
PKCS12, PEM ও DER বলে সার্টিফিকেট অবজেক্ট কীভাবে মোড়ক ও এনকোড হয়। তারা ঠিক করে না প্রতিপক্ষ কে, ইস্যুকারী বিশ্বাসযোগ্য কি না, বা ফাইলে পাসওয়ার্ড লাগবে কি না।
ক্লায়েন্ট কী গ্রহণ করে তা সামঞ্জস্যের প্রশ্ন। ফাইলে কী আছে তা পরিচয়ের প্রশ্ন। এই দুটো আলাদা রাখলে বেশিরভাগ আমদানি ত্রুটি রহস্যময় থাকা বন্ধ করে।
তিনটি ধারক, একটিই অবজেক্ট মডেল
আপনার কাছে আসলে কী আছে তা দিয়ে শুরু করুন। সার্টিফিকেট হলো একটি পাবলিক কী সম্পর্কে স্বাক্ষরিত বিবৃতি। প্রাইভেট কী আলাদা উপাদান যা প্রমাণ করে আপনি সেই কী নিয়ন্ত্রণ করেন। চেইন হলো সেই ইস্যুকারীদের সমষ্টি যা আপনার সার্টিফিকেটকে ক্লায়েন্টের বিশ্বাসযোগ্য রুটের সঙ্গে যুক্ত করে। মোড়ক যাই হোক, তিনটিই বিদ্যমান।
PKCS12 ফাইল, সাধারণত .p12 বা .pfx, RFC 7292-এ সংজ্ঞায়িত ধারক যা একটি প্রাইভেট কী, এক বা একাধিক সার্টিফিকেট ও চেইন একটি পাসওয়ার্ড-সুরক্ষিত ব্লকে রাখতে পারে, সঙ্গে পরিচয়ের নাম দেওয়া একটি এলিয়াস। PEM ফাইল RFC 7468-এ সংজ্ঞায়িত টেক্সট ফ্রেমিং: BEGIN ও END লাইনের মাঝে base64 বডি, এবং এক ফাইলে পরপর কয়েকটি ব্লক থাকতে পারে। DER একই ASN.1 কাঠামোর বাইনারি এনকোডিং, আর PEM বডি আক্ষরিকভাবে base64-এ মোড়া DER।
শেষ বাক্যটি মনে রাখার মতো। PEM থেকে DER-এ রূপান্তর মোড়ক পুনর্লিখন করে, বিষয়বস্তু নয়, আর ফিরিয়ে আনলে মূল বাইট ফেরে।
| Container | Can hold | Does not decide |
|---|---|---|
| PKCS12 (.p12, .pfx) | Key, leaf certificate, chain, alias, password | Which root the client trusts |
| PEM (.pem, .crt, .cer) | Any number of base64 blocks | Whether the private key is present |
| DER (.der, .cer) | One binary structure | The object type, whatever the extension says |
এনকোডিং এনক্রিপশন নয়
base64 একটি পরিবহন বর্ণমালা। এটি কিছু লুকায় না, আর যে কেউ শেলে একটি PEM ব্লক ডিকোড করতে পারে। DER ফাইল বাইনারি এবং সমানভাবে প্রকাশ্য। কোনোটিই সুরক্ষা নয়, আর কোনোটিই পাসওয়ার্ডের অস্তিত্ব বোঝায় না।
আসল সুরক্ষা কী উপাদানে। একটি PKCS12 বান্ডেল পাসওয়ার্ড-উদ্ভূত কী দিয়ে তার বিষয়বস্তু এনক্রিপ্ট করতে পারে। PEM প্রাইভেট কী পুরনো হেডার ব্লকে এনক্রিপ্ট করা যায় বা PKCS#8 EncryptedPrivateKeyInfo-তে রাখা যায়। সার্টিফিকেট একা কিছু গোপন রাখে না, তাই যে এক্সপোর্ট কেবল একটি সার্টিফিকেট দেয়, সে ক্লায়েন্টকে প্রমাণীকরণ করতে দেয় না, যেকোনো ফরম্যাটে মোড়ালেও।
এক্সটেনশন ইঙ্গিত, চুক্তি নয়। .cer ও .crt-এ শেষ হওয়া ফাইল দুই এনকোডিং-এই দেখা যায়, আর অ্যাপ্লায়েন্সগুলো DER সার্টিফিকেট .pem নামে এতই বেশি এক্সপোর্ট করে যে প্রত্যয় দেখে অনুমান করলে এক বিকেল নষ্ট হয়। বরং প্রথম বাইট পড়ুন: PEM ফাইল BEGIN লাইন দিয়ে শুরু হয়, আর DER শুরু হয় 0x30 দিয়ে কারণ বাইরের কাঠামো SEQUENCE।
আমদানি আসলে কেন ব্যর্থ হয়
ক্লায়েন্টের ত্রুটি বার্তা কয়েকটি ভিন্ন সমস্যাকে অবৈধ সার্টিফিকেট সম্পর্কে এক বাক্যে চেপে দেয়, তাই কারণ অনুযায়ী আলাদা করুন। সবচেয়ে সাধারণ হলো এনকোডিং অমিল: যে ক্লায়েন্ট PEM পার্স করে, সে DER ফাইলে পার্স ত্রুটি দেয়, আর সমাধান নতুন সার্টিফিকেট নয়, রূপান্তর। দ্বিতীয়টি অনুপস্থিত কী, যেখানে সার্টিফিকেট ঠিক আছে কিন্তু পরিচয় প্রমাণ করা যায় না। তৃতীয়টি চেইন, যেখানে অন্তর্বর্তী সার্টিফিকেট ছাড়া বান্ডেল আমদানি ডায়ালগে সঠিক দেখায় আর হ্যান্ডশেকে ব্যর্থ হয়।
এনক্রিপশন প্যারামিটার চতুর্থটি ঘটায়, আর তা দেখতে হুবহু ভুল পাসওয়ার্ডের মতো। পুরনো অ্যাপ্লায়েন্স PKCS12 ফাইল RC2-40 ও 3DES দিয়ে এক্সপোর্ট করত, যা OpenSSL 3 প্রত্যাখ্যান করে যদি লেগ্যাসি প্রোভাইডার লোড না থাকে। অ্যাপ্লায়েন্স থেকে AES-256-CBC ও PBKDF2 দিয়ে পুনরায় এক্সপোর্টই স্থায়ী সমাধান। একটি ফাইলের জন্য ক্লায়েন্ট মেশিনে পুরনো সাইফার স্থায়ীভাবে চালু রাখা খারাপ লেনদেন।
পঞ্চমটি অস্পষ্টতা। দুই কী ও দুই সার্টিফিকেটযুক্ত ধারক, বা তিনটি CERTIFICATE ব্লকযুক্ত PEM ফাইল ক্লায়েন্টকে বাছতে বাধ্য করে, আর তার পছন্দ প্রায়ই শুধু প্রথম আইটেম। টানেল ভুল পরিচয়ে উঠলে সাধারণত এটাই কারণ।
রূপান্তরের আগে পরীক্ষা করুন
গোপন তথ্য না ছেপে কাঠামো পড়ুন। openssl pkcs12 -in bundle.p12 -info -noout এনক্রিপশন অ্যালগরিদম ও এলিয়াস জানায় আর কী ও সার্টিফিকেটের আউটপুট চেপে দেয়, আর openssl-pkcs12 ম্যানুয়াল ফ্ল্যাগগুলো নথিভুক্ত করে। -noout বাদ দেওয়া ও -nodes যোগ করা এমন ফাইল তৈরির জন্য যেগুলো আপনি রাখবেন, দ্রুত দেখার জন্য নয়, কারণ এটি প্রাইভেট কী স্পষ্টভাবে লেখে।
সার্টিফিকেটের ক্ষেত্রে openssl x509 -in cert.pem -noout -subject -issuer -dates তা উত্তর দেয় যা আমদানি ডায়ালগ দেয় না, আর -ext subjectAltName যোগ করলে দেখা যায় সার্টিফিকেট আসলে কোন নামের জন্য বৈধ। ফাইল DER হলে -inform DER যোগ করুন; এই একটিমাত্র ফ্ল্যাগ বেশিরভাগ unable-to-load ত্রুটি মেটায়।
কী-কে সার্টিফিকেটের সঙ্গে মেলানো যান্ত্রিক কাজ, আর যেকোনো আমদানির আগে করা উচিত:
openssl x509 -in cert.pem -noout -pubkey | openssl sha256openssl pkey -in key.pem -pubout | openssl sha256
একই ডাইজেস্ট মানে জোড়াটি একসঙ্গে খাপ খায়। ভিন্ন ডাইজেস্ট মানে আপনার কী ভুল, আর কোনো ফরম্যাট রূপান্তর তা বদলাবে না।
ফরম্যাট যা কখনো বদলায় না
বিশ্বাসের সিদ্ধান্ত ধারকের উপরে হয়। ক্লায়েন্ট তার স্টোরের একটি রুট পর্যন্ত চেইন হাঁটে, বৈধতার জানালা দেখে, ক্লায়েন্ট প্রমাণীকরণের জন্য বর্ধিত কী ব্যবহার দেখে, আর সার্ভার পাশে দেখে যে ডায়াল করা নামটি সার্টিফিকেটে আছে। এই ধাপগুলোর কোনোটিই ফাইল এক্সটেনশন পড়ে না।
তাই ত্রুটি না মেলা পর্যন্ত ফাইলের নাম বদলানো সময় নষ্ট করার এত নির্ভরযোগ্য উপায়। আমদানি সফল হয়, পরিচয় তবু ভুল থাকে, আর ব্যর্থতা হ্যান্ডশেকে ফিরে আসে যেখানে বার্তা কম সহায়ক। তাই দু বছর আগে এক্সপোর্ট করা বান্ডেল পরিষ্কারভাবে আমদানি হয় আর তবু প্রত্যাখ্যাত হয়: মেয়াদ শেষের তারিখ ফাইলের নামে নয়, সার্টিফিকেটের ভিতরে ভ্রমণ করেছে।
পুনর্কাজ এড়ানোর একটি ক্রম
ক্লায়েন্টের ডকুমেন্টেশনে জিজ্ঞাসা করুন কোন এনকোডিং গ্রহণ করে ও ক্লায়েন্ট পরিচয়ের জন্য কোন ধারক আশা করে, তারপর দেখুন আপনাকে কী দেওয়া হয়েছে। ক্লায়েন্ট একটি আমদানযোগ্য পরিচয় চাইলে আর আপনার কাছে আলাদা PEM ফাইল থাকলে, নিজের নিয়ন্ত্রণে থাকা পাসওয়ার্ড দিয়ে একবার বান্ডেল বানান ও উৎস রাখুন। PEM চাইলে কী ও চেইন বের করুন, তারপর আপনার দল ইতিমধ্যে ব্যবহার করা শংসাপত্র-ব্যবস্থাপনা প্রক্রিয়ায় মধ্যবর্তী ফাইলগুলো মুছুন।
আমদানির পরে ডায়ালগ নয়, পরিচয় যাচাই করুন: সাবজেক্ট, ইস্যুকারী, মেয়াদ এবং ক্লায়েন্ট যে নাম উপস্থাপন করবে। তালিকার বন্ধুত্বপূর্ণ নাম একটি লেবেল, যাচাইকৃত পরিচয় নয়। এরপর টানেল ব্যর্থ হলে আপনি মোড়কের বদলে প্রমাণীকরণ বা রাউটিং ডিবাগ করছেন, যা অনেক ছোট আলাপ।