VPN কী ফাইলে RSA-র n, e, d, p ও q কোথায় থাকে
n, e, d, p ও q ফাইলের নামে নয়, একটি কাঠামোর ভিতরে থাকে। OpenSSL দিয়ে RSA VPN কী পড়ুন এবং গোপন কিছু ছাপ না করেই তা তার সার্টিফিকেটের সঙ্গে মিলিয়ে দেখুন।
RSA-র ব্যাখ্যায় অক্ষরগুলো একটি বস্তুর ভিতরের ক্ষেত্রের নাম দেয়, PKI টুল যে ফাইল দেয় তার নয়। একটি প্রাইভেট-কী ফাইলে এমন কাঠামো থাকে যার প্রথম ক্ষেত্রগুলো প্রকাশ্য আর পরের ক্ষেত্রগুলোকে টানেল শেষ করে যে মেশিন সেটি কখনো ছেড়ে যেতে পারবে না। এই দুটি তথ্যের মাঝখানে কোন ফাইল কোন প্রশ্নের উত্তর দেয়—এ নিয়ে বেশিরভাগ ব্যবহারিক প্রশ্ন থাকে। এই গাইডটি আগে কাঠামোটি পড়ে, তারপর সেই কমান্ডগুলো যা কিছু ফাঁস না করেই তা পরীক্ষা করে।
মৌলিক সংখ্যা খোঁজার আগে নিশ্চিত করুন কীটি RSA
একটি সার্টিফিকেট প্রমাণ করে কোনো কী আছে এবং স্বাক্ষরিত হয়েছে; এটি প্রমাণ করে না যে কীটি RSA। সিস্টেমগুলো উপবৃত্তীয় বক্ররেখা বা Ed25519-এর উপর গড়া হতে পারে, আর একই ডিরেক্টরি বিন্যাস তাদের সবার কাজে লাগে। যে মৌলিক উৎপাদক কখনো ছিলই না তা খুঁজতে যাওয়ার আগে অ্যালগরিদম যাচাই করুন।
এই তিনটি শুধু-পড়ার কমান্ড প্রশ্নটির উত্তর দেয় এবং টুলের সংস্করণ লিখে রাখে।
openssl version
openssl x509 -in vpn-client.crt -noout -text
openssl pkey -in vpn-client.key -noout -textসংস্করণ গুরুত্বপূর্ণ, কারণ অপশনের নাম বড় সংস্করণের মধ্যে সরে গেছে। সার্টিফিকেটের আউটপুটে পাবলিক কী অ্যালগরিদমের লাইন ও কী-র আকার খুঁজুন; কী-র আউটপুটে একটি RSA কী মডুলাস ও একটি পাবলিক সূচক ছাপে। উপবৃত্তীয় বক্ররেখার কী বদলে একটি নামকরা বক্ররেখা ছাপে, আর কোনও খোঁজই তা থেকে n বা q বের করবে না।
base64-এর বদলে কাঠামোটি পড়ুন
PEM হলো হেডার লাইনে মোড়া base64, আর তা ডিকোড করলে DER পাওয়া যায়, যা একটি বিশাল পূর্ণসংখ্যা নয় বরং ক্রমিক কাঠামো। RSA প্রাইভেট কী দুটি প্রচলিত কনটেইনারে আসে, PKCS#1 ও PKCS#8, এবং দুটোই একই সংখ্যাসমূহে পৌঁছায়।
দুটি মৌলিক সংখ্যার ক্ষেত্রে প্রাইভেট কাঠামোতে নয়টি ক্ষেত্র থাকে: একটি সংস্করণ, মডুলাস n, পাবলিক সূচক e, প্রাইভেট সূচক d, মৌলিক সংখ্যা p ও q, দুটি CRT সূচক এবং একটি CRT সহগ। RFC 8017-এর A.1 বিভাগ সেই উপাদানগুলো ও ASN.1 বিন্যাস সংজ্ঞায়িত করে, আর এটি দুটির বেশি মৌলিক সংখ্যাও অনুমোদন করে, তাই একটি সাধারণ পার্সার অতিরিক্ত মৌলিক এন্ট্রি ছাপতে পারে। ক্রমটি খেয়াল করুন, কারণ এটি একটি সাধারণ ভুল ব্যাখ্যা করে: পাবলিক অর্ধেক প্রাইভেট ফাইলের ভিতরে সংরক্ষিত থাকে, তাই একটি পাবলিক ক্ষেত্রের উপস্থিতি সেই ফাইলকে শেয়ার করার যোগ্য করে না। এর পরে যা কিছু আছে তা হলো সেই উপাদান যা হোস্টে থাকতেই হবে।
এনকোডিং এমন একটি স্তর যোগ করে যা সহজেই বিষয়বস্তুর সঙ্গে গুলিয়ে ফেলা যায়। openssl asn1parse কাঠামোটিকে গাছের মতো আঁকে যাতে ক্ষেত্রের ক্রম দৃশ্যমান হয়, আর এটি কিছুই ডিক্রিপ্ট করে না এবং কীটি ব্যবহারযোগ্য কি না তাও বলে না।
কী ছাপ না করেই সার্টিফিকেটের সঙ্গে কী মিলান
এর পরে যে প্রশ্নটি আসে তা সাধারণত এই: সার্টিফিকেট ও কী একসঙ্গে আছে কি না। মডুলাস তুলনা করলে উত্তর পাওয়া যায়, কিন্তু তাতে প্রাইভেট-সংশ্লিষ্ট উপাদানও একটি টার্মিনাল প্রতিলিপিতে চলে যায় যা পরে টিকিটে ঢুকে পড়তে পারে। পাবলিক অর্ধেক তুলনা করলে একই প্রশ্নের উত্তর মেলে, পর্দায় সংবেদনশীল কিছু না রেখেই।
openssl pkey -in vpn-client.key -pubout -out /tmp/key.pub
openssl x509 -in vpn-client.crt -pubkey -noout > /tmp/cert.pub
cmp /tmp/key.pub /tmp/cert.pub && echo MATCHএকই রকম ফাইল মানে সার্টিফিকেটটি সেই কী-র পাবলিক অর্ধেক বহন করে, আর পার্থক্য মানে আপনি ভুল জোড়া হাতে ধরে আছেন। এই অমিলই হলো এমন টানেলের সবচেয়ে সাধারণ কারণ যা আনন্দে দরকষাকষি করে তারপর প্রমাণীকরণে রাজি হয় না। পরে দুটি অস্থায়ী ফাইল মুছে ফেলুন; তাদের মধ্যে গোপন কিছু নেই, তবে পরিষ্কার কাজের ডিরেক্টরি ঘটনার মাঝপথে ভাবনা সহজ করে।
পাশের ফাইলগুলো কী নয় তা জানুন
একটি সার্টিফিকেট এমন এনক্রিপ্ট করা পাবলিক কী নয় যা প্রতিপক্ষ CA সার্টিফিকেট দিয়ে খোলে; এটি পাবলিক কী ও পরিচয়ের তথ্যের মধ্যে একটি স্বাক্ষরিত বন্ধন। CA-র প্রাইভেট স্বাক্ষরক কী তার নিজের সার্টিফিকেট থেকে এবং প্রতিটি ক্লায়েন্ট কী থেকে আলাদা থাকে। একটি অনুরোধও সার্টিফিকেট নয়: এটি চাওয়া তথ্য ও পাবলিক কী বহন করে এবং অনুরোধের উপর একটি স্বাক্ষর থাকে, যা এটিকে নথিভুক্তির ইনপুট করে তোলে, অধিকারের প্রমাণ নয়।
| File | Answers | Does not prove |
|---|---|---|
| vpn-client.key | Possession of the private key | That the identity is enrolled |
| vpn-client.crt | A signed binding of public key to identity | That the client holds the matching key |
| vpn-client.csr | The requested binding and public key | That access was granted |
| dh2048.pem | Group parameters for key exchange | Any RSA component |
| crl.pem | Revocation status for certificates | Anything about a private key |
এই এন্ট্রিগুলোর দুটিকে RSA প্যারামিটারের সঙ্গে এতটাই গুলিয়ে ফেলা হয় যে দুবার নাম বলতে হয়। একটি Diffie-Hellman প্যারামিটার ফাইলে কী প্রতিষ্ঠার জন্য গ্রুপ প্যারামিটার থাকে এবং কোনও RSA মৌলিক সংখ্যা থাকে না, যদিও সেটিও একটি বড় মৌলিক সংখ্যা হিসেবে ছাপা হয়। একটি বাতিলকরণ তালিকা সার্টিফিকেটের অবস্থা প্রকাশ করে এবং প্রাইভেট সূচক লুকাতে পারে এমন জায়গা নয়।
তাই প্রতিটি তালিকা সারিতে চারটি জিনিস লিখতে হবে: বস্তুর ধরন, মালিক, উদ্দেশ্য এবং প্রাইভেট উপাদান অন্তর্ভুক্ত কি না। শেষ কলামটিই ঠিক করে ফাইলটি কোথায় কপি করা যাবে, আর মানুষ ঠিক ওটাই বাদ দেয়।
জোড়াটি লিখে রাখুন, তারপর হ্যান্ডশেক যাচাই করুন
কিছু বদলানোর আগে তারিখ ও OpenSSL সংস্করণসহ যাচাইয়ের আউটপুট সংরক্ষণ করুন। তখন পরের রোটেশনটি স্মৃতির বদলে প্রমাণের সঙ্গে মিলিয়ে দেখা যাবে।
openssl verify -CAfile ca.crt vpn-client.crt
openssl x509 -in vpn-client.crt -noout -subject -issuer -datesপাবলিক কী তুলনার পরে জোড়াটি ব্যবহার করে এমন পথটি চালান: টানেল তোলেন, সার্টিফিকেট উপস্থাপিত ও গৃহীত হয়েছে নিশ্চিত করুন, এবং গেটওয়ে কোন পরিচয় লিখেছে তা দেখুন। যদি কী ও সার্টিফিকেট মেলে এবং প্রমাণীকরণ তবুও ব্যর্থ হয়, তবে ত্রুটি জোড়ায় নয়, বিশ্বাস, পরিচয় ম্যাপিং বা প্রবেশাধিকার নীতিতে।
ফিরিয়ে আনার জন্য আগের কী ও সার্টিফিকেট তারিখযুক্ত ডিরেক্টরিতে রাখুন এবং দুটিই একসঙ্গে পুনরুদ্ধার করুন, কখনো একটিকে নয়। সার্টিফিকেট ছাড়া কী আর কী ছাড়া সার্টিফিকেট বাইরে থেকে একইভাবে ব্যর্থ হয়, যা আধা-পুনরুদ্ধার করা জোড়া রাত দুটোয় খুলতে ব্যয়বহুল করে তোলে।