سپورٹ ٹکٹ پوچھتا ہے کہ VPN بنڈل کے اندر کون سا سرٹیفکیٹ ہے، اور پہلا جذبہ یہ ہوتا ہے کہ سب کچھ برآمد کر کے منسلک کر دیا جائے۔ P12 فائل سرٹیفکیٹس اور نجی کلید کا مواد ایک ہی کنٹینر میں پیک کرتی ہے، اس لیے سب کچھ برآمد کرنا بالکل وہی ہے جو آپ کو نہیں بھیجنا چاہیے۔ سوال کا جواب دینے والا حکم انتخاب کا مسئلہ ہے، تبدیلی کا نہیں۔ چار جھنڈے طے کرتے ہیں کہ کنٹینر کا کون سا نصف ملے گا، اور ان میں سے دو ایسے ہیں جو حقیقت سے زیادہ محفوظ لگتے ہیں۔

کنٹینر کو خالی کرنے کے بجائے اسے پڑھنے سے شروع کریں۔

PKCS12 فائل درحقیقت کیا رکھتی ہے

PKCS12 کنٹینر ایک یا زیادہ سرٹیفکیٹس، ممکنہ طور پر نجی کلید، اور مواد پر message authentication code رکھتا ہے۔ سرٹیفکیٹس میں آپ کی کلائنٹ شناخت کا پتا سرٹیفکیٹ اور وہ درمیانی سرٹیفکیٹس شامل ہو سکتے ہیں جو اسے CA سے زنجیر کرتے ہیں۔ کلید، جب موجود ہو، وہی چیز ہے جو فائل کو دستاویز کے بجائے راز بناتی ہے۔

یہی فرق -nokeys کے موجود ہونے اور یہ کہ یہی وہ جھنڈا ہے جس کی اس کام کو ضرورت ہے، کی وجہ ہے۔

بنڈل کو کلید لکھے بغیر پڑھیں

معائنہ کی صورت ساخت اور الگورتھم کی تفصیلات چھاپتی ہے اور کچھ نہیں لکھتی: openssl pkcs12 -in client.p12 -info -noout۔ یہ درآمد کا پاس ورڈ مانگتی ہے، جو اس قدر کے لیے درست جگہ ہے، اور بتاتی ہے کہ فائل میں کلید ہے یا نہیں۔ جب پاس ورڈ ٹائپ نہ ہو سکے تو -passin env:PKCS12_PASS استعمال کریں، کیونکہ shell حکم میں پاس ورڈ عملوں کی فہرست میں پاس ورڈ ہوتا ہے۔ یہ مرحلہ کچھ برآمد نہیں کرتا، اور یہی پوری بات ہے۔

آؤٹ پٹ کو تین چیزوں کے لیے پڑھیں: کتنے سرٹیفکیٹس، کلید موجود ہے یا نہیں، اور کون سے الگورتھم اسے بچاتے ہیں۔

-nokeys استعمال کریں اور اسے -nocerts سے نہ ملائیں

-nokeys نجی چابیاں خارج کرتا ہے اور سرٹیفکیٹس چھوڑ دیتا ہے۔ -clcerts اسے کلائنٹ سرٹیفکیٹس تک محدود کرتا ہے، -cacerts اسے CA سرٹیفکیٹس تک محدود کرتا ہے، اور یہ دونوں فلٹر ہیں متبادل نہیں۔ -nocerts اسی خیال کی محفوظ ہجے کی طرح پڑھا جاتا ہے اور الٹ مطلب رکھتا ہے: کوئی سرٹیفکیٹ نہیں، جو صرف چابیاں چھوڑتا ہے۔ اسے سرٹیفکیٹ برآمد میں ملانا وہ طریقہ ہے جس سے نجی کلید ڈسک پر پہنچتی ہے۔

دو سطروں والی صورت جو سرٹیفکیٹ فائل اور CA فائل بناتی ہے، اور اس کے سوا کچھ نہیں، یہ ہے:

openssl pkcs12 -in client.p12 -nokeys -clcerts -out client-certificates.pem
openssl pkcs12 -in client.p12 -nokeys -cacerts -out ca-certificates.pem

پرانی بنڈلوں کو OpenSSL 3 پر -legacy درکار ہے تاکہ اپنی پرانی انکرپشن پڑھ سکیں، اور یہ جھنڈا بدلتا ہے کہ parser کیا قبول کرتا ہے، نہ کہ وہ کیا خارج کرتا ہے۔ اگر تجزیہ غیر تعاون یافتہ الگورتھم کی خرابی سے ناکام ہو، تو -legacy شامل کرنا درست پہلا قدم ہے اور MAC جانچ چھوڑنا نہیں۔

آؤٹ پٹ چیک کریں، ایگزٹ کوڈ نہیں

صفر ایگزٹ حیثیت کہتی ہے کہ حکم چلا، نہ کہ فائل میں وہ ہے جو آپ توقع کرتے ہیں۔ آؤٹ پٹ میں سرٹیفکیٹس گنیں اور subject اور تاریخیں پڑھیں: openssl x509 -in client-certificates.pem -noout -subject -dates -fingerprint۔ فنگر پرنٹ کا موازنہ اس سے کریں جس کی سپورٹ ٹیم توقع کرتی ہے، کیونکہ دو کلائنٹ سرٹیفکیٹس والا بنڈل دو بلاک والی فائل بناتا ہے اور زیادہ تر اوزار صرف پہلا پڑھتے ہیں۔ مقصد، اعتماد اور کلید کی مطابقت پھر الگ امتحان ہیں۔

جو سرٹیفکیٹ تجزیہ ہو سکتا ہے وہ سرٹیفکیٹ تجزیہ ہو سکتا ہے۔ یہ وہ سرٹیفکیٹ نہیں جو VPN قبول کرتا ہے۔

فیصلہ کریں کہ آیا آپ کو فائلیں واقعی درکار ہیں

اگر وصول کرنے والا کلائنٹ PKCS12 براہ راست درآمد کرتا ہے، تو اصل بنڈل منظور شدہ چینل سے بھیجنا اور پاس ورڈ الگ رکھنا آسان ہے اور تحفظ برقرار رکھتا ہے۔ استخراج معائنے، PEM کی ضرورت والے کلائنٹ، یا ایسے سپورٹ کیس کے لیے ہے جس نے مخصوص artifact مانگا ہو۔ ہر استخراج ایک تہہ ہٹاتا ہے اور اس کی وجہ ہونی چاہیے۔

عوامی سرٹیفکیٹس میں نجی کلید نہیں ہوتی، لیکن ان میں نام اور تنظیم کی تفصیلات ہوتی ہیں۔ فائل کے بجائے وہ فیلڈز شیئر کریں جو ٹکٹ نے مانگے، الا یہ کہ فائل ہی مانگی گئی ہو۔

متعلقہ مضامین