OpenVPN میں کچھ بھی سرٹیفکیٹ کے Easy-RSA سے آنے کا تقاضا نہیں کرتا، اور جس فلیٹ کے پاس پہلے سے تنظیمی PKI ہے اسے عام طور پر دوسرا نہیں بنانا چاہیے۔ اصل کام کسی آلے کا انتخاب نہیں، بلکہ یہ طے کرنا ہے کہ جاری کردہ شناختیں کیا معنی رکھتی ہیں، ٹنل کن ہم منصبوں کو قبول کرتا ہے، اور تجدید و منسوخی تصدیق کنندہ تک کیسے پہنچتی ہیں۔ نیچے دیے گئے پانچ مراحل ترتیب سے مکمل کریں، کیونکہ بعد کا مرحلہ پہلے میں لیے گئے کردار کے فیصلے کو درست نہیں کر سکتا۔

ایک مشترکہ شناخت کے بجائے دو کردار جاری کریں

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

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

ہر طرف اعتماد کے ان پٹ جوڑیں

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

client
ca /etc/openvpn/pki/issuing-root.pem
cert /etc/openvpn/pki/device-17.crt
key /etc/openvpn/pki/device-17.key
remote-cert-tls server
verify-x509-name vpn.corp.example name
crl-verify /etc/openvpn/pki/issuing.crl

سرور کی طرف remote-cert-tls client اور اپنے سرٹیفکیٹ کے ساتھ اس کی عکاسی کرتی ہے، اور یہی کلائنٹ سرٹیفکیٹ کو سرور کے طور پر قبول ہونے سے روکتا ہے۔ نام کی جانچ کردار کی جانچ سے الگ فیصلہ ہے۔ براؤزر طرز کے میزبان نام کے میلان کو فرض کرنے کے بجائے یہ دیکھنے کے لیے کہ کون سا فیلڈ موازنہ ہوتا ہے، تعینات ترتیب پڑھیں۔ دونوں فریقوں کو یہ بھی واضح کرنا چاہیے کہ وہ کس جاری کنندہ پر بھروسا کرتے ہیں، کیونکہ پوری فلیٹ میں مشترکہ فائل راستہ مشترکہ پالیسی کے برابر نہیں ہے۔

اعتماد کو وسیع کیے بغیر درمیانی سرٹیفکیٹ پہنچائیں

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

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

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

فیصلہ کریں کہ منسوخی واقعی کیسے آتی ہے

crl-verify تصدیق کنندہ کو فائل یا اینڈ پوائنٹ سے مشورہ کرنے پر مجبور کرتا ہے، اور اس ترتیب کو مالک اور تازہ کاری کا راستہ درکار ہے۔ تعیناتی کے دوران ایک بار نقل کی گئی فہرست پہلی بار سرٹیفکیٹ منسوخ ہونے پر خاموشی سے آپ کی حفاظت کرنا چھوڑ دیتی ہے۔

متوقع پھیلاؤ کا وقت لکھیں اور اسے ایسے سرٹیفکیٹ سے جانچیں جسے منسوخ کرنے کے لیے آپ تیار ہیں۔ اگر VPN میزبان پر فہرست تازہ نہیں ہو سکتی، تو متبادل مختصر مدتِ اعتبار اور واقعی چلنے والا تجدید عمل ہے، URL موجود ہونے سے منسوخی کام کرتی ہے یہ مفروضہ نہیں۔

اصلی کلائنٹ سے قبولیت ثابت کریں

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

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

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