VPN کلائنٹ کی کلید کیسے بنائیں اور دستخط کے لیے CSR کیسے جمع کریں

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

مرحلہ 1: کلید وہیں بنائیں جہاں وہ رہے گی

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

سافٹ ویئر بہاؤ ایسا دکھتا ہے، کلید اور درخواست ایک ہی نشست میں بنائی جاتی ہیں:

umask 077
openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:3072 -out client.key
openssl req -new -key client.key -out client.csr -subj "/CN=alice-vpn/O=Example"

umask سطر دکھنے سے زیادہ اہم ہے۔ اس کے بغیر کلید ڈیفالٹ طور پر اجازت دینے والے نظام پر سب کے پڑھنے کے قابل لکھی جاتی ہے، اور بعد میں فائل کی نقل کرنا اسے پھیلا دیتا ہے۔ موجودہ کلید کا دوبارہ استعمال جائز ہے جب وہ پہلے ہی محفوظ ہو اور آپ کی پالیسی سے مطابقت رکھتی ہو؛ ہر آلے کے لیے نئی بنانا سمجھانا آسان ہے۔

مرحلہ 2: شناخت درخواست میں رکھیں، ای میل میں نہیں

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

جب آپ کا تصدیق کنندہ ایک کی جانچ کرے تو موضوع کا متبادل نام شامل کریں، کیونکہ جدید مطابقت اکثر پرانے CN کو نظرانداز کرتی ہے:

openssl req -new -key client.key -out client.csr \
  -subj "/CN=alice-vpn/O=Example" \
  -addext "subjectAltName=DNS:alice-vpn"

CN کو مختصر، مستحکم اور لیپ ٹاپ ماڈل کے بجائے اکاؤنٹ سے بندھا رکھیں۔ جس نام میں صارف کے آلے کا سیریل نمبر ہو وہ پہلی ہارڈویئر تبدیلی کے انتظار میں مدد کا مسئلہ ہے۔

مرحلہ 3: دستخط سے پہلے درخواست کی تصدیق کریں

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

میکانی حصہ ایک حکم ہے، اور اسے موضوع کے ساتھ تصدیق کا نتیجہ چھاپنا چاہیے:

openssl req -in client.csr -noout -verify -subject
openssl req -in client.csr -noout -pubkey | openssl pkey -pubin -noout -text

غور کریں کہ یہ کیا ثابت کرتا ہے۔ تصدیق شدہ درخواست صرف یہ دکھاتی ہے کہ بھیجنے والے کے پاس جمع کرانے کے وقت متعلقہ نجی کلید تھی؛ یہ ثابت نہیں کرتی کہ بھیجنے والا موضوع میں نامزد شخص ہے، اور نہ مانگی گئی گروہ یا راستے کی رسائی کی اجازت دیتی ہے۔ اندراج کا جائزہ الگ دروازہ ہے، اور ایسی گروہ کی درخواست جسے کسی نے منظور نہیں کیا خاموشی سے ترمیم کرنے کے بجائے مسترد کرنی چاہیے۔

مرحلہ 4: اجازت دیں، پھر واضح توسیعات کے ساتھ دستخط کریں

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

cat > client.ext <<'EOF'
basicConstraints = CA:FALSE
keyUsage = digitalSignature
extendedKeyUsage = clientAuth
EOF
openssl x509 -req -in client.csr -CA ca.crt -CAkey ca.key \
  -CAcreateserial -days 365 -extfile client.ext -out client.crt

اگر پہلے سے ایک زیرِ استعمال ہو تو موجودہ سیریل فائل کے ساتھ -CAserial استعمال کریں، اور CA کلید آف لائن یا اسی محفوظ ذخیرے میں رکھیں جس کا نام آپ کی پالیسی لیتی ہے۔ سرٹیفکیٹ کے سیریل نمبر ہر جاری کنندہ کے لیے منفرد ہونے چاہئیں؛ سیریل فائل کو صفر سے دوبارہ بنانا ایسے تصادموں کا خطرہ ہے جو منسوخی کو مبہم بنا دیتے ہیں۔

درج کریں کہ کیا جاری ہوا: سیریل نمبر، موضوع، مطلوبہ شناخت، منظوری دینے والا شخص اور مدت۔ وہی ریکارڈ ہے جس پر بعد میں منسوخی کا فیصلہ انحصار کرتا ہے، اور اگر اندراج کا نشان صرف ایک میل باکس میں رہتا ہے تو اسے صرف سرٹیفکیٹ سے دوبارہ نہیں بنایا جا سکتا۔

مرحلہ 5: اسے متعلقہ کلید کے پاس نصب کریں اور جوڑی ثابت کریں

کلائنٹ سرٹیفکیٹ اور جاری کنندہ کا سلسلہ وصول کرتا ہے، کبھی کلید نہیں. جوڑنے سے پہلے تصدیق کریں کہ سرٹیفکیٹ ڈسک پر پہلے سے موجود کلید کے ساتھ واقعی جوڑی بناتا ہے، کیونکہ غیرمطابق جوڑی بہت بعد میں الجھا دینے والی ہینڈ شیک ناکامی پیدا کرتی ہے:

openssl x509 -in client.crt -noout -pubkey | openssl pkey -pubin -outform DER | openssl sha256
openssl pkey -in client.key -pubout -outform DER | openssl sha256

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