جميع الأدلة

DEVOMNITOOLS / أدلة المطورين

فحص طلب CSR أو شهادة X.509 محلياً

افحص شهادات PEM وطلبات توقيع الشهادات داخل المتصفح. قارن الحقول وافهم الفرق بين طلب CSR والشهادة التي أصدرتها جهة التصديق.

DevOmniTools نُشر: حُدّث: 3 دقائق للقراءة

النقاط الأساسية

  • طلب CSR ليس شهادة صادرة.
  • الفحص لا يثبت الثقة بالشهادة ولا يتحقّق من إلغائها.
  • لا تُدخل مفاتيح خاصة في الأداة.

تمييز تنسيقات الإدخال

مخطط تحليل طلبات توقيع الشهادات الرقمية CSR وفق معيار PKCS#10

يتضمّن طلب توقيع الشهادة CSR بيانات صاحب الطلب ومفتاحه العام وتوقيعه. أما شهادة X.509 الصادرة فتتضمّن أيضاً جهة الإصدار والرقم التسلسلي وفترة الصلاحية والامتدادات. لا يملك طلب CSR فترة صلاحية تمنحها جهة الإصدار. قد يظهر كلاهما بصيغة PEM حول بيانات DER مرمّزة باستخدام Base64.

فحص الحقول

افتح قارئ شهادات X.509 وطلبات CSR وألصق كتلة PEM كاملة مع علامتَي BEGIN وEND. تشير CERTIFICATE إلى شهادة وCERTIFICATE REQUEST إلى طلب توقيع. يحلّل المتصفح بنية ASN.1 محلياً دون الحاجة إلى تثبيت OpenSSL لهذا الفحص.

-----BEGIN CERTIFICATE REQUEST-----
(base64 DER data)
-----END CERTIFICATE REQUEST-----

مراجعة النتيجة

قارن بيانات صاحب الشهادة بالهوية المقصودة. في الشهادة الصادرة راجع المُصدر وتواريخ الصلاحية والأسماء البديلة إن وُجدت، ثم خوارزمية المفتاح العام وحجمه. في طلب CSR راجع الهوية والمفتاح قبل إرساله إلى جهة التصديق. قراءة البيانات لا تتحقّق من سلسلة الثقة أو الإلغاء ولا تثبت أن الموقع آمن.

فصل المفاتيح الخاصة

لا تُلصق كتلة PRIVATE KEY مطلقاً. قد تكشف الشهادات العامة أسماء داخلية أو تفاصيل المؤسسة؛ استخدم مثالاً عند المشاركة. الذكاء الاصطناعي الاختياري منفصل عن التحليل المحلي وقد يرسل البيانات خارج المتصفح بعد الموافقة. اختبر العمل دون اتصال قبل الاعتماد على نسخة مخزّنة أثناء معالجة مشكلة.

معايير الفحص القياسي (RFC 2986 وRFC 5280)

عند تشخيص مشكلات مصادقة TLS والشهادات الرقمية في بيئات الإنتاج، انتبه للقواعد التشفيرية التالية:

  1. الأسماء البديلة (SAN) مقابل الاسم العام (CN): لم تعد متصفحات الويب الحديثة (وفقاً للمواصفة RFC 5280 وRFC 6125) تعتمد على حقل commonName. إذا لم تتضمن الشهادة أو طلب CSR ملحق subjectAltName الذي يحدد النطاقات أو عناوين IP، فسيرفض المتصفح الاتصال بالخطأ ERR_CERT_COMMON_NAME_INVALID.
  2. إثبات حيازة المفتاح (POP): في طلبات CSR المتوافقة مع معيار PKCS#10 (RFC 2986)، يقوم المفتاح الخاص بالتوقيع على بنية CertificationRequestInfo. تتحقق الأداة من هذا التوقيع الذاتي للتأكد من أن صاحب الطلب يمتلك المفتاح الخاص المطابق للمفتاح العام قبل إرساله إلى هيئة إصدار الشهادات (CA).
  3. قيود الاستخدام الإضافي للمفتاح (EKU): تحقق من معرفات OID الخاصة بالاستخدام للتأكد من تحديد serverAuth (1.3.6.1.5.5.7.3.1) لخوادم الويب أو clientAuth (1.3.6.1.5.5.7.3.2) للمصادقة الثنائية في بنية mTLS.
  1. إدخال PEM
  2. تحليل ASN.1
  3. فحص الشهادة أو الطلب
التحقق من الثقة يتطلّب فحوصاً إضافية.

تفكيك تشفير ASN.1 ومطابقة متطلبات شهادات SSL/TLS

يتبع طلب توقيع الشهادة (CSR) معيار PKCS#10 المشفر بصيغة DER والقائم على ترميز ASN.1. يوفر فحص الطلب محلياً قبل إرساله إلى هيئات إصدار الشهادات (CA) المزايا التالية:

  • التحقق من الأسماء البديلة للموضوع (SAN): تتطلب المتصفحات الحديثة ومحركات البحث وجود جميع النطاقات الفرعية داخل حقل Subject Alternative Names وليس فقط في الاسم العام (CN).
  • التحقق من طول مفتاح التشفير العام: تأكد من أن المفتاح العام المضمن في الطلب يفي بالحد الأدنى للأمان: مفاتيح RSA بطول 2048 بت على الأقل (ويُفضل 4096 بت)، أو مفاتيح المنحنيات الإهليلجية (ECDSA) باستخدام المنحنى P-256 أو P-384.
  • حماية المفتاح الخاص المرفق: تذكّر أن ملف CSR يحتوي على المفتاح العام فقط. لا ترفع أبداً المفتاح الخاص (.key) إلى أي موقع خارجي أو أداة عبر الإنترنت.