PKCS12، PEM یا DER: VPN کلاینټ ته واقعاً څه ته اړتیا ده
بستهبندي فیصله کوي چې کلاینټ هویت وارد کړي که نه، نه دا چې هغه باوري دی که نه. PKCS12، PEM او DER پرتله کړئ، بیا تایید کړئ.
د سندونو په بحثونو کې دوه ادعاوې ګرځي۔ لومړی دا چې .p12 غښتلی انتخاب دی او .pem سست؛ دویم دا چې متني فایل باید د لېږلو لپاره خوندي وي ځکه چې تاسو یې لوستلی شئ۔ دواړه د یوې دقیقې تفتیش تاب نه شي راوړلی۔
PKCS12، PEM او DER بیانوي چې د سند شیان څنګه بستهبندي او کوډ کیږي۔ دوی نه فیصله کوي چې مقابل لوری څوک دی، ایا صادرونکی باوري دی، یا ایا فایل ته پاسورډ ته اړتیا ده۔
هغه څه چې کلاینټ یې مني د مطابقت پوښتنه ده۔ هغه څه چې فایل کې دي د هویت پوښتنه ده۔ دا دواړه جلا وساتئ او ډیری د وارداتو تېروتنې به نورې مرموزې نه وي۔
درې کانټینرونه، یو شی ماډل
له هغه څخه پیل وکړئ چې واقعاً لرئ۔ سند د عامه کیلي په اړه لاسلیک شوې اعلامیه ده۔ شخصي کیلي جلا مواد دي چې ثابتوي تاسو هغه کیلي کنټرولوئ۔ زنځیر د هغو صادرونکو ټولګه ده چې ستاسو سند له هغې ریښې سره نښلوي چې کلاینټ باور پرې کوي۔ درې واړه د بستهبندۍ څخه خپلواک شتون لري۔
د PKCS12 فایل، معمولاً .p12 یا .pfx، په RFC 7292 کې تعریف شوی کانټینر دی چې کولای شي شخصي کیلي، یو یا ډیر سندونه او زنځیر په یوه د پاسورډ له مخې ساتل شوې بلاک کې وړي، د هویت نومولو لپاره د یو کنیت سره۔ د PEM فایل په RFC 7468 کې تعریف شوی متني چوکاټ دی: د BEGIN او END کرښو ترمنځ base64 بدن، او یو فایل کولای شي څو بلاکونه پرلهپسې ولري۔ DER د همدې ASN۔1 جوړښتونو باینري کوډ کول دي، او PEM بدن په لفظي توګه base64 کې راپېچل شوی DER دی۔
هغه وروستی جمله د یادولو وړ ده۔ PEM په DER بدلول چوکاټ بیا لیکي، نه منځپانګه، او بیرته بدلول اصلي بایټونه راوړي۔
| Container | Can hold | Does not decide |
|---|---|---|
| PKCS12 (.p12, .pfx) | Key, leaf certificate, chain, alias, password | Which root the client trusts |
| PEM (.pem, .crt, .cer) | Any number of base64 blocks | Whether the private key is present |
| DER (.der, .cer) | One binary structure | The object type, whatever the extension says |
کوډ کول انکرپشن نه دی
base64 د لېږد الفبا ده۔ هغه څه نه پټوي، او هر څوک کولای شي په شیل کې د PEM بلاک کوډ پرانیزي۔ د DER فایل باینري او هماغه ډول عامه دی۔ هیڅ یو ځانګړتیا ساتنه نه ده، او هیڅ یوه د پاسورډ شتون نه ښیي۔
ریښتینې ساتنه د کیلي په موادو کې ده۔ د PKCS12 بنډل کولای شي خپله منځپانګه له پاسورډ څخه اخیستل شوې کیلي سره انکرپټ کړي۔ د PEM شخصي کیلي د زاړه سرلیک بلاک سره انکرپټ کېدای شي یا په PKCS#8 EncryptedPrivateKeyInfo کې وساتل شي۔ سند پخپله هیڅ پټ نه ساتي، له همدې کبله هغه صادرات چې یوازې سند ورکوي کلاینټ د تصدیق کولو توان نه لري، په هر فورمت کې چې یې پېچئ۔
غځېدنه اشاره ده، قرارداد نه۔ هغه فایلونه چې په .cer او .crt پای ته رسي په دواړو کوډ کولو کې ښکاري، او وسایل د DER سندونه د .pem نومونو لاندې دومره ډیر صادروي چې د پای څخه اټکل کول یوه ماسپښین ضایع کوي۔ پرځای یې لومړي بایټونه ولولئ: د PEM فایل د BEGIN کرښې سره پرانیستل کیږي، DER بیا له 0x30 سره پیل کیږي ځکه چې بهرنی جوړښت SEQUENCE دی۔
ولې واردات واقعاً ناکام کیږي
د کلاینټ د تېروتنې پیغامونه څو مختلفې ستونزې په یوه جمله کې د ناسم سند په اړه فشردوي، نو د لامل له مخې یې جلا کړئ۔ ترټولو عام د کوډ کولو ناهمغږي ده: هغه کلاینټ چې PEM تحلیلوي په DER فایل کې د تحلیل تېروتنه ورکوي، او حل یې نوی سند نه، بدلون دی۔ دویمه ورکه کیلي ده، چېرې چې سند سم دی او هویت نه شي ثابتېدلی۔ دریمه زنځیر دی، چېرې چې پرته له منځني سند بنډل په وارداتو ډیالوګ کې سم ښکاري او د لاسورکولو پر مهال ناکام کیږي۔
د انکرپشن پیرامیټرونه څلورمه لامل دی، او هغه په بشپړه توګه د ناسم پاسورډ په څېر ښکاري۔ زاړه وسایل د PKCS12 فایلونه د RC2-40 او 3DES سره صادروي، چې OpenSSL 3 ردوي مګر دا چې لیګسي چمتوکوونکی وتړل شي۔ له وسیلې څخه د AES-256-CBC او PBKDF2 سره بیا صادرول تلپاتې حل دی۔ د یوه فایل لپاره په کلاینټ ماشین کې زاړه سایفرونه تل پرانیستې ساتل بد سودا ده۔
پنځمه ابهام دی۔ هغه کانټینر چې دوه کیلي او دوه سندونه لري، یا د PEM فایل چې درې CERTIFICATE بلاکونه لري، کلاینټ ته د انتخاب کولو فشار راوړي، او انتخاب یې ډیری وخت یوازې لومړی توکی وي۔ کله چې تونل د ناسم هویت سره پاڅي، معمولاً همدا لامل وي۔
مخکې له بدلولو تفتیش وکړئ
جوړښت ولولئ پرته له دې چې رازونه چاپ کړئ۔ openssl pkcs12 -in bundle.p12 -info -noout د انکرپشن الګوریتمونه او کنیتونه راپور ورکوي او د کیلي او سند وتل ځپي، او د openssl-pkcs12 لارښود علمونه مستند کوي۔ -noout لرې کول او -nodes زیاتول د هغو فایلونو لپاره دي چې غواړئ وساتئ، نه د یوې چټکې کتنې لپاره، ځکه چې شخصي کیلي په څرګنده لیکي۔
د سند لپاره، openssl x509 -in cert.pem -noout -subject -issuer -dates هغه څه ته ځواب وایي چې د وارداتو ډیالوګ به یې ځواب نه وایي، او -ext subjectAltName زیاتول هغه نومونه ښیي چې سند واقعاً ورته معتبر دی۔ که فایل DER وي، -inform DER زیات کړئ؛ هماغه یوه علامه ډیری unable-to-load تېروتنې حل کوي۔
کیلي له سند سره سمول میخانیکي کار دی، او د هر واردات مخکې یې کول ارزښت لري:
openssl x509 -in cert.pem -noout -pubkey | openssl sha256openssl pkey -in key.pem -pubout | openssl sha256
ورته ډایجیسټونه معنا دا ده چې جوړه یوځای ده۔ مختلف ډایجیسټونه معنا دا ده چې تاسو ناسمه کیلي لرئ، او هیڅ فورمت بدلون به یې نه بدلوي۔
هغه څه چې فورمت هیڅکله نه بدلوي
د باور پریکړې د کانټینر له پاسه کیږي۔ کلاینټ زنځیر تر خپلې زېرمې ریښې پورې ګرځي، د اعتبار کړکۍ ګوري، د کلاینټ تصدیق لپاره د کیلي پراخه کارونه ګوري، او د سرور په اړخ کې ګوري چې هغه نوم چې یې ډایل کړی په سند کې دی۔ له دې ګامونو هیڅ یو د فایل غځېدنه نه لولي۔
له همدې کبله د فایل نوم بدلول تر هغه چې تېروتنه ورکه شي د وخت ضایع کولو دومره باوري لار ده۔ واردات بریالي کیږي، هویت بیا هم ناسم دی، او ناکامي د لاسورکولو پر مهال بیرته راځي چېرې چې پیغام لږ مرسته کوونکی دی۔ له همدې کبله دوه کاله مخکې صادر شوی بنډل پاک واردیږي او بیا هم رد کیږي: د پای نیټه د فایل په نوم کې نه، د سند دننه سفر کړی و۔
د بیا کار مخه نیوونکی ترتیب
د کلاینټ له مستنداتو وپوښتئ چې کوم کوډ کول مني او د کلاینټ هویت لپاره کوم کانټینر تمه لري، بیا وګورئ چې تاسو ته څه ورکړل شوي۔ که کلاینټ یو د وارداتو وړ هویت غواړي او تاسو جلا PEM فایلونه لرئ، بنډل یو ځل د هغه پاسورډ سره جوړ کړئ چې تاسو یې کنټرولوئ او سرچینې وساتئ۔ که PEM غواړي، کیلي او زنځیر راوباسئ، بیا منځني فایلونه د هغه اعتبارنامې سمبالښت پروسې له لارې لرې کړئ چې ستاسو ټیم لا دمخه کاروي۔
له وارداتو وروسته هویت تایید کړئ نه ډیالوګ: موضوع، صادرونکی، پای او هغه نوم چې کلاینټ به وړاندې کړي۔ په لیست کې دوستانه نوم یوه لیبل ده، نه تصدیق شوی هویت۔ که بیا تونل ناکام شي، تاسو د بستهبندۍ پرځای تصدیق یا لارښوونه ډیبګ کوئ، چې ډیره لنډه خبرې اترې ده۔