زوړ P12 په OpenSSL 3 کې ناکام: غلط پټنوم که زوړ سایفر؟
په غلط ډول ټایپ شوی پټنوم له هغه زوړ RC2 بنډل څخه جلا کړئ چې OpenSSL 3 یې د پرانیستلو انکار کوي، بیا فایل د کیلي ساتنې پرته بیا سیل کړئ۔
د وارداتو ډیالوګ ستاسو پټنوم اخلي، لږ ګرځي او بیا وایي چې بنډل نشي لوستلی۔ په هغه پیغام کې هیڅ نه ویل کیږي چې پټنوم مو غلط ټایپ کړی که فایل د کوم سایفر سره سیل شوی چې کلاینټ نور نه ورکوي۔ دا جلا ناکامي او جلا سمونونه دي، او غلط انتخاب کلاینټ ته د کمېدو لامل کیږي چې پرېکړه یوازې وروسته کوي۔ دې ته کتل چې کلاینټ په کوم پړاو کې ودروي، دوی په نږدې یوه دقیقه کې جلا کوي۔
د ډیالوګ او د سند لیست ترمنځ څه پېښېږي
.p12 فایل یو کانټینر دی، سند نه دی۔ په منځ کې یو یا څو د سند کڅوړې او د شخصي کیلي کڅوړه ده چې ستاسو د پټنوم څخه اخیستل شوې کیلي سره انکرپټ شوې، او همدارنګه د ټول فایل باندې MAC په نوم د بشپړتیا کتنه ده۔ د هغې پرانیستل یعنې هغه MAC کتل، د کیلي کڅوړه ډيکرپټول او سند له رابهرېدونکې کیلي سره برابرول۔
د پټنوم ستونزه د MAC په پړاو کې راځي۔ د سایفر ستونزه وروسته راځي، کله چې د کیلي کڅوړه باید پرانیستل شي او جوړوونکې بیاډ کې د فایل کې نومول شوي الګوریتم پلي کول نه وي۔
دوهمه پېښه په نننیو سیستمونو کې عامه ده ځکه چې OpenSSL 3 د زړو الګوریتمونو یوه ډله اختیاري legacy provider ته واړوله۔ د OpenSSL 1.x لخوا صادر شوي بنډلونه معمولاً سندونه د 40-بټ RC2 سره او شخصي کیلي د درې کیلي Triple DES سره سیل کول۔ د OpenSSL 3 ډیفالټ بیاډ لا هم ستاسو د سم پټنوم سره MAC کتلی شي او بیا پر کڅوړه ناکام کیږي، نو پټنوم هیڅکله غلط نه و او بیا ټایپ کول یې هیڅ نه بدلوي۔
پرته له دې چې کیلي ولیکئ کانټینر ولولئ
په خپله ماشین کې OpenSSL بیاډ ته ووایاست چې فایل تحلیل کړي او هغه ځای ولولي چې هلته تسلیم شي۔ له آوټپټ فایل پرته کتنه کیلي په ډیسک کې انکرپټه پرېږدي، او په شریک شوي هوسټ کې د دې ګام د خوندي کېدو یوازینی لامل همدا دی۔
openssl pkcs12 -in vpn-identity.p12 -info -nooutپه زوړ بنډل کې چې سم پټنوم ولري دا د کڅوړې ځانګړنې چاپوي او بیا د digital envelope routines::unsupported سره ودروي۔ په غلط پټنوم کې د هرې کڅوړې له لوستلو دمخه Mac verify error: invalid password? ترلاسه کوئ۔ دواړه پیغامونه مخالف لوري ښیي، او کلاینټ همدا معلومات پټ کړي وو۔
که ناکامي د نه ملاتړ شوي الګوریتم وي، هماغه حکم د -legacy په زیاتولو سره او بل څه نه بدلولو سره بیا وچلوئ۔ هغه بیرغ legacy provider یوازې هماغه یوې پروسې لپاره باروي۔ دا VPN کلاینټ د زړو بنډلونو تحلیل ته نه اړ باسي، د ټول سیستم کریپټو پالیسي نه لمس کوي او دا سمون نه دی، اندازه کول دي، ځکه فایل لا هم باید بدل شي۔
کومه تېروتنه کوم پړاو ته اشاره کوي
لنډه جدول درې پایلې جلا ساتي، او د ډیالوګ د ښکارېدو ځای څخه عبارتونه مهم دي۔
| Text you see | Stage | What it tells you |
|---|---|---|
Mac verify error: invalid password? | Integrity check | Passphrase or cached credential, not the cipher |
digital envelope routines::unsupported | Bag decrypt | Algorithm missing from the default provider |
not enough data / header too long | Container format | Wrong encoding, edited file, or truncated download |
د not enough data یا header too long په څېر متن په لومړیو دوو ډلو کې نه راځي۔ دا د بڼې ستونزه ده: DER فایل چې .pem ته نوم بدل شوی، هغه کاپي چې د کرښو پای بیا لیکونکي ایډیټر خرابه کړې، یا نیمګړې ډاونلوډ۔ له سایفرونو کتلو دمخه د صادروونکي لخوا لېږل شوي چکسام سره پرتله کړئ۔
Mac verify error یوازې د پټنوم په اړه شاهد وګڼئ۔ دا مانا لري چې ستاسو له ټایپ شوي څخه محاسبه شوی MAC له ذخیره شوې ارزښت سره نه ځي، دا د ټایپ غلطۍ، د پخواني وارداتو څخه کیش شوي پټنوم یا بل پټنوم لاندې بیا صادر شوي فایل له امله پېښېږي۔ د منځنیو الګوریتمونو د زړوالي په اړه هیڅ نه وایي۔
داسې بنډل جوړ کړئ چې کلاینټ یې واقعاً پرانیستلی شي
کله چې legacy تحلیل کوونکی تصدیق کړي چې فایل سم دی، تلپاتې حل هغه بدیل دی چې الګوریتمونه یې هدف کلاینټ ملاتړ کوي: د کیلي او سند کڅوړو لپاره AES-256-CBC، د اخیستنې لپاره SHA-256 سره PBKDF2 او د MAC لپاره SHA-256۔ ستاسو PKI مدیر کولی شي دا له هماغه کیلي موادو څخه صادر کړي، او منځنی سند هغه پاتې کیږي چې ستاسو سرورونه دمخه باور پرې لري۔
کله چې په سیمه کې بدلون ته اړتیا وي، pkcs12 وسیلې ته ووایاست چې کڅوړې بیا سیل کړي، نه دا چې لومړی یې وتوي۔ دواړه پټنومونه د فایل څخه لوستل او له خپل شیل تاریخ څخه بهر یې وساتئ۔
openssl pkcs12 -in vpn-identity.p12 -out vpn-identity-aes.p12 \
-keypbe AES-256-CBC -certpbe AES-256-CBC -macalg sha256 \
-passin file:old.pass -passout file:new.passبریالۍ بدلون د پای نېټې، کیلي کارونې، شخصي کیلي برابرېدو یا د سرور د صادروونکې لړۍ باور په اړه هیڅ نه وایي۔ بیا بسته کول د لېږد بدلون دی، نوي کول نه، او هر یو له دوی خپله کتنه غواړي۔
هر هغه لارښوونه پرېږدئ چې بې ساتنې منځوکې کیلي لیکي یا خالي آوټپټ پټنوم پریږدي، یوازې ځکه چې کلاینټ بیا فایل ومنه۔ د ساتنې پرته لوستل کیدونکی بنډل د هغه وارداتو ناکامۍ څخه چې پیل یې کړی وو بد نتیجه ده۔
تصدیق کړئ چې کلاینټ هغه فایل وارد کړ چې تاسو جوړ کړی
په ټرمینل کې پاک تحلیل ثابوي چې کانټینر سم دی۔ دا نه ثابوي چې کلاینټ هغه غوره کړ، ځکه پاتې پروفایل کولی شي لا هم زوړ فایل ته اشاره وکړي، او ځینې کلاینټونه وارد شوی هویت د هغه نوم لاندې کیش کوي چې تاسو نه دی ټاکلی۔
هغه هویت چاپ کړئ چې واردول یې کوئ او له هغه سره یې پرتله کړئ چې کلاینټ په خپل د سند په کتنه کې ښیي۔
openssl pkcs12 -in vpn-identity-aes.p12 -clcerts -nokeys -passin file:new.pass \
| openssl x509 -noout -subject -dates -fingerprint -sha256لومړی زوړ پروفایل اندام لرې کړئ، بیا واردات وکړئ۔ که کلاینټ بار شوی موضوع یا د ګوتې نښه لاګ کوي، له پورتنۍ کرښې سره یې برابر کړئ؛ که یوازې دوستانه نوم ښیي، پرځای یې د پای نېټې کتنه وکړئ، ځکه د هغې له هماغه صادروونکي بل سند سره ګډول سخت دي۔
PKCS12 مرجع دلته کارول شوي provider، پټنوم او آوټپټ انتخابونه لیست کوي۔ legacy provider له کلاینټ چاپیریال څخه بهر ساتل اصل ټکی دی: ورسره اندازه وکړئ، پرته ترې وسپارئ او شخصي کیلي په ډیسک کې ساتلې پرېږدئ۔