کراس دستخط شدہ CA: کلید میل کھاتی ہے، AKI بندھن نہیں

دو CA سرٹیفکیٹ ایک ہی عوامی کلید اور ایک ہی subject رکھ سکتے ہیں اور پھر بھی قابلِ تبادلہ نہیں ہوتے۔ ایک خود دستخط شدہ ہے، دوسرا پرانی جڑ سے کراس دستخط شدہ ہے، اور ان کے جاری کنندہ نام، سیریل نمبر اور دستخط مختلف ہیں۔ ایک پتہ اپنی Authority Key Identifier کے ذریعے خاص طور پر ان میں سے ایک سے جڑ سکتا ہے۔ یہ بندھن اس وقت تک پوشیدہ رہتا ہے جب تک کوئی کلائنٹ غلط زنجیر نہ چنے اور handshake بغیر کسی واضح وجہ کے ناکام نہ ہو جائے۔

یہ پانچ جانچیں ترتیب سے کریں: ہر ایک مختلف ناکامی کو خارج کرتی ہے۔

جانچ 1: ٹیمپلیٹ چھونے سے پہلے دونوں زنجیریں کھینچیں

راستے لکھ لیں۔ پرانی آبادی پرانی جڑ A پر بھروسا کرتی ہے، جس نے CA B جاری کیا، جس نے سرور کا پتہ جاری کیا۔ نئی آبادی خود دستخط شدہ CA B پر براہِ راست بھروسا کرتی ہے۔ دونوں B سرٹیفکیٹ ایک ہی کلید اور subject رکھتے ہیں، اور اسی وجہ سے subject سطر پڑھنے والا شخص ایک CA دیکھتا ہے جہاں کلائنٹ دو دیکھتا ہے۔

کراس دستخط شدہ نقل بھی حقیقی CA سرٹیفکیٹ ہونی چاہیے، جس میں basic constraints اور key usage دستخط کی اجازت دیں۔

جانچ 2: صرف کلید نہیں، AKI فیلڈز کا موازنہ کریں

پتے کے جاری کنندہ کا نام B کے subject سے میل کھانا چاہیے، اور یہ حصہ عام طور پر قائم رہتا ہے۔ دو نقلیں جہاں الگ ہوتی ہیں وہ Authority Key Identifier ہے، کیونکہ یہ کلید شناخت کنندہ، جاری کنندہ سرٹیفکیٹ اور سیریل نمبر رکھ سکتا ہے۔ کلید شناخت کنندہ دونوں نقلوں سے میل کھاتا ہے، کیونکہ کلید یکساں ہے۔ جاری کنندہ اور سیریل فیلڈز بالکل ایک سے میل کھاتے ہیں، اسی لیے خود دستخط شدہ نقل کے خلاف بنی زنجیر کراس دستخط شدہ کے خلاف ناکام ہو سکتی ہے۔

اندازہ لگانے کے بجائے پتہ دیکھیں: openssl x509 -in server.pem -noout -ext authorityKeyIdentifier۔

پھر دونوں امیدواروں کا openssl x509 -in b-cross.pem -noout -text | grep -A2 "Authority Key Identifier" سے موازنہ کریں، اور وہی حکم خود دستخط شدہ نقل کے خلاف چلائیں۔

اگر پتہ جاری کنندہ اور سیریل نمبر رکھتا ہے، تو صرف وہی سرٹیفکیٹ زنجیر مکمل کرتا ہے جسے یہ اقدار بیان کرتی ہیں، کلائنٹ نے کوئی بھی نقل لوڈ کی ہو۔

جانچ 3: اجرا کی پالیسی بدلیں، دستخط شدہ بائٹس کبھی نہیں

ایکسٹینشن دستخط کے اندر رہتے ہیں۔ موجودہ پتے پر ایک شامل کرنا، ہٹانا یا ترمیم کرنا مرمت نہیں، یہ مختلف سرٹیفکیٹ ہے، اور اسے دوبارہ جاری کرنا پڑتا ہے۔ تبدیلی اجرا کی پالیسی میں آتی ہے: authorityKeyIdentifier = keyid,issuer:always نئے پتوں کو سرٹیفکیٹ کے مخصوص بندھن کے ساتھ بھیجتا ہے، جبکہ تنہا keyid وہ ڈھیلا روپ رکھتا ہے جو جان بوجھ کر کیے گئے کراس دستخطی منتقلی کے لیے موزوں ہے۔ اگلی بیچ دستخط ہونے سے پہلے فیصلہ کریں کہ آپ کی PKI کیا چاہتی ہے۔

مشترکہ ٹیمپلیٹ میں ترمیم آپ کے سامنے والے سرور ہی نہیں، ہر آئندہ سرٹیفکیٹ کو بھی بدل دیتی ہے۔

جانچ 4: ہر اعتماد آبادی کو الگ الگ تصدیق کریں

پرانا راستہ اور نیا راستہ الگ رن کے طور پر آزمائیں۔ openssl verify -purpose sslserver -verify_hostname vpn.example -CAfile old-root.pem -untrusted b-cross-signed.pem server.pem کراس دستخط شدہ راستہ مشق کرتا ہے، اور نئی جڑ اور untrusted فائل کے بغیر وہی حکم خود دستخط شدہ راستہ مشق کرتا ہے۔ دونوں جڑیں ایک بنڈل میں ملانا چھپا دیتا ہے کہ کون سی زنجیر منتخب ہوئی۔ پھر حقیقی کلائنٹس کے ساتھ دہرائیں، کیونکہ VPN بیک اینڈ کسی زنجیر کو ترجیح دے سکتا ہے یا سرٹیفکیٹ پن کر سکتا ہے ایسے طریقوں سے جو openssl نہیں کرتا۔

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

جانچ 5: پرانے راستے کو ریٹائرمنٹ گھڑی پر رکھیں

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

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