PKCS12 یا PEM یا DER: یک کلاینت VPN واقعاً به چه چیزی نیاز دارد
بسته‌بندی تعیین می‌کند که کلاینت شما هویت را وارد می‌کند یا نه، نه اینکه قابل اعتماد است یا نه. PKCS12 و PEM و DER را مقایسه کنید و سپس بررسی کنید.
در بحث‌های مربوط به گواهی‌ها دو ادعا می‌چرخد. اولی این است که .p12 گزینهٔ قوی است و .pem گزینهٔ شل؛ دومی این است که یک فایل متنی باید برای ارسال امن باشد چون می‌توانید آن را بخوانید. هیچ‌کدام یک دقیقه بازرسی را تحمل نمی‌کنند.
PKCS12 و PEM و DER توصیف می‌کنند که اشیای گواهی چگونه بسته‌بندی و کدگذاری می‌شوند. آن‌ها تعیین نمی‌کنند طرف مقابل کیست، آیا صادرکننده قابل اعتماد است، یا آیا فایل به گذرواژه نیاز دارد.
آنچه کلاینت می‌پذیرد پرسشی دربارهٔ سازگاری است. آنچه فایل در خود دارد پرسشی دربارهٔ هویت است. این دو را جدا نگه دارید تا بیشتر خطاهای ورود دیگر مرموز نباشند.
سه ظرف، یک مدل شیء
از آنچه واقعاً دارید شروع کنید. گواهی یک بیانیهٔ امضاشده دربارهٔ یک کلید عمومی است. کلید خصوصی مادهٔ جدایی است که ثابت می‌کند آن کلید را کنترل می‌کنید. زنجیره مجموعه‌ای از صادرکنندگان است که گواهی شما را به ریشه‌ای که کلاینت به آن اعتماد دارد پیوند می‌دهد. هر سه مستقل از بسته‌بندی وجود دارند.
فایل PKCS12، معمولاً .p12 یا .pfx، ظرفی است که در RFC 7292 تعریف شده و می‌تواند کلید خصوصی، یک یا چند گواهی و زنجیره را در یک بلوک محافظت‌شده با گذرواژه حمل کند، همراه با نام مستعاری که هویت را نام می‌برد. فایل PEM قالبی متنی است که در RFC 7468 تعریف شده: بدنهٔ base64 میان خطوط BEGIN و END، و یک فایل می‌تواند چندین بلوک را پشت سر هم نگه دارد. DER کدگذاری دودویی همان ساختارهای ASN.1 است، و بدنهٔ PEM عملاً DER است که base64 دور آن پیچیده شده.
همان جملهٔ آخر ارزش نگه داشتن دارد. تبدیل 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 می‌خواهد، کلید و زنجیره را استخراج کنید، و سپس فایل‌های میانی را با همان فرایند رسیدگی به اعتبارنامه‌ای که تیمتان از قبل استفاده می‌کند حذف کنید.
پس از ورود، هویت را بررسی کنید نه گفت‌وگو را: موضوع، صادرکننده، انقضا و نامی که کلاینت ارائه خواهد کرد. نام خوشایند در یک فهرست یک برچسب است، نه هویت تأییدشده. اگر تونل سپس شکست بخورد، در حال اشکال‌زدایی احراز هویت یا مسیریابی هستید نه بسته‌بندی، که گفت‌وگوی بسیار کوتاه‌تری است.