پرانی P12 فائل OpenSSL 3 پر ناکام: غلط پاس ورڈ یا پرانا سائفرفیر؟
غلط ٹائپ کی گئی پاس فریز کو اس پرانے RC2 بنڈل سے الگ کریں جسے OpenSSL 3 کھولنے سے انکار کرتا ہے، پھر فائل کو کلید کی حفاظت ہٹائے بغیر دوبارہ سیل کریں۔
درآمد کا ڈائیلاگ آپ کا پاس ورڈ لیتا ہے، لمحہ بھر گھومتا ہے اور پھر کہتا ہے کہ بنڈل نہیں پڑھ سکتا۔ اس پیغام میں کچھ نہیں بتایا جاتا کہ آپ نے پاس فریز غلط ٹائپ کی یا فائل ایسے سائفرفیر سے سیل ہے جو کلائنٹ اب فراہم نہیں کرتا۔ یہ مختلف ناکامیاں اور مختلف اصلاحات ہیں، غلط انتخاب کلائنٹ کی ڈاؤن گریڈ کی طرف لے جاتا ہے جو صرف فیصلہ ٹالتا ہے۔ کلائنٹ کس مرحلے پر رکتا ہے یہ دیکھنا انہیں تقریباً ایک منٹ میں الگ کر دیتا ہے۔
ڈائیلاگ اور سرٹیفکیٹ فہرست کے درمیان کیا ہوتا ہے
.p12 فائل ایک کنٹینر ہے، سرٹیفکیٹ نہیں۔ اس کے اندر ایک یا زیادہ سرٹیفکیٹ تھیلے اور آپ کے پاس ورڈ سے اخذ کردہ کلید سے خفیہ کردہ نجی کلید کا تھیلا ہے، نیز پوری فائل پر MAC کہلانے والی سالمیت کی جانچ۔ اسے کھولنے کا مطلب وہ MAC جانچنا، کلید کے تھیلے کو ڈکرپٹ کرنا اور سرٹیفکیٹ کو باہر آنے والی کلید سے ملانا ہے۔
پاس ورڈ کی دشواری MAC کے مرحلے پر آتی ہے۔ سائفرفیر کی دشواری بعد میں آتی ہے، جب کلید کا تھیلا کھولنا پڑتا ہے اور کھولنے والی بلڈ میں فائل میں لکھے الگورتھم کا نفاذ نہیں ہوتا۔
دوسری صورت آج کے نظاموں پر عام ہے کیونکہ OpenSSL 3 نے پرانے الگورتھم کا ایک گروہ اختیاری legacy provider میں منتقل کیا۔ 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 provider کو صرف اسی ایک عمل کے لیے لوڈ کرتا ہے۔ یہ 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 حوالہ یہاں استعمال شدہ provider، پاس فریز اور آؤٹ پٹ اختیارات کی فہرست دیتا ہے۔ legacy provider کو کلائنٹ ماحول سے باہر رکھنا ہی اصل بات ہے: اس کے ساتھ پیمائش کریں، اس کے بغیر بھیجیں اور نجی کلید کو ڈسک پر محفوظ رہنے دیں۔