اپنے VPN کی جڑ CA کو آف لائن رکھیں اور پھر بھی سرٹیفکیٹ جاری کریں

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

ایک کنکشن دراصل کیا تصدیق کرتا ہے

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

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

جڑ کو ایسے ہوسٹ پر بنائیں جسے کبھی پتہ نہیں ملتا

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

openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 -out root.key
openssl req -x509 -new -key root.key -sha256 -days 7300 \
  -subj "/CN=Example VPN Root CA" -out root.crt \
  -addext "basicConstraints=critical,CA:TRUE" \
  -addext "keyUsage=critical,keyCertSign,cRLSign"

دستخط ہوسٹ پر درمیانی بنائیں اور صرف اس کی درخواست آف لائن مشین تک لے جائیں۔ جڑ اس درخواست پر صفر راستے کی لمبائی کے ساتھ دستخط کرتی ہے، اس لیے درمیانی CA آخری سرے کے سرٹیفکیٹ پر دستخط کر سکتا ہے لیکن اپنے نیچے دوسرا CA نہیں بنا سکتا۔ وہ ایک توسیع سمجھوتے میں آئے دستخط ہوسٹ کو جڑ کے برابر اختیار بنانے سے روکتی ہے۔ ECDSA صرف اس وقت استعمال کریں جب ہر کلائنٹ OpenVPN 2.4 یا نیا چلاتا ہو؛ ورنہ RSA چابیاں بنائیں اور بہاؤ ویسا ہی رکھیں۔

openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 -out intermediate.key
openssl req -new -key intermediate.key -subj "/CN=Example VPN Intermediate CA" -out intermediate.csr
openssl x509 -req -in intermediate.csr -CA root.crt -CAkey root.key \
  -CAcreateserial -days 3650 -sha256 -extfile intermediate.ext -out intermediate.crt

intermediate.ext میں basicConstraints=critical,CA:TRUE,pathlen:0، keyUsage=critical,keyCertSign,cRLSign اور authorityKeyIdentifier=keyid:always شامل ہیں۔ دستخط ہوسٹ کے دوبارہ جڑنے سے پہلے جڑ کی چابی اس کی تجوری میں واپس رکھیں۔ اگر جڑ کو درمیانی منسوخ کرنے کی صلاحیت درکار ہو تو اسے openssl x509 -req کی بجائے جڑ کی سطح کے index.txt کے خلاف openssl ca -config root.cnf -extensions intermediate_ca سے دستخط کریں، تاکہ سیریل نمبر درج ہو؛ پھر نتیجے میں آنے والی جڑ کی فہرست کلائنٹ پروفائل کے اندر بھیجیں، جہاں فائل پر مبنی crl-verify اسے آغاز پر پڑھتا ہے۔ کلائنٹس کو دونوں CA سرٹیفکیٹ والا بنڈل بھیجیں؛ اکیلا پتہ جڑ کے خلاف تصدیق نہیں ہوگا۔

درمیانی سے پتے جاری کریں، ڈیٹا بیس کے ساتھ

openssl x509 -req کے ساتھ دستخط کرنا تب تک کام کرتا ہے جب تک منسوخی کی ضرورت نہ ہو، کیونکہ کوئی چیز سیریل نمبر درج نہیں کرتی۔ پہلے سرٹیفکیٹ ہی سے openssl ca استعمال کریں تاکہ سیریل نمبر، میعاد اور منسوخی کی حالت ایک ہی ڈیٹا بیس میں رہیں۔ ڈیٹا بیس کی فائلیں ایک بار بنائیں، پھر کنفیگریشن ان کی طرف موڑیں:

mkdir -p /etc/vpn-ca/intermediate/newcerts
touch /etc/vpn-ca/intermediate/index.txt
echo 1000 > /etc/vpn-ca/intermediate/serial
echo 1000 > /etc/vpn-ca/intermediate/crlnumber

