VPN کلید فائل میں RSA کے n، e، d، p اور q کہاں رہتے ہیں
n، e، d، p اور q ایک ہی ساخت کے اندر ہیں، فائل کے ناموں میں نہیں۔ OpenSSL سے RSA VPN کلید پڑھیں اور راز چھاپے بغیر اسے اس کے سرٹیفکیٹ سے ملا دیں۔
RSA کی وضاحت میں حروف ایک ہی شے کے اندرونی میدانوں کے نام ہیں، PKI اوزار کی دی ہوئی فائلوں کے نہیں۔ نجی کلید کی فائل ایسی ساخت رکھتی ہے جس کے پہلے میدان عوامی ہیں اور بعد والے میدان اس مشین سے کبھی نہیں نکلنے چاہئیں جو سرنگ ختم کرتی ہے۔ ان دو حقیقتوں کے درمیان یہ زیادہ تر عملی سوال ہیں کہ کون سی فائل کس سوال کا جواب دیتی ہے۔ یہ رہنما پہلے ساخت پڑھتا ہے، پھر وہ احکام جو اسے بہائے بغیر جانچتے ہیں۔
ابتدائی اعداد ڈھونڈنے سے پہلے یقینی بنائیں کہ کلید RSA ہے
سرٹیفکیٹ ثابت کرتا ہے کہ کوئی کلید موجود ہے اور اس پر دستخط ہوئے ہیں؛ یہ ثابت نہیں کرتا کہ کلید RSA ہے۔ نظام بیضوی منحنی خطوط یا Ed25519 پر بنائے جا سکتے ہیں، اور وہی ڈائریکٹری ترتیب سب کو خدمت دیتی ہے۔ وہ ابتدائی اجزا ڈھونڈنے سے پہلے الگورتھم جانچیں جو کبھی تھے ہی نہیں۔
یہ تین صرف-پڑھنے والے احکام سوال کا جواب دیتے ہیں اور اوزار کا نسخہ ریکارڈ کرتے ہیں۔
openssl version
openssl x509 -in vpn-client.crt -noout -text
openssl pkey -in vpn-client.key -noout -textنسخہ اہم ہے کیونکہ آپشنز کے نام بڑے ورژنوں کے درمیان سرکے ہیں۔ سرٹیفکیٹ کے آؤٹ پٹ میں عوامی کلید کے الگورتھم کی سطر اور کلید کا حجم ڈھونڈیں؛ کلید کے آؤٹ پٹ میں RSA کلید ایک ماڈیولس اور ایک عوامی قوت نمائی چھاپتی ہے۔ بیضوی منحنی خط کی کلید اس کے بجائے نام والا منحنی خط چھاپتی ہے، اور کوئی تلاش اس سے n یا q نہیں نکالے گی۔
base64 کے بجائے ساخت پڑھیں
PEM سرخیوں کی سطروں میں لپٹا base64 ہے، اور اسے ڈی کوڈ کرنے سے DER ملتا ہے، یعنی بہت بڑا عدد نہیں بلکہ ترتیب شدہ ساخت۔ RSA نجی کلیدیں دو عام کنٹینروں میں سفر کرتی ہیں، PKCS#1 اور PKCS#8، اور دونوں ایک ہی اعداد کے مجموعے پر آتے ہیں۔
دو ابتدائی اعداد کی صورت میں نجی ساخت نو میدان رکھتی ہے: نسخہ، ماڈیولس n، عوامی قوت نمائی e، نجی قوت نمائی d، ابتدائی اعداد p اور q، دو CRT قوت نمائیاں اور ایک CRT گتانک۔ RFC 8017 کا حصہ A.1 ان اجزا اور ASN.1 ترتیب کی تعریف کرتا ہے، اور دو سے زیادہ ابتدائی اعداد کی بھی اجازت دیتا ہے، اسی لیے ایک عام تجزیہ کار اضافی ابتدائی اندراج چھاپ سکتا ہے۔ ترتیب پر توجہ دیں، کیونکہ یہ ایک عام غلطی کی وضاحت کرتی ہے: عوامی آدھا حصہ نجی فائل کے اندر محفوظ ہوتا ہے، اس لیے عوامی میدان کی موجودگی اس فائل کو بانٹنے کے لیے محفوظ نہیں بناتی۔ اس کے بعد کا سب کچھ وہ مواد ہے جو میزبان پر ہی رہنا چاہیے۔
اینکوڈنگ ایک ایسی تہہ جوڑتی ہے جسے مندرجات سے گڈمڈ کرنا آسان ہے۔ openssl asn1parse ساخت کو درخت کی طرح کھینچتا ہے تاکہ میدانوں کی ترتیب نظر آئے، اور یہ کچھ ڈکرپٹ نہیں کرتا اور یہ بھی نہیں بتاتا کہ کلید قابل استعمال ہے یا نہیں۔
کلید چھاپے بغیر سرٹیفکیٹ کو کلید سے ملائیں
اگلا سوال عام طور پر یہ ہوتا ہے کہ سرٹیفکیٹ اور کلید ایک ساتھ ہیں یا نہیں۔ ماڈیولس کا موازنہ اس کا جواب دیتا ہے، مگر نجی کے قریب مواد کو ٹرمینل ریکارڈ میں بھی نقل کرتا ہے جو ٹکٹ میں پہنچ سکتا ہے۔ عوامی آدھوں کا موازنہ اسی سوال کا جواب اسکرین پر کچھ بھی حساس رکھے بغیر دیتا ہے۔
openssl pkey -in vpn-client.key -pubout -out /tmp/key.pub
openssl x509 -in vpn-client.crt -pubkey -noout > /tmp/cert.pub
cmp /tmp/key.pub /tmp/cert.pub && echo MATCHیکساں فائلوں کا مطلب ہے کہ سرٹیفکیٹ اس کلید کا عوامی آدھا حصہ رکھتا ہے، اور فرق کا مطلب ہے کہ آپ غلط جوڑی پکڑے ہوئے ہیں۔ یہی عدم مطابقت اس سرنگ کی سب سے عام وجہ ہے جو خوشی سے بات چیت کرتی ہے اور پھر تصدیق سے انکار کر دیتی ہے۔ پھر دو عارضی فائلیں ہٹا دیں؛ ان میں کچھ بھی خفیہ نہیں، مگر واقعے کے بیچ صاف کام کی ڈائریکٹری پر غور کرنا آسان ہے۔
جانیں کہ پڑوسی فائلیں کیا نہیں ہیں
سرٹیفکیٹ وہ مرموز عوامی کلید نہیں جسے سامنے والا فریق CA سرٹیفکیٹ سے کھولتا ہے؛ یہ عوامی کلید اور شناخت کے ڈیٹا کے درمیان دستخط شدہ بندھن ہے۔ CA کی نجی دستخط کلید اپنے سرٹیفکیٹ اور ہر کلائنٹ کلید سے الگ رہتی ہے۔ درخواست بھی سرٹیفکیٹ نہیں: یہ طلب شدہ معلومات اور عوامی کلید درخواست پر دستخط کے ساتھ رکھتی ہے، جو اسے اندراج کا ان پٹ بناتا ہے، حق کا ثبوت نہیں۔
| File | Answers | Does not prove |
|---|---|---|
| vpn-client.key | Possession of the private key | That the identity is enrolled |
| vpn-client.crt | A signed binding of public key to identity | That the client holds the matching key |
| vpn-client.csr | The requested binding and public key | That access was granted |
| dh2048.pem | Group parameters for key exchange | Any RSA component |
| crl.pem | Revocation status for certificates | Anything about a private key |
ان اندراجات میں سے دو RSA پیرامیٹرز سے اتنی بار گڈمڈ ہوتے ہیں کہ انہیں دو بار نام دینا پڑتا ہے۔ Diffie-Hellman پیرامیٹر فائل کلید قائم کرنے کے لیے گروہی پیرامیٹر رکھتی ہے اور کوئی RSA ابتدائی عدد نہیں، اگرچہ یہ بھی بڑے ابتدائی عدد کے طور پر چھپتی ہے۔ منسوخی کی فہرست سرٹیفکیٹوں کی حالت شائع کرتی ہے اور ایسی جگہ نہیں جہاں نجی قوت نمائی چھپ سکے۔
اس لیے ہر فہرست سطر کو چار چیزیں ریکارڈ کرنی چاہئیں: شے کی قسم، مالک، مقصد اور کیا نجی مواد شامل ہے۔ آخری کالم طے کرتا ہے کہ فائل کہاں نقل کی جا سکتی ہے، اور لوگ اسی کو چھوڑ دیتے ہیں۔
جوڑ ریکارڈ کریں، پھر ہینڈ شیک کی تصدیق کریں
کچھ بھی بدلنے سے پہلے تصدیق کا آؤٹ پٹ تاریخ اور OpenSSL نسخے کے ساتھ محفوظ کریں۔ پھر بعد کی گردش کا موازنہ حافظے کے بجائے ثبوت سے کیا جا سکتا ہے۔
openssl verify -CAfile ca.crt vpn-client.crt
openssl x509 -in vpn-client.crt -noout -subject -issuer -datesعوامی کلید کے موازنے کے بعد وہ راستہ چلائیں جو جوڑی استعمال کرتا ہے: سرنگ اوپر اٹھائیں، یقینی بنائیں کہ سرٹیفکیٹ پیش ہوتا اور قبول ہوتا ہے، اور دیکھیں کہ گیٹ وے نے کون سی شناخت ریکارڈ کی۔ اگر کلید اور سرٹیفکیٹ ملتے ہیں اور تصدیق پھر بھی ناکام ہوتی ہے، تو نقص جوڑی میں نہیں، اعتماد، شناخت میپنگ یا رسائی پالیسی میں ہے۔
واپسی کے لیے پچھلی کلید اور سرٹیفکیٹ تاریخ والی ڈائریکٹری میں رکھیں اور دونوں کو ساتھ بحال کریں، کبھی ایک کو نہیں۔ سرٹیفکیٹ کے بغیر کلید اور کلید کے بغیر سرٹیفکیٹ باہر سے یکساں ناکام ہوتے ہیں، جو آدھی بحال شدہ جوڑیوں کو رات دو بجے سلجھانا مہنگا بنا دیتا ہے۔