strongSwan: کلید کی قسم، لوڈر اور غلط backend

فائل ایکسٹینشنز کلید الگورتھم کی شناخت نہیں کرتیں، اور .pem لفافے میں RSA یا ECDSA مواد ہو سکتا ہے۔ PEM بیان کرتا ہے کہ بائٹس کیسے لپٹے جاتے ہیں، جبکہ RSA اور ECDSA مختلف الگورتھم کے نام ہیں، اور PKCS12 فائل تیسری چیز ہے۔ strongSwan پلگ انز اور کنفیگریشن backend کے ذریعے اسناد لوڈ کرتا ہے، اس لیے سرٹیفکیٹ فہرست میں دکھائی دے سکتا ہے جبکہ نجی کلید کبھی قابل استعمال نہیں بنتی۔ کسی بھی راز میں ترمیم سے پہلے ان تہوں کو الگ کریں۔

اینکوڈنگ، الگورتھم اور پیکیجنگ تین تہیں ہیں

کلید کی فائل میں اینکوڈنگ، الگورتھم اور اکثر ایک کنٹینر ہوتا ہے۔ PEM جانا پہچانا base64 لفافہ ہے؛ DER اس کا بائنری ہم منصب ہے؛ PKCS12 ایک سرٹیفکیٹ کو اس کی کلید اور زنجیر کے ساتھ جوڑتا ہے۔ سرٹیفکیٹ زنجیر کی فائل ایک اور کنٹینر ہے، اور عام طور پر اس میں کوئی نجی کلید نہیں ہوتی۔ ان میں سے کوئی لیبل یہ نہیں بتاتا کہ اندر کا مواد RSA ہے یا ECDSA۔

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

لوڈر کو قصوروار ٹھہرانے سے پہلے عوامی کلیدوں کا موازنہ کریں

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

openssl x509 -in server.crt -pubkey -noout |
    openssl pkey -pubin -outform DER |
    openssl dgst -sha256

openssl pkey -in server-key.pem -pubout -outform DER |
    openssl dgst -sha256

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

پرانی ipsec.secrets یا swanctl اسناد

strongSwan میں اسناد کے دو عام راستے ہیں۔ پرانا starter اسٹیک قسم کے مخصوص اندراجات یہاں سے پڑھتا ہے: ipsec.secrets، اور ہر اندراج کو مواد کے لیے درست قسم بتانی چاہیے۔ swanctl اور vici اسٹیک اپنی اسناد ڈائریکٹری سے اپنی ترتیب کے ذریعے کلیدیں لوڈ کرتا ہے۔ چلتی ہوئی backend جو فائل نہیں پڑھتی اس میں ترمیم کچھ نہیں بدلتی۔

: ECDSA "/etc/ipsec.d/private/server-key.pem"

معلوم کریں کہ واقعی کون سا backend چل رہا ہے، پھر کلید وہاں رکھیں جہاں وہ backend دیکھتا ہے۔ strongSwan 5.9 پرانا دستور قسم کے مخصوص راز کے اندراجات کی وضاحت کرتا ہے، اور یہ swanctl دستاویز نہیں ہے۔ دونوں کو ملانا ایسا ڈیمن بناتا ہے جو اس فائل کو نظر انداز کرتا ہے جسے منتظم مستند سمجھتا ہے۔ بغیر خرابی کے دوبارہ لوڈ کا مطلب صرف یہ ہے کہ ترتیب تجزیہ ہوئی۔

لوڈ ایونٹ اور توثیق کا نتیجہ پڑھیں

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

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