[ ca ]
default_ca = CA_default
[ CA_default ]
dir = /etc/vpn-ca/intermediate
database = $dir/index.txt
new_certs_dir = $dir/newcerts
serial = $dir/serial
crlnumber = $dir/crlnumber
certificate = $dir/intermediate.crt
private_key = $dir/intermediate.key
default_md = sha256
default_days = 365
default_crl_days = 30
unique_subject = no
policy = policy_any
[ policy_any ]
commonName = supplied
[ server_cert ]
basicConstraints = CA:FALSE
keyUsage = critical, digitalSignature
extendedKeyUsage = serverAuth
subjectAltName = @server_names
[ client_cert ]
basicConstraints = CA:FALSE
keyUsage = critical, digitalSignature
extendedKeyUsage = clientAuth
[ server_names ]
DNS.1 = vpn.example.com

چابی کے استعمال کی سطر ECDSA چابی فرض کرتی ہے؛ RSA کے لیے keyEncipherment شامل کریں۔ ہر کلائنٹ کو اس کا اپنا عمومی نام دیں، کیونکہ OpenVPN اسی فیلڈ سے کنکشن کی شناخت کرتا ہے، اور CN=vpn-client مشترکہ رکھنے والے دو لیپ ٹاپ لاگز میں، client-config-dir کے قواعد میں یا کسی بھی فی صارف پش میں الگ نہیں پہچانے جا سکتے، اور آپ وہ انتساب کھو دیتے ہیں جو منسوخی کے فیصلے کو قابل دفاع بناتا ہے۔ پتہ اس طرح جاری اور تصدیق کریں:

openssl req -new -key alice.key -subj "/CN=alice-laptop" -out alice.csr
openssl ca -config intermediate.cnf -extensions client_cert -in alice.csr -out alice.crt -batch
openssl verify -CAfile ca-bundle.crt -untrusted intermediate.crt alice.crt

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

جڑ کو جگائے بغیر منسوخی شائع کریں

کلائنٹ سرٹیفکیٹ درمیانی منسوخ کرتا ہے، کبھی جڑ نہیں۔ جڑ کی فہرست صرف اس وقت اہم ہے جب کوئی درمیانی جل جائے۔ سرور کو crl-verify کے ذریعے درمیانی فہرست کی طرف موڑیں۔ فائل پر مبنی CRL سروس شروع ہونے پر لوڈ ہوتا ہے، اس لیے ہر دوبارہ پیداوار کے بعد اسے دوبارہ لوڈ کریں؛ ڈائریکٹری شکل جڑنے کے وقت حالت پڑھتی ہے اور فی سیریل نمبر ایک فائل خرچ کرتی ہے۔

اسی ڈیٹا بیس سے دو کمانڈوں کے ساتھ منسوخ کریں اور دوبارہ بنائیں:

openssl ca -config intermediate.cnf -revoke /etc/vpn-ca/intermediate/newcerts/1001.pem
openssl ca -config intermediate.cnf -gencrl -out /etc/openvpn/crl.pem

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

زنجیر کی جانچ کریں، پھر رسم لکھیں

ڈیزائن پر بھروسا کرنے سے پہلے چار ناکامیاں دوبارہ پیدا کریں۔ openssl verify -CAfile ca-bundle.crt -untrusted intermediate.crt server.crt کے ساتھ زنجیر کی تصدیق کریں۔ میعاد ختم شدہ کلائنٹ سرٹیفکیٹ کے ساتھ جڑیں اور تصدیق کریں کہ سرور اسے مسترد کرتا ہے۔ ٹیسٹ کلائنٹ منسوخ کریں، دوبارہ لوڈ کریں اور تصدیق کریں کہ فہرست نافذ ہوتی ہے۔ ہوسٹ کی گھڑی ایک دن آگے بڑھائیں، کیونکہ غلط گھڑی ایسے سرٹیفکیٹ جاری اور مسترد کر سکتی ہے جو کہیں اور درست دکھتے ہیں۔

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

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