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 شامل کریں؛ یہی ایک جھنڈی زیادہ تر لوڈ نہ ہونے کی خرابیاں حل کر دیتی ہے۔
کلید کو سرٹیفکیٹ سے ملانا میکانی کام ہے، اور کسی بھی درآمد سے پہلے کرنے کے قابل ہے:
openssl x509 -in cert.pem -noout -pubkey | openssl sha256openssl pkey -in key.pem -pubout | openssl sha256
یکساں ڈائجسٹ کا مطلب ہے کہ یہ جوڑا ایک دوسرے کا ہے۔ مختلف ڈائجسٹ کا مطلب ہے کہ آپ کے پاس غلط کلید ہے، اور فارمیٹ کی کوئی تبدیلی اسے نہیں بدلے گی۔
جو فارمیٹ کبھی نہیں بدلتا
بھروسے کے فیصلے کنٹینر کے اوپر ہوتے ہیں۔ کلائنٹ زنجیر پر چل کر اپنے اسٹور کے روٹ تک جاتا ہے، اعتبار کی مدت جانچتا ہے، کلائنٹ توثیق کے لیے توسیع شدہ کلید کا استعمال جانچتا ہے، اور سرور کی طرف جانچتا ہے کہ جس نام پر ڈائل کیا وہ سرٹیفکیٹ میں موجود ہے۔ ان میں سے کوئی مرحلہ فائل کی ایکسٹینشن نہیں پڑھتا۔
اسی لیے فائل کا نام بدلتے رہنا جب تک خرابی غائب نہ ہو، وقت ضائع کرنے کا ایسا قابلِ بھروسا طریقہ ہے۔ درآمد کامیاب ہو جاتی ہے، شناخت پھر بھی غلط رہتی ہے، اور ناکامی ہینڈ شیک کے دوران دوبارہ ظاہر ہوتی ہے جہاں پیغام کم مددگار ہوتا ہے۔ یہی وجہ ہے کہ دو سال پہلے ایکسپورٹ شدہ بنڈل صاف درآمد ہوتا ہے اور پھر بھی مسترد ہو جاتا ہے: میعاد کی تاریخ فائل کے نام میں نہیں، سرٹیفکیٹ کے اندر سفر کرتی ہے۔
دوبارہ کام سے بچنے والا ترتیب
کلائنٹ کی دستاویزات سے پوچھیں کہ وہ کون سی انکوڈنگز قبول کرتا ہے اور کلائنٹ شناخت کے لیے کون سا کنٹینر چاہتا ہے، پھر دیکھیں کہ آپ کو کیا دیا گیا۔ اگر کلائنٹ ایک ہی درآمد کے قابل شناخت چاہتا ہے اور آپ کے پاس الگ PEM فائلیں ہیں، تو بنڈل ایک بار ایسے پاس ورڈ سے بنائیں جو آپ کے کنٹرول میں ہو اور ماخذ محفوظ رکھیں۔ اگر اسے PEM چاہیے، تو کلید اور زنجیر نکالیں، اور بعد میں درمیانی فائلیں اُس کریڈنشل سنبھالنے کے عمل سے ہٹا دیں جو آپ کی ٹیم پہلے سے استعمال کرتی ہے۔
درآمد کے بعد ڈائیلاگ کی نہیں، شناخت کی تصدیق کریں: سبجیکٹ، جاری کنندہ، میعاد، اور وہ نام جو کلائنٹ پیش کرے گا۔ فہرست میں دوستانہ نام ایک لیبل ہے، تصدیق شدہ شناخت نہیں۔ اگر سرنگ پھر ناکام ہو، تو آپ پیکجنگ کے بجائے توثیق یا روٹنگ ڈی بگ کر رہے ہیں، اور یہ بہت مختصر گفتگو ہے۔