تبدیل کرنے سے پہلے: SSH کلید بمقابلہ OpenVPN سرٹیفکیٹ

درآمد سرٹیفکیٹ کی خرابی کے ساتھ ناکام ہوتی ہے، اس لیے ظاہر قدم تبدیلی جیسا لگتا ہے۔ یہ رجحان لوگوں کو ایسے راستے پر لے جاتا ہے جہاں فائل کی توسیع بدلتی ہے مگر انکار بالکل ویسا ہی رہتا ہے۔ authorized_keys میں ssh-ed25519 سطر اور OpenVPN کلائنٹ سرٹیفکیٹ الگ الگ اسناد کی اشیاء ہیں، جن کے جاری کنندگان، انکوڈنگ اور منسوخی کے راستے مختلف ہیں۔ ان جانچوں کو ترتیب سے کرنے سے ایک منٹ میں معلوم ہو جاتا ہے کہ تبدیلی سے کوئی مدد ہو سکتی ہے یا نہیں۔

آپ کے پاس اصل میں کون سی چیز ہے؟

لوگ پانچ چیزوں کو کلید کہتے ہیں، اور ان میں سے صرف ایک ہی وہ ہے جو TLS پروفائل چاہتا ہے۔ SSH عوامی کلید ایک ہی سطر کا متن ہے جس میں قسم کا سابقہ اور base64 پے لوڈ ہے۔ OpenSSH سرٹیفکیٹ وہ کلید نیز دستخط، principals اور اختیارات ہے، جسے ssh-keygen اپنی چھوٹی CA کی طرح کام کر کے بناتا ہے۔ X.509 سرٹیفکیٹ بالکل مختلف ساخت ہے، جو موضوع، مدتِ اعتبار، توسیعات اور سرٹیفکیٹ اتھارٹی کا دستخط رکھتا ہے۔ نجی کلید خفیہ نصف ہے، اور جاری کردہ بنڈل عام طور پر ایک ہی فائل میں سرٹیفکیٹ، اس کی زنجیر اور نجی کلید ہوتا ہے۔

پہلی جانچ میں صرف ایک حکم لگتا ہے۔ openssl کو فائل کی طرف اشارہ کریں اور سرٹیفکیٹ کی ساخت تجزیہ کرنے کو کہیں:

openssl x509 -in client.crt -noout -subject -issuer

اگر وہ unable-to-load یا PEM خرابی کے ساتھ ناکام ہو، تو فائل کو آپ نے جو بھی نام دیا ہو، وہ X.509 سرٹیفکیٹ نہیں ہے۔ نام بدلنے سے اندر کا ASN.1 دوبارہ نہیں لکھا جاتا، اور عوامی کلید کی سطر کو PEM ہیڈر متن میں لپیٹنے سے بھی نہیں۔

کیا پروفائل سرٹیفکیٹ مانگتا ہی ہے؟

کلائنٹ سرٹیفکیٹ کئی توثیق کے طریقوں میں سے ایک ہیں، اور بہت سے کارآمد TLS پروفائل کبھی ایک بھی نہیں مانگتے۔ سرور صارفین کی توثیق پلگ ان، صارف نام اور پاس ورڈ، یا ٹوکن بیک اینڈ سے کر سکتا ہے، پھر بھی کلائنٹ سے سرور کی شناخت کی تصدیق کا مطالبہ کرتا ہے۔ اگر پروفائل میں کلائنٹ سرٹیفکیٹ کی ہدایت نہ ہو، تو کبھی کوئی سرٹیفکیٹ نہیں مانگا جائے گا، اور کوئی تبدیلی گیٹ وے کو ایک مانگنے پر مجبور نہیں کرے گی۔

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

دوبارہ انکوڈنگ کیا کر سکتی ہے اور کیا نہیں

نجی کلیدوں کے واقعی جائز متبادل کنٹینر ہوتے ہیں۔ وہی RSA یا EC کلید روایتی PEM، PKCS#8، یا PKCS#12 بنڈل کے اندر لکھی جا سکتی ہے، اور اوزار خوشی سے ان کے درمیان تبدیلی کرتے ہیں۔ عوامی کلیدوں کی بھی ایسی ہی کہانی ہے: ssh-keygen SSH کلید کی RFC 4716 شکل نکال سکتا ہے، اور OpenSSH اپنی سرٹیفکیٹ شکل بھی سمجھتا ہے۔ یہ سب نمائندگی ہے، اور نمائندگی اعتماد نہیں۔

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

یہی وہ مرحلہ ہے جہاں زیادہ تر کوششیں خاموشی سے ناکام ہوتی ہیں: فائل اب .crt پر ختم ہوتی ہے، کلائنٹ اسے بغیر شکایت پڑھتا ہے، اور مصافحہ پھر بھی ٹوٹ جاتا ہے کیونکہ سامنے والا فریق قابلِ اعتماد جاری کنندہ تک زنجیر نہیں بنا سکتا۔

سرٹیفکیٹ اتھارٹی تصویر میں کہاں آتی ہے

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

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

SSH کلید دوبارہ استعمال کرنے کی قیمت

فرض کریں کہ کسی تبدیلی نے واقعی کچھ قابلِ قبول بنایا۔ ایک ہی کلید جوڑی SSH رسائی اور VPN توثیق کے لیے دوبارہ استعمال کرنا پھر بھی دو خودمختار سلامتی فیصلوں کو جوڑ دیتا ہے۔ authorized_keys سے ایک سطر ہٹانے سے SSH لاگ ان رک جاتے ہیں، اور اسی عوامی کلید کے لیے VPN CA نے پہلے ہی جو سرٹیفکیٹ جاری کیا ہے اسے کچھ نہیں ہوتا۔ VPN طرف اپنے ہی طریقے سے منسوخ ہوتی ہے، یعنی سرٹیفکیٹ منسوخی کی فہرست یا آپریٹر کا رجسٹریشن ریکارڈ۔

چنانچہ چیک لسٹ کسی حیلے سے نہیں، رکنے کی شرط سے ختم ہوتی ہے۔ اگر openssl فائل کو سرٹیفکیٹ کے طور پر تجزیہ نہ کرے، تو تبدیلی روکیں اور بتائیں کہ آپ کے پاس کیا ہے: SSH کلید، SSH سرٹیفکیٹ، X.509 سرٹیفکیٹ، نجی کلید یا بنڈل۔ اگر پروفائل کلائنٹ سرٹیفکیٹ نہ مانگے، تو رکیں اور پوچھیں کہ سرور کون سا توثیق کا طریقہ توقع کرتا ہے۔ صرف اسی وقت جب دونوں جواب X.509 کی طرف اشارہ کریں رجسٹریشن اگلا قدم بنتی ہے، اور پہلے جملے میں درست اسم ہو تو وہ گفتگو کہیں زیادہ تیز ہوتی ہے۔