آپ نے سرٹیفکیٹ انسٹال کیا، یہ Keychain Access میں آسان نام کے ساتھ دکھائی دیتا ہے، اور VPN کلائنٹ کا شناختی انتخاب اب بھی خالی ہے۔ کلائنٹ سرٹیفکیٹ نہیں ڈھونڈ رہا۔ وہ شناخت ڈھونڈ رہا ہے: نجی کلید کے ساتھ جڑا سرٹیفکیٹ جو ملکیت ثابت کر سکے، وہاں محفوظ جہاں کلائنٹ کو اسے پڑھنے کی اجازت ہے۔

کلائنٹ جو مانگتا ہے وہ شناخت ہے

Apple کا سیکیورٹی فریم ورک سرٹیفکیٹ اور شناخت کو الگ الگ اشیاء سمجھتا ہے۔ سرٹیفکیٹ عوامی ڈیٹا ہے۔ شناخت وہ سرٹیفکیٹ اور اس کی نجی کلید ہے، اور چیلنج مکمل کر سکتی ہے صرف شناخت۔ قابلِ اعتماد CA سرٹیفکیٹ، دوسری طرف، کلائنٹ کو جاری کنندہ کا جائزہ لینے دیتا ہے; یہ مشین کو جاری شدہ کلائنٹ اسناد کی حامل نہیں بناتا۔

ItemWhat it can doWhat it cannot do
CA or server certificateValidate the gateway's chainAuthenticate this client
Client certificate without keyNothing for authenticationProve possession of anything
Identity (cert plus key)Answer the authentication challengeGuarantee the gateway accepts it

اسی لیے .cer فائل درآمد کرنے سے کبھی قابلِ استعمال کلائنٹ شناخت نہیں بنتی۔ فائل میں صرف عوامی مواد ہوتا ہے۔ نام بدلنے یا اعتماد دینے سے یہ کلید جوڑی نہیں بنتی۔

انتخاب خالی رہنے کی تین وجوہات

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

security find-identity -v -p ssl-client

یہ ان شناختوں کی فہرست دیتا ہے جنہیں سسٹم کلائنٹ توثیق کے لیے درست مانتا ہے۔ اگر گنتی صفر ہو تو مسئلہ VPN کلائنٹ سے اوپر ہے اور پروفائل میں کوئی ترمیم اسے درست نہیں کرے گی۔ اگر شناخت یہاں نظر آئے مگر کلائنٹ میں نہیں، تو فرق کلائنٹ کے ذخیرے یا دائرے میں ہے۔

نجی کلید کہاں رہتی ہے، اور کون اسے استعمال کر سکتا ہے

جب آپ Keychain Access کے ذریعے شناخت درآمد کرتے ہیں، تو درآمد مکالمہ ہدف کیچین پیش کرتا ہے۔ کون سا ہدف درست ہے یہ کلائنٹ اور پروفائل کے صارف یا ڈیوائس دائرے پر منحصر ہے۔ سسٹم کیچین کی سفارش کرنے والا پرانا جواب عالمگیر قاعدہ نہیں، اور ذخیروں کے درمیان اشیاء کی نقل کرنا مرمت نہیں۔

System Roots اعتماد کا مجموعہ ہے۔ وہاں سرٹیفکیٹ رکھنے سے بدلتا ہے کہ سسٹم کن جاری کنندگان پر اعتماد کرتا ہے; یہ نجی کلید نہیں بناتا، اور یہ شناخت کا ذخیرہ نہیں ہے۔ انتخاب بھرنے کے لیے غیر متعلق سرٹیفکیٹ ہلانا ایسی مرمت ہے جو مشین کو مستقل طور پر وسیع اعتماد کے مجموعے کے ساتھ چھوڑ دیتی ہے۔

نجی کلید تک رسائی الگ کنٹرول ہے۔ ہر ایپلیکیشن کو کلید استعمال کرنے کی اجازت دینا ایک کلائنٹ کا انتخاب کا مسئلہ حل کرتا ہے اور وہی صلاحیت مشین پر باقی سب کو دیتا ہے۔ یہ اس کلائنٹ کو دیں جسے ضرورت ہے، اور دیکھیں کہ کلید ہارڈویئر سے معاون ہے یا ناقابلِ برآمد کے طور پر نشان زد ہے; اگر ایسا ہے تو برآمد شدہ نقل کے بجائے معاون فراہم کنندہ استعمال کرنا ہوگا۔

پروفائل اسناد کی طرف کیسے اشارہ کرتا ہے

زیرِ انتظام مقامی IKEv2 ترتیب میں، پروفائل PayloadCertificateUUID کے ذریعے اپنے اسناد کے پے لوڈ کا حوالہ دیتا ہے۔ اہم بات حوالہ شدہ شناخت اور اسے فراہم کرنے کا طریقہ ہے; پروفائل میں دکھایا جانے والا نام تبدیل کرنے سے غلط پے لوڈ یا ایسے پے لوڈ کا حوالہ درست نہیں ہوتا جس نے کبھی کلید فراہم نہیں کی۔

تیسری پارٹی کا فراہم کنندہ بالکل مختلف انتخاب کا طریقہ استعمال کر سکتا ہے، جیسے اپنا ذخیرہ یا سسٹم اشارہ۔ مقامی پروفائل کے مفروضے منتقل کرنے کے بجائے اس فراہم کنندہ کی دستاویزات پڑھیں، اور حوالے کی تصدیق اصل نصب شدہ پروفائل میں کریں، انتظامی کنسول کے مسودے میں نہیں۔

انتخاب اور قبولیت الگ سنگِ میل ہیں

بھرا ہوا انتخاب یعنی کلائنٹ شناخت ڈھونڈ اور استعمال کر سکتا ہے۔ یہ نہیں بتاتا کہ گیٹ وے اسے قبول کرے گا یا نہیں۔ سرور اب بھی جاری کنندہ، اعتبار کی مدت، منسوخی کی حالت اور اس اسناد کا اکاؤنٹ سے نقشہ بنانا۔

دونوں مراحل واضح طور پر، اسی ترتیب میں جانچیں۔ تصدیق کریں کہ شناخت پیش کی جاتی ہے، جڑیں، اور پھر گیٹ وے کے مالک سے کہیں کہ وہ تصدیق کرے کہ کون سی اسناد پیش ہوئیں اور کس نقشہ سازی کے قاعدے نے انہیں استعمال کیا۔ اگر کلائنٹ شناخت پیش کرے اور سرور اسے مسترد کرے، تو باقی کام سرور کی طرف ہے۔ Mac پر سرٹیفکیٹ دوبارہ انسٹال کرنے سے وہ نتیجہ نہیں بدلے گا، خواہ کتنی بار دہرایا جائے۔

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