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؛ هذا العلم الواحد يحل معظم أخطاء تعذّر التحميل.
مطابقة مفتاح بشهادة عملية ميكانيكية، وتستحق أن تُجرى قبل أي استيراد:
openssl x509 -in cert.pem -noout -pubkey | openssl sha256openssl pkey -in key.pem -pubout | openssl sha256
البصمات المتطابقة تعني أن الزوجين ينتميان لبعضهما. البصمات المختلفة تعني أن لديك المفتاح الخطأ، ولا تحويل تنسيق سيغيّر ذلك.
ما لا يغيّره التنسيق أبداً
قرارات الثقة تحدث فوق الحاوية. يمشي العميل في السلسلة إلى جذر في مخزنه، ويتحقق من نافذة الصلاحية، ويتحقق من استخدام المفتاح الموسّع لمصادقة العميل، ويتحقق على جانب الخادم من ظهور الاسم الذي اتصل به في الشهادة. لا شيء من هذه الخطوات يقرأ امتداد ملف.
لهذا فإن إعادة تسمية ملف حتى يختفي خطأ طريقة موثوقة لإهدار الوقت. ينجح الاستيراد، وتبقى الهوية خاطئة، ويعود الفشل أثناء المصافحة حيث الرسالة أقل إفادة. ولهذا أيضاً تُستورد حزمة صُدّرت قبل عامين بنظافة وتُرفض رغم ذلك: تاريخ الانتهاء سافر داخل الشهادة لا في اسم الملف.
ترتيب يتجنب إعادة العمل
اسأل وثائق العميل عن الترميزات التي يقبلها والحاوية التي يتوقعها لهوية العميل، ثم انظر فيما أُعطي لك. إن أراد العميل هوية واحدة قابلة للاستيراد ولديك ملفات PEM منفصلة، ابنِ الحزمة مرة واحدة بكلمة مرور تتحكم بها واحتفظ بالمصادر. وإن أراد PEM، فاستخرج المفتاح والسلسلة، ثم أزل الملفات الوسيطة عبر عملية معالجة بيانات الاعتماد التي يستخدمها فريقك أصلاً.
بعد الاستيراد، تحقق من الهوية لا من مربع الحوار: الموضوع والمُصدر والانتهاء والاسم الذي سيقدمه العميل. الاسم الودود في قائمة تسمية لا هوية موثّقة. وإن فشل النفق بعد ذلك فأنت تصحح مصادقة أو توجيهاً بدلاً من تغليف، وهو حديث أقصر بكثير.