remote-cert-tls server: OpenVPN پروفائل میں یہ کیا جانچتا ہے
یہ ہدایت ہم منصب کے سرٹیفکیٹ میں درج کردار کی جانچ کرتی ہے، اس کے نام کی نہیں۔ کچھ بھی بند کرنے سے پہلے کردار، اعتماد کی بنیاد اور میزبان نام کی جانچ کا موازنہ کریں۔
OpenVPN پروفائل کے تین مختلف حصے تین مختلف سوالات کے جواب دیتے ہیں، اور انہیں آپس میں ملانا ہی وہ وجہ ہے جس سے لوگ کام کرنے والی جانچ بند کر دیتے ہیں۔ کیا ہم منصب کا سرٹیفکیٹ اسی اتھارٹی نے دستخط کیا ہے جس پر میں بھروسہ کرتا ہوں؟ کیا وہ سرٹیفکیٹ TLS سرور کا کردار ظاہر کرتا ہے؟ کیا یہ وہی مخصوص سرور ہے جس تک میں پہنچنا چاہتا تھا؟ remote-cert-tls server صرف درمیانے سوال کا جواب دیتا ہے، اور یہ سرٹیفکیٹ کے اندر موجود ایکسٹینشنز پڑھ کر کرتا ہے۔
تین جانچیں جنہیں ذہن میں ملانا آسان ہے
اعتماد کی بنیاد ca ہدایت میں ہے۔ کردار کی جانچ remote-cert-tls سے تعلق رکھتی ہے۔ شناخت کی جانچ verify-x509-name سے تعلق رکھتی ہے، جب کوئی پروفائل اسے استعمال کرتا ہے، یا پھر کسی بھی نام کی جانچ سے جو تعیناتی شامل کرتی ہے۔
یہ مختلف ناکامیوں کا احاطہ کرتی ہیں:
| Question | Directive | Failure it catches |
|---|---|---|
| Who signed this? | ca | Certificate from an unrelated authority |
| Is this a server? | remote-cert-tls | Client certificate presented by a peer |
| Is this my server? | verify-x509-name | Another valid server from the same CA |
کسی پروفائل میں تینوں موجود ہو سکتے ہیں اور پھر بھی وہ کمزور ہو سکتا ہے اگر CA بہت زیادہ وسیع پیمانے پر مشترک ہو، جو کہ کلید کے انتظام کا سوال ہے نہ کہ ہدایت کا۔
کردار کی جانچ کیا پڑھتی ہے
یہ ہدایت ایک میکرو ہے۔ یہ کلید کے استعمال کی ایک شرط اور توسیع شدہ کلید کے استعمال کی ایک شرط میں پھیلتی ہے جو TLS Web Server کے کردار کا نام لیتی ہے، لہٰذا ہم منصب کے سرٹیفکیٹ کو واقعی وہ مقصد ظاہر کرنا ہوگا۔ کلائنٹ کی توثیق کے لیے جاری کیا گیا سرٹیفکیٹ اسے پورا نہیں کرتا، چاہے دونوں پر ایک ہی اتھارٹی نے دستخط کیے ہوں۔
یہ اہم ہے کیونکہ چھوٹی تعیناتیوں میں مشترکہ CA عام ہے۔ ایک ہی اتھارٹی ہر کلائنٹ اور سرور پر دستخط کرتی ہے، اور کردار کی جانچ کے بغیر ان سرٹیفکیٹوں میں سے کوئی بھی ہینڈ شیک کا سرور والا حصہ مکمل کر سکتا ہے۔ یہ جانچ اس منظرنامے کو ناممکن نہیں بناتی، لیکن اس کا آسان ورژن ختم کر دیتی ہے۔
یہ ہدایت بناوٹ کے اعتبار سے غیر متناسب ہے: کلائنٹس remote-cert-tls server رکھتے ہیں، اور سرورز remote-cert-tls client رکھتے ہیں۔ انہیں بدل دیں تو ہر کنکشن کردار کی ایسی خرابی کے ساتھ ناکام ہوگا جو ٹوٹے ہوئے سرٹیفکیٹ جیسی لگتی ہے۔
پرانا پروفائل کبھی کبھی اسی مقصد کے لیے ns-cert-type استعمال کرتا ہے۔ موجودہ مینوئل صفحات اس آپشن کو متروک سمجھتے ہیں، لہٰذا جو پروفائل اب بھی اس پر انحصار کرتا ہے اسے ڈیبگ کرنے کے بجائے منتقل کرنا بہتر ہے۔
اسے بند کرنا کیوں اصلاح جیسا لگتا ہے
جب کردار کی جانچ ناکام ہوتی ہے تو کنکشن تصدیق کی خرابی کے ساتھ رک جاتا ہے اور ظاہر قدم اس لائن کو حذف کرنا ہوتا ہے۔ پھر کنکشن قائم ہو جاتا ہے، جو ترقی جیسا لگتا ہے اور دراصل وہی ناکامی ہے جسے روکنے کے لیے یہ ہدایت موجود ہے۔ اب آپ ایسے ہم منصب کو قبول کرتے ہیں جس کا سرٹیفکیٹ کبھی اس کردار کے لیے بنایا ہی نہیں گیا تھا۔
اس کے بجائے خرابی پڑھیں۔ یہ بتاتی ہے کہ کون سی جانچ ناکام ہوئی، اور دوسری طرف کا سرٹیفکیٹ دیکھا جا سکتا ہے کہ اس میں واقعی کون سی ایکسٹینشنز ہیں۔ دو منٹ کا مطالعہ طے کر دیتا ہے کہ قصور جاری کرنے میں ہے یا ترتیب میں۔ اندازہ لگانا آدھا دن لے جاتا ہے اور عموماً کمزور پروفائل پر ختم ہوتا ہے۔ تجدید شدہ سرور سرٹیفکیٹ جو توسیع شدہ کلید کا استعمال کھو دے، تجدید میں ایک حقیقی قصور ہے، نہ کہ کلائنٹ کو ڈھیلا کرنے کی وجہ۔
نام کی جانچ ایک الگ ہدایت ہے
کردار کی جانچ پوری کرنا یہ بتاتا ہے کہ ہم منصب آپ کی اتھارٹی سے دستخط شدہ کوئی سرور ہے۔ یہ یہ نہیں بتاتا کہ کون سا، جو اہم ہے جب وہی CA کئی گیٹ ویز کے لیے سرٹیفکیٹ جاری کرتی ہے اور ان میں سے ایک متاثر یا دوبارہ مقرر ہو جاتا ہے۔
verify-x509-name سرٹیفکیٹ کے سبجیکٹ کا موازنہ آپ کی ترتیب کردہ قدر سے کرتا ہے، جس میں بالکل سبجیکٹ، سابقہ یا کسی ایک فیلڈ کے لیے موازنے کے طریقے ہیں۔ وہ فیلڈ استعمال کریں جو واقعی گیٹ وے کی شناخت کرتا ہے، اور توقع رکھیں کہ نام بدلنے پر اسے سوچے سمجھے طریقے سے اپ ڈیٹ کرنا ہوگا۔
کوئی بھی ہدایت کلید کے اچھے انتظام کی جگہ نہیں لیتی۔ اگر کلائنٹ کی کلید کی فائل پروفائل کے ساتھ ادھر ادھر کاپی کی جاتی ہے تو ہم منصب کی شناخت اتنی ہی مضبوط ہے جتنی تقسیم کی فہرست۔
پروفائل میں ترمیم کرنے سے پہلے سرٹیفکیٹ کا معائنہ کریں
ہم منصب کا سرٹیفکیٹ اور کلائنٹ کا لاگ اسی ترتیب سے پڑھیں۔ سرٹیفکیٹ بتاتا ہے کہ وہ کون سے کردار ظاہر کرتا ہے؛ لاگ بتاتا ہے کہ کس جانچ نے اسے مسترد کیا۔
یہ کمانڈز تفصیلی کنکشن سے استعمال کی ایکسٹینشنز اور تصدیق کی سطریں چھاپتی ہیں:
openssl x509 -in server.crt -noout -text | grep -A1 -E "Key Usage|Extended Key Usage"
sudo openvpn --config client.ovpn --verb 4 2>&1 | grep -i verifyاگر ایکسٹینشنز سرور کا کردار دکھاتی ہیں اور لاگ پھر بھی کردار کی ناکامی رپورٹ کرتا ہے تو پروفائل غالباً خراب سرٹیفکیٹ کے بجائے غلط سرٹیفکیٹ فائل کی طرف اشارہ کر رہا ہے۔ اگر ایکسٹینشنز صرف کلائنٹ کی توثیق دکھاتی ہیں تو کلائنٹ کو دیکھنا چھوڑ دیں اور جاری کرنے کا عمل ٹھیک کریں۔ بہرحال، کنکشن کو صحت مند کہنے سے پہلے جانچ بحال کریں، کیونکہ تصدیق ہٹانے کے بعد کامیاب ہینڈ شیک اس خرابی سے کم ثابت کرتا ہے جس کی اس نے جگہ لی۔