পুরোনো P12 OpenSSL 3-এ ব্যর্থ: ভুল পাসওয়ার্ড নাকি পুরোনো সাইফার?
ভুল করে লেখা পাসফ্রেজকে OpenSSL 3 যে পুরোনো RC2 বান্ডল খুলতে অস্বীকার করে তা থেকে আলাদা করুন, তারপর কী সুরক্ষা না সরিয়ে ফাইলটি আবার সিল করুন।
ইমপোর্ট ডায়ালগ আপনার পাসওয়ার্ড নেয়, এক মুহূর্ত ঘুরে বলে যে এটি বান্ডলটি পড়তে পারছে না। সেই বার্তায় কিছুই বলে না যে আপনি পাসফ্রেজ ভুল লিখেছেন, নাকি ফাইলটি এমন সাইফারে সিল করা যা ক্লায়েন্ট আর সরবরাহ করে না। এগুলো ভিন্ন ভিন্ন ব্যর্থতা, প্রতিটির সমাধানও ভিন্ন, আর ভুল বাছাই ক্লায়েন্টের সংস্করণ কমানোর দিকে নিয়ে যায় যা কেবল সিদ্ধান্ত পিছিয়ে দেয়। ক্লায়েন্ট কোন ধাপে থামে তা দেখলে প্রায় এক মিনিটেই এদের আলাদা করা যায়।
ডায়ালগ আর সার্টিফিকেট তালিকার মধ্যে কী ঘটে
.p12 ফাইল একটি ধারক, সার্টিফিকেট নয়। ভিতরে এক বা একাধিক সার্টিফিকেট ব্যাগ আর আপনার পাসওয়ার্ড থেকে উদ্ভূত কী দিয়ে এনক্রিপ্ট করা একটি প্রাইভেট-কী ব্যাগ থাকে, সাথে পুরো ফাইলের উপর MAC নামের একটি অখণ্ডতা যাচাই। এটি খোলার মানে সেই MAC যাচাই করা, কী ব্যাগ ডিক্রিপ্ট করা এবং বেরিয়ে আসা কী-এর সাথে সার্টিফিকেট মেলানো।
পাসওয়ার্ডের সমস্যা আসে MAC ধাপে। সাইফারের সমস্যা আসে পরে, যখন কী ব্যাগ খুলতে হয় আর যে বিল্ড এটি খোলে তার কাছে ফাইলে উল্লিখিত অ্যালগরিদমের কোনো বাস্তবায়ন থাকে না।
দ্বিতীয় ঘটনাটি বর্তমান সিস্টেমে সাধারণ, কারণ OpenSSL 3 পুরোনো অ্যালগরিদমের একটি দলকে ঐচ্ছিক legacy প্রোভাইডারে সরিয়ে দিয়েছে। OpenSSL 1.x দ্বারা রপ্তানি করা বান্ডল সাধারণত সার্টিফিকেটগুলো 40-বিট RC2 দিয়ে এবং প্রাইভেট কী তিন-কী Triple DES দিয়ে সিল করত। ডিফল্ট OpenSSL 3 বিল্ড এখনও আপনার সঠিক পাসওয়ার্ড দিয়ে MAC যাচাই করে, তারপর ব্যাগে ব্যর্থ হয়, তাই পাসওয়ার্ড কখনোই ভুল ছিল না এবং আবার টাইপ করলে কিছুই বদলায় না।
কী না লিখে ধারকটি পড়ুন
আপনার নিজের মেশিনের OpenSSL বিল্ডকে ফাইলটি পার্স করতে বলুন এবং দেখুন কোথায় এটি হাল ছাড়ে। কোনো আউটপুট ফাইল ছাড়া পরীক্ষা কী-টিকে ডিস্কে এনক্রিপ্টেড রেখে দেয়, আর এটাই একমাত্র কারণ যে এই ধাপটি শেয়ার করা হোস্টে চালানো নিরাপদ।
openssl pkcs12 -in vpn-identity.p12 -info -nooutসঠিক পাসওয়ার্ডসহ পুরোনো বান্ডলে এটি ব্যাগের বৈশিষ্ট্য ছাপে এবং তারপর digital envelope routines::unsupported নিয়ে থামে। ভুল পাসওয়ার্ডে কোনো ব্যাগ পড়ার আগেই আপনি Mac verify error: invalid password? পান। দুটি বার্তা বিপরীত দিকে ইঙ্গিত করে, আর ঠিক সেই তথ্যই ক্লায়েন্ট গোপন করেছিল।
যদি ব্যর্থতাটি অসমর্থিত-অ্যালগরিদমের হয়, একই কমান্ড আবার চালান, শুধু -legacy যোগ করে আর অন্য কিছু না বদলে। এই ফ্ল্যাগটি কেবল সেই একটি প্রসেসের জন্য legacy প্রোভাইডার লোড করে। এটি VPN ক্লায়েন্টকে পুরোনো বান্ডল পার্স করতে বাধ্য করে না, সিস্টেম-ব্যাপী ক্রিপ্টো নীতিতে হাত দেয় না, এবং এটি মেরামত নয় বরং পরিমাপ, কারণ ফাইলটি তবুও প্রতিস্থাপন করতে হবে।
কোন ত্রুটি কোন ধাপ বোঝায়
একটি সংক্ষিপ্ত সারণি তিনটি ফলাফলকে আলাদা রাখে, আর ডায়ালগ কোথায় দেখা গেল তার চেয়ে শব্দচয়ন বেশি জরুরি।
| Text you see | Stage | What it tells you |
|---|---|---|
Mac verify error: invalid password? | Integrity check | Passphrase or cached credential, not the cipher |
digital envelope routines::unsupported | Bag decrypt | Algorithm missing from the default provider |
not enough data / header too long | Container format | Wrong encoding, edited file, or truncated download |
not enough data বা header too long-এর মতো লেখা প্রথম দুই দলের কোনোটিতেই পড়ে না। এটি বিন্যাসের সমস্যা: .pem নাম দেওয়া একটি DER ফাইল, লাইন শেষাংশ পুনর্লিখনকারী এডিটর দ্বারা বিকৃত একটি অনুলিপি, বা অসম্পূর্ণ ডাউনলোড। সাইফার দেখার আগে ইস্যুকারীর পাঠানো চেকসামের সাথে মিলিয়ে নিন।
Mac verify error-কে কেবল পাসওয়ার্ড সম্পর্কিত প্রমাণ হিসেবে ধরুন। এর মানে আপনার লেখা থেকে গণনা করা MAC সংরক্ষিত মানের সাথে মেলে না, যা টাইপোতে, আগের ইমপোর্ট থেকে ক্যাশ করা পাসওয়ার্ডে, বা ভিন্ন পাসফ্রেজে পুনরায় রপ্তানি করা ফাইলে ঘটে। ভিতরের অ্যালগরিদম পুরোনো কি না সে সম্পর্কে এটি কিছু বলে না।
ক্লায়েন্ট সত্যিই খুলতে পারে এমন একটি বান্ডল তৈরি করুন
legacy পার্সার ফাইলটি সুস্থ বলে নিশ্চিত করলে, স্থায়ী সমাধান হলো এমন প্রতিস্থাপন যার অ্যালগরিদম লক্ষ্য ক্লায়েন্ট সমর্থন করে: কী ও সার্টিফিকেট ব্যাগের জন্য AES-256-CBC, উদ্ভবের জন্য SHA-256 সহ PBKDF2, এবং MAC-এর জন্য SHA-256। আপনার PKI প্রশাসক একই কী উপাদান থেকে এটি রপ্তানি করতে পারেন, আর ভিতরের সার্টিফিকেট আপনার সার্ভার যে ইতিমধ্যে বিশ্বাস করে সেটিই থাকে।
স্থানীয়ভাবে রূপান্তর করতে হলে pkcs12 টুলকে আগে ডাম্প না করে ব্যাগগুলো আবার সিল করতে বলুন। উভয় পাসফ্রেজ ফাইল থেকে পড়ে আপনার শেল ইতিহাসের বাইরে রাখুন।
openssl pkcs12 -in vpn-identity.p12 -out vpn-identity-aes.p12 \
-keypbe AES-256-CBC -certpbe AES-256-CBC -macalg sha256 \
-passin file:old.pass -passout file:new.passসফল রূপান্তর মেয়াদ, কী ব্যবহার, প্রাইভেট-কী মিল বা সার্ভার ইস্যুকারী চেইনকে বিশ্বাস করে কি না সে সম্পর্কে কিছুই বলে না। পুনঃপ্যাকেজিং একটি পরিবহন পরিবর্তন, নবায়ন নয়, আর এর প্রতিটির নিজস্ব যাচাই এখনও দরকার।
যেকোনো রেসিপি এড়িয়ে যান যা অরক্ষিত মধ্যবর্তী কী লেখে বা খালি আউটপুট পাসওয়ার্ড দেয়, শুধু এই কারণে যে ক্লায়েন্ট পরে ফাইলটি গ্রহণ করেছে। সুরক্ষা ছাড়া পড়ার যোগ্য বান্ডল আপনার শুরুর ইমপোর্ট ব্যর্থতার চেয়ে খারাপ ফল।
ক্লায়েন্ট আপনার তৈরি ফাইলটিই ইমপোর্ট করেছে তা নিশ্চিত করুন
টার্মিনালে পরিষ্কার পার্স প্রমাণ করে ধারকটি বৈধ। এটি প্রমাণ করে না যে ক্লায়েন্ট এটি বেছেছে, কারণ একটি অবশিষ্ট প্রোফাইল পুরোনো ফাইলের দিকেই নির্দেশ করতে পারে, আর কিছু ক্লায়েন্ট ইমপোর্ট করা পরিচয় আপনার না-বাছা নামে ক্যাশ করে।
আপনি যে পরিচয় ইমপোর্ট করতে যাচ্ছেন তা ছাপুন এবং ক্লায়েন্ট তার সার্টিফিকেট ভিউতে যা দেখায় তার সাথে মিলিয়ে দেখুন।
openssl pkcs12 -in vpn-identity-aes.p12 -clcerts -nokeys -passin file:new.pass \
| openssl x509 -noout -subject -dates -fingerprint -sha256আগে পুরোনো প্রোফাইল এন্ট্রিটি সরান, তারপর ইমপোর্ট করুন। ক্লায়েন্ট যদি যে সাবজেক্ট বা ফিঙ্গারপ্রিন্ট লোড করেছে তা লগ করে, উপরের লাইনের সাথে মেলান; যদি কেবল একটি বন্ধুত্বপূর্ণ নাম দেখায়, বরং মেয়াদ শেষের তারিখ দেখুন, কারণ একই ইস্যুকারীর অন্য সার্টিফিকেটের সাথে এটি গুলিয়ে ফেলা কঠিনতর।
PKCS12 রেফারেন্স এখানে ব্যবহৃত প্রোভাইডার, পাসফ্রেজ ও আউটপুট অপশনগুলো তালিকাভুক্ত করে। legacy প্রোভাইডারকে ক্লায়েন্ট পরিবেশের বাইরে রাখাই মূল কথা: এটি দিয়ে মাপুন, এটি ছাড়া পাঠান, আর প্রাইভেট কী ডিস্কে সুরক্ষিত রাখুন।