X.509

📅 آخر تحديث: ٤ أغسطس ٢٠٢٦
✍️ نُشر في: ٤ أغسطس ٢٠٢٦
📷 يحتوي على 3 صور
الموسوعة الحرة

في علم التشفير ، يُعدّ X.509 معيارًا صادرًا عن الاتحاد الدولي للاتصالات (ITU) يُحدد تنسيق شهادات المفتاح العام . [ 1 ] تُستخدم شهادات X.509 في العديد من بروتوكولات الإنترنت، بما في ذلك TLS/SSL ، الذي يُشكّل أساس HTTPS ، [ 2 ] وهو البروتوكول الآمن لتصفح الويب . كما تُستخدم أيضًا في التطبيقات غير المتصلة بالإنترنت، مثل التوقيعات الإلكترونية . [ 1 ]

تربط شهادة X.509 هويةً بمفتاح عام باستخدام توقيع رقمي. تحتوي الشهادة على هوية ( اسم مضيف ، أو مؤسسة، أو فرد) ومفتاح عام ( RSA ، أو DSA ، أو ECDSA ، أو ed25519 ، إلخ)، ويتم توقيعها إما من قِبل جهة إصدار شهادات (CA) أو ذاتيًا. عندما يتم توقيع الشهادة من قِبل جهة إصدار شهادات موثوقة، أو التحقق منها بوسائل أخرى، يمكن لحامل تلك الشهادة استخدام المفتاح العام الذي تحتويه لإنشاء اتصالات آمنة مع طرف آخر، أو للتحقق من صحة المستندات الموقعة رقميًا بواسطة المفتاح الخاص المقابل .

يحدد X.509 أيضًا قوائم إبطال الشهادات ، وهي وسيلة لتوزيع المعلومات حول الشهادات التي اعتبرتها جهة التوقيع غير صالحة، بالإضافة إلى خوارزمية التحقق من صحة مسار الشهادة ، والتي تسمح بتوقيع الشهادات بواسطة شهادات CA الوسيطة، والتي يتم بدورها توقيعها بواسطة شهادات أخرى، لتصل في النهاية إلى نقطة ارتكاز موثوقة .

تم تعريف X.509 من قبل "قطاع التقييس" التابع للاتحاد الدولي للاتصالات ( ITU-T SG17 ) ، في مجموعة دراسة ITU-T 17، وهو يعتمد على تدوين بناء الجملة المجرد واحد (ASN.1)، وهو معيار آخر من معايير ITU-T.

التاريخ والاستخدام

صدرت شهادة X.509 مبدئيًا في 3 يوليو 1988، بالتزامن مع شهادة X.500 . تمثلت مهمتها الأولى في توفير وصول آمن للمستخدمين إلى مصادر المعلومات وتجنب هجمات الوسيط المشفرة . وتعتمد هذه الشهادة على نظام هرمي صارم لهيئات إصدار الشهادات. وهذا يختلف عن نماذج شبكة الثقة ، مثل PGP ، حيث يمكن لأي شخص (وليس فقط هيئات إصدار الشهادات الخاصة) التوقيع على شهادات المفاتيح الخاصة بالآخرين، وبالتالي التصديق على صحتها.

يتضمن الإصدار الثالث من معيار X.509 مرونةً لدعم بنيات أخرى مثل الجسور والشبكات . [ 2 ] ويمكن استخدامه في شبكة ثقة من نوع نظير إلى نظير، شبيهة بشبكة OpenPGP ، ولكن نادرًا ما استُخدم بهذه الطريقة حتى عام 2004.لم يُطبّق نظام X.500 إلا من قِبل الدول ذات السيادة لأغراض تنفيذ معاهدات تبادل معلومات الهوية الحكومية، وقد قام فريق عمل البنية التحتية للمفتاح العام (X.509) التابع لـ IETF بتكييف المعيار مع بنية الإنترنت الأكثر مرونة. في الواقع، يُشير مصطلح شهادة X.509 عادةً إلى شهادة PKIX وملف تعريف قائمة إبطال الشهادات (CRL) الخاصين بمعيار شهادة X.509 الإصدار 3، كما هو مُحدد في RFC 5280 ، والذي يُعرف اختصارًا بـ PKIX للبنية التحتية للمفتاح العام (X.509) . [ 3 ] 

كانت إحدى المشكلات المبكرة المتعلقة بالبنية التحتية للمفاتيح العامة (PKI) وشهادات X.509 هي مشكلة "أي دليل" المعروفة. تكمن المشكلة في أن العميل لا يعرف من أين يحصل على الشهادات الوسيطة المفقودة لأن دليل X.509 العام لم يكن موجودًا. تم التخفيف من حدة هذه المشكلة عن طريق تضمين جميع الشهادات الوسيطة في الطلب. على سبيل المثال، كانت خوادم الويب القديمة ترسل شهادة خادم الويب فقط إلى العميل. أما العملاء الذين يفتقرون إلى شهادة المرجع المصدق الوسيط أو إلى معرفة مكان العثور عليها، فقد فشلوا في إنشاء مسار صالح من المرجع المصدق إلى شهادة الخادم. ولتجاوز هذه المشكلة، ترسل خوادم الويب الآن جميع الشهادات الوسيطة مع شهادة خادم الويب. [ 4 ]

بينما يشير مصطلح PKIX إلى معيار البنية التحتية للمفاتيح العامة (PKI) الخاص بفريق هندسة الإنترنت (IETF)، توجد العديد من معايير PKI الأخرى ذات سياسات مختلفة. على سبيل المثال، تمتلك حكومة الولايات المتحدة الأمريكية معيار PKI خاص بها بسياساتها الخاصة، وكذلك منتدى CA/Browser Forum. يُعد معيار PKI الخاص بحكومة الولايات المتحدة الأمريكية مرجعًا ضخمًا يتجاوز 2500 صفحة. إذا اختلف معيار PKI الخاص بمؤسسة ما اختلافًا كبيرًا عن معيار IETF أو CA/Browser Forum، فإنها تُخاطر بفقدان التوافق مع الأدوات الشائعة مثل متصفحات الويب و cURL و Wget . على سبيل المثال، إذا كان معيار PKI ينص على إصدار الشهادات يوم الاثنين فقط، فلن تُطبّق الأدوات الشائعة مثل cURL وWget هذه السياسة، ولن تسمح بإصدار شهادة يوم الثلاثاء. [ 4 ]

الشهادات

تربط شهادات X.509 هوية المستخدم بمفتاح عام باستخدام توقيع رقمي. في نظام X.509، يوجد نوعان من الشهادات: شهادة هيئة التصديق (CA) وشهادة الكيان النهائي. يمكن لشهادة هيئة التصديق إصدار شهادات أخرى. تُسمى شهادة هيئة التصديق ذات المستوى الأعلى والموقعة ذاتيًا أحيانًا بشهادة هيئة التصديق الجذرية. أما شهادات هيئة التصديق الأخرى فتُسمى شهادات هيئة التصديق الوسيطة أو الفرعية. تُحدد شهادة الكيان النهائي هوية المستخدم، سواء كان شخصًا أو مؤسسة أو شركة. لا يمكن لشهادة الكيان النهائي إصدار شهادات أخرى. تُسمى شهادة الكيان النهائي أحيانًا بشهادة فرعية، حيث لا يمكن إصدار شهادات أخرى تحتها.

تطلب أي منظمة ترغب في الحصول على شهادة موقعة هذه الشهادة من جهة إصدار الشهادات باستخدام بروتوكول مثل طلب توقيع الشهادة (CSR) أو بروتوكول تسجيل الشهادة البسيط (SCEP) أو بروتوكول إدارة الشهادات (CMP) . تقوم المنظمة أولاً بإنشاء زوج من المفاتيح ، مع الحفاظ على سرية المفتاح الخاص واستخدامه لتوقيع طلب توقيع الشهادة. يحتوي طلب توقيع الشهادة على معلومات تُحدد هوية مقدم الطلب ومفتاحه العام الذي يُستخدم للتحقق من توقيع طلب توقيع الشهادة، بالإضافة إلى الاسم المميز (DN) الفريد للشخص أو المنظمة أو الشركة. قد يُرفق بطلب توقيع الشهادة بيانات اعتماد أو إثباتات هوية أخرى تطلبها جهة إصدار الشهادات.

سيتم التحقق من صحة طلب توقيع الشهادة (CSR) باستخدام هيئة التسجيل (RA)، ثم ستصدر هيئة التصديق شهادة تربط مفتاحًا عامًا باسم مميز محدد . عادةً ما تكون هيئة التسجيل وهيئة التصديق وحدتين تجاريتين منفصلتين بموجب مبدأ فصل المهام للحد من مخاطر الاحتيال.

يمكن توزيع شهادات الجذر الموثوقة للمؤسسة على جميع الموظفين لتمكينهم من استخدام نظام البنية التحتية للمفاتيح العامة (PKI) الخاص بالشركة. تأتي متصفحات مثل إنترنت إكسبلورر ، وفايرفوكس ، وأوبرا ، وسفاري ، وكروم مزودة بمجموعة محددة مسبقًا من شهادات الجذر، مما يسمح بتفعيل شهادات SSL الصادرة عن هيئات إصدار الشهادات الرئيسية فورًا؛ في الواقع، يحدد مطورو المتصفحات هيئات إصدار الشهادات الموثوقة لمستخدمي المتصفحات. على سبيل المثال، يوفر فايرفوكس ملف CSV و/أو HTML يحتوي على قائمة بهيئات إصدار الشهادات المضمنة. [ 7 ]

يتضمن كل من X.509 و RFC 5280 معايير لتطبيقات قوائم إبطال الشهادات (CRL). ومن الطرق الأخرى المعتمدة من قبل IETF للتحقق من صحة الشهادة بروتوكول حالة الشهادة عبر الإنترنت (OCSP). وقد فعّل متصفح Firefox 3.0 التحقق من OCSP افتراضيًا، وكذلك فعلت إصدارات Windows بدءًا من Vista والإصدارات الأحدث. [ 8 ] 

هيكل الشهادة

يتم التعبير عن البنية المتوقعة من قبل المعايير بلغة رسمية، وهي تدوين بناء الجملة المجرد واحد (ASN.1).

بنية الشهادة الرقمية X.509 v3 هي كما يلي:

  • شهادة
    • رقم الإصدار
    • رقم سري
    • معرّف خوارزمية التوقيع
    • اسم الجهة المصدرة
    • فترة الصلاحية
      • ليس قبل
      • ليس بعد
    • اسم الموضوع
    • معلومات المفتاح العام للموضوع
      • خوارزمية المفتاح العام
      • المفتاح العام للموضوع
    • المعرّف الفريد للجهة المصدرة (اختياري)
    • المعرّف الفريد للموضوع (اختياري)
    • الإضافات (اختيارية)
      • ...
  • خوارزمية توقيع الشهادة
  • توقيع الشهادة

حقل "الامتدادات"، إن وُجد، هو عبارة عن سلسلة من امتدادات الشهادة، واحد أو أكثر. [ 9 ] : §4.1.2.9: الامتدادات. لكل امتداد معرّف فريد خاص به، يُعبّر عنه بمعرّف الكائن (OID) ، وهو عبارة عن مجموعة من القيم، بالإضافة إلى مؤشر حرج أو غير حرج. يجب على النظام الذي يستخدم الشهادة رفضها إذا صادف امتدادًا حرجًا لا يتعرف عليه، أو امتدادًا حرجًا يحتوي على معلومات لا يمكنه معالجتها. يمكن تجاهل الامتداد غير الحرج إذا لم يتم التعرف عليه، ولكن يجب معالجته إذا تم التعرف عليه. [ 9 ] : §4.2: امتدادات الشهادة

تم تحديد بنية الإصدار 1 في RFC 1422 . 

التنسيق الداخلي لمعرفات المصدر والموضوع الفريدة المحددة في X.520 الدليل: توصية أنواع السمات المحددة.

أدخلت هيئة تقييس الاتصالات التابعة للاتحاد الدولي للاتصالات (ITU-T) معرّفات فريدة للجهة المصدرة والجهة الخاضعة للرقابة في الإصدار الثاني، وذلك للسماح بإعادة استخدام اسم الجهة المصدرة أو الجهة الخاضعة للرقابة بعد فترة من الزمن. ومن أمثلة إعادة الاستخدام، إفلاس هيئة إصدار الشهادات (CA) وحذف اسمها من القائمة العامة للدولة. بعد فترة، قد تُسجّل هيئة إصدار شهادات أخرى تحمل الاسم نفسه، حتى وإن لم تكن مرتبطة بالأولى. مع ذلك، توصي فرقة عمل هندسة الإنترنت (IETF) بعدم إعادة استخدام أسماء الجهات المصدرة أو الجهات الخاضعة للرقابة. لذا، لا يُستخدم الإصدار الثاني على نطاق واسع في الإنترنت.

تم إدخال الإضافات في الإصدار 3. يمكن لهيئة إصدار الشهادات استخدام الإضافات لإصدار شهادة لغرض محدد فقط (على سبيل المثال، فقط لتوقيع الكائنات الرقمية ).

في جميع الإصدارات، يجب أن يكون الرقم التسلسلي فريدًا لكل شهادة صادرة عن جهة إصدار شهادات محددة (كما هو مذكور في RFC 5280 ). 

ملحقات تُعلم باستخدام محدد للشهادة

يُحدد RFC 5280 (والإصدارات السابقة له) عددًا من امتدادات الشهادات التي تُشير إلى كيفية استخدامها. معظم هذه الامتدادات عبارة عن أقواس مُشتقة من مُعرّف الكائن (OID). ومن أكثرها شيوعًا، والمُعرّفة في القسم 4.2.1، ما يلي: joint-iso-ccitt(2) ds(5) id-ce(29)

  • القيود الأساسية، { id-ce 19 }[ 9 ] : §4.2.1.9 تُستخدم لتحديد ما إذا كانت الشهادة شهادة صادرة عن جهة مصدقة (CA) ومؤهلة لتصديق أو إصدار شهادات أخرى. يمكن تصنيف القيد على أنه حرج. في حال تصنيف القيد على أنه حرج، يجب على الوكيل عدم معالجة الشهادة إذا لم يفهم القيد. يمكن للوكيل الاستمرار في معالجة قيد غير حرج لا يفهمه.
  • استخدام المفتاح، { id-ce 15 }[ 9 ] : يوفر القسم 4.2.1.3 خريطة بتات تحدد العمليات التشفيرية التي يمكن تنفيذها باستخدام المفتاح العام الموجود في الشهادة؛ على سبيل المثال، يمكن أن يشير إلى أنه يجب استخدام المفتاح للتوقيعات وليس للتشفير.
  • الاستخدام الموسّع للمفتاح { id-ce 37 }، [ 9 ] : يُستخدم القسم 4.2.1.12{ id-pkix 3 1 } ، عادةً في شهادة فرعية، للإشارة إلى الغرض من المفتاح العام المُضمّن في الشهادة. يحتوي هذا القسم على قائمة بمعرفات الكائنات (OIDs)، يشير كل منها إلى استخدام مسموح به. على سبيل المثال، يشير إلى أنه يمكن استخدام المفتاح على جانب الخادم في اتصال TLS أو SSL؛ { id-pkix 3 4 }ويشير إلى أنه يمكن استخدام المفتاح لتأمين البريد الإلكتروني.

بشكل عام، عند استخدام RFC 5280 ، إذا كانت الشهادة تحتوي على عدة امتدادات تقيّد استخدامها، فيجب استيفاء جميع القيود ليكون استخدامها مناسبًا. يقدم RFC مثالًا محددًا لشهادة تحتوي على كل من keyUsage و extendedKeyUsage: في هذه الحالة، يجب معالجة كليهما، ولا يمكن استخدام الشهادة إلا إذا كان كلا الامتدادين متسقين في تحديد استخدام الشهادة. على سبيل المثال، يستخدم NSS كلا الامتدادين لتحديد استخدام الشهادة. [ 10 ] 

شهادات التحقق الموسع

تُصدر هيئات التصديق العاملة ضمن إطار البنية التحتية للمفاتيح العامة (PKI) التابعة لمنتدى هيئات التصديق/المتصفحات شهادات بمستويات تحقق متفاوتة. توفر عمليات التحقق المختلفة مستويات متباينة من الضمانات بأن الشهادة تمثل ما يُفترض أن تمثله. على سبيل المثال، يمكن التحقق من خادم ويب عند أدنى مستوى من الضمانات باستخدام بريد إلكتروني يُسمى التحقق من النطاق (DV) . أو يمكن التحقق من خادم ويب عند مستوى أعلى من الضمانات باستخدام أساليب أكثر تفصيلاً تُسمى التحقق الموسع (EV) .

عمليًا، تعني شهادة التحقق من النطاق (DV) إصدار شهادة لنطاق معين example.comبعد إثبات ملكية هذا النطاق، مثلاً بالرد على بريد إلكتروني مُرسل إليه webmaster@example.com. أما شهادة التحقق الموسع (EV) فتعني إصدار شهادة لنطاق معين example.com، وتكون شركة مثل Example, LLC هي مالكة النطاق، وقد تم التحقق من هذه الملكية بموجب عقد التأسيس .

لا يضيف التحقق الموسع أي ضوابط أمان إضافية ، لذا فإن إعداد القناة الآمنة باستخدام شهادة EV ليس "أقوى" من إعداد القناة باستخدام مستوى مختلف من التحقق مثل DV.

يتم الإشارة إلى التحقق الموسع في الشهادة باستخدام امتداد X.509 الإصدار 3. تستخدم كل جهة مصدقة (CA ) مُعرّف كائن (OID) مختلفًا لتأكيد التحقق الموسع. لا يوجد مُعرّف كائن واحد للإشارة إلى التحقق الموسع، مما يُعقّد برمجة وكيل المستخدم . يجب أن يحتوي كل وكيل مستخدم على قائمة بمُعرّفات الكائنات التي تُشير إلى التحقق الموسع.

يعترف نظام البنية التحتية للمفاتيح العامة (PKI) التابع لمنتدى CA/Browser بالتحقق الموسع. أما أنظمة PKI الأخرى، مثل نظام البنية التحتية للمفاتيح العامة للإنترنت (PKIX)، فلا تُولي أي اهتمام خاص للتحقق الموسع. وتتعامل الأدوات التي تستخدم سياسات PKIX، مثل cURL وWget، مع شهادة EV كأي شهادة أخرى. حتى عام 2019، كانت العديد من المتصفحات تُظهر للمستخدم تنبيهًا مرئيًا واضحًا في شريط عنوان URL للإشارة إلى أن الموقع يُقدم شهادة EV. بعد دراسات وتقارير أظهرت عدم فعالية شهادات EV واستغلالها من قِبل المجرمين لحقن عناصر مُضللة في واجهة المستخدم الرئيسية للمتصفح، أزالت جميع المتصفحات الرئيسية التنبيه المرئي البارز السابق من شريط عنوان URL. [ 11 ] [ 12 ] [ 13 ] وبدلًا من ذلك، ومنذ عام 2019، تُخفي متصفحات مثل Chromium و Firefox معلومات جهة إصدار شهادة EV في قوائم فرعية، حيث تُعرض بطريقة محايدة، دون أي تمييز أو إشارة إلى التحقق الموسع.

يذكر خبير الأمن بيتر غوتمان أن هيئات إصدار الشهادات (CAs) ابتكرت شهادات التحقق الموسع (EV) لاستعادة مستويات الربح بعد أن أدى التنافس المحموم على خفض الأسعار إلى تراجعها. خلال هذا التنافس، خفضت هيئات إصدار الشهادات الأسعار لجذب المستهلكين لشراء شهاداتها. ونتيجة لذلك، انخفضت الأرباح، وتراجعت هيئات إصدار الشهادات عن مستوى التحقق الذي كانت تجريه إلى درجة أنه لم يعد هناك أي ضمانات تقريبًا على الشهادة. [ 4 ]

امتدادات أسماء ملفات الشهادات

توجد عدة امتدادات شائعة الاستخدام لأسماء ملفات شهادات X.509. بعض هذه الامتدادات تُستخدم أيضاً لبيانات أخرى مثل المفاتيح الخاصة.

  • .pem– ( البريد الإلكتروني المعزز بالخصوصية ) شهادة DER مشفرة بصيغة Base64 ، مضمنة بين-----BEGIN CERTIFICATE----------END CERTIFICATE-----
  • .cer، .crt، – عادة ما تكون في شكل DER.der ثنائي ، ولكن الشهادات المشفرة بـ Base64 شائعة أيضًا (انظر أعلاه).pem
  • .p8المفتاح الخاص المُصدَّر كما هو مُحدد في معيار PKCS#8 . قد يكون بصيغة DER أو PEM ويبدأ بـ . يبدأ المفتاح المُشفَّر بـ .p8eوقد يكون له الامتداد ..pk8-----BEGIN PRIVATE KEY----------BEGIN ENCRYPTED PRIVATE KEY-----.p8e
  • .p10– PKCS#10.csr هو طلب توقيع شهادة (CSR). يبدأ بصيغة PEM بـ . يتم إنشاء هذه الطلبات لتقديمها إلى هيئات إصدار الشهادات (CA). تتضمن تفاصيل أساسية للشهادة المطلوبة مثل الاسم الشائع (/CN)، والموضوع، والمنظمة، والولاية، والبلد، بالإضافة إلى المفتاح العام للشهادة المراد توقيعها. يتم توقيع هذه الطلبات من قبل هيئة إصدار الشهادات، ثم تُعاد الشهادة. الشهادة المُعادة هي الشهادة العامة (التي تتضمن المفتاح العام فقط دون المفتاح الخاص)، والتي يمكن أن تكون بصيغتين، ولكنها عادةً ما تكون بصيغة . [ 14 ]-----BEGIN CERTIFICATE REQUEST-----.p7r
  • .p7r– رد PKCS#7 على طلب توقيع الشهادة (CSR). يحتوي على الشهادة الموقعة حديثًا، وشهادة هيئة إصدار الشهادات الخاصة.
  • .p7s– التوقيع الرقمي PKCS#7 . قد يحتوي على الملف أو الرسالة الأصلية الموقعة. يُستخدم في S/MIME لتوقيع البريد الإلكتروني. مُعرّف في RFC 2311.
  • .p7m– رسالة PKCS#7 (SignedData, EnvelopedData) مثال على ملف مشفر ("مغلف") أو رسالة أو خطاب بريد إلكتروني MIME. مُعرّفة في RFC 2311.
  • .p7c– بنية SignedData المتدهورة في معيار PKCS#7، والتي تحتوي على "شهادات فقط"، بدون أي بيانات للتوقيع. مُعرّفة في RFC 2311.
  • .p7b.keystoreبنية PKCS#7 SignedData بدون بيانات، فقط حزمة شهادات و/أو قوائم إبطال الشهادات (نادرًا)، ولكن بدون مفتاح خاص. تستخدم صيغة DER أو BER أو PEM التي تبدأ بـ -----BEGIN PKCS7-----. هذا هو التنسيق الذي يستخدمه نظام Windows لتبادل الشهادات. يدعمه Java، ولكن غالبًا ما يستخدم امتدادًا .keystoreبدلاً من ذلك. على عكس .pemشهادات النمط، يوفر هذا التنسيق طريقة محددة لتضمين شهادات مسار الشهادة.
  • .p12قد يحتوي ملف PKCS#12 على شهادة (شهادات) (عامة) ومفاتيح خاصة (محمية بكلمة مرور) في ملف واحد. أما ملف PFX .pfxالخاص بتبادل المعلومات الشخصية ، وهو الإصدار السابق لملف PKCS#12 (يحتوي عادةً على بيانات بتنسيق PKCS#12، على سبيل المثال ، مع ملفات PFX التي تم إنشاؤها في IIS )..pkcs12.pfx
  • .crl– قائمة إبطال الشهادات (CRL). تقوم جهات إصدار الشهادات بإصدار هذه القوائم كوسيلة لإلغاء صلاحية الشهادات قبل انتهاء صلاحيتها.

يُعدّ PKCS#7 معيارًا لتوقيع البيانات أو تشفيرها (ويُسمى رسميًا "تغليفها"). وبما أن الشهادة مطلوبة للتحقق من صحة البيانات الموقعة، فمن الممكن تضمينها في بنية SignedData.

سلاسل الشهادات والتصديق المتبادل

سلسلة الشهادات (المعروفة أيضًا باسم "مسار الشهادة" [ 9 ] : §3.2 ) هي قائمة من الشهادات (تبدأ عادةً بشهادة كيان نهائي) متبوعة بشهادة واحدة أو أكثر من شهادات هيئة التصديق (عادةً ما تكون الأخيرة شهادة موقعة ذاتيًا)، مع الخصائص التالية:

  1. يتطابق مُصدر كل شهادة (باستثناء الشهادة الأخيرة) مع موضوع الشهادة التالية في القائمة.
  2. يتم توقيع كل شهادة (باستثناء الأخيرة) بواسطة المفتاح السري المقابل للشهادة التالية في السلسلة (أي يمكن التحقق من توقيع شهادة واحدة باستخدام المفتاح العام الموجود في الشهادة التالية).
  3. الشهادة الأخيرة في القائمة هي شهادة موثوقة : وهي شهادة تثق بها لأنها تم تسليمها إليك من خلال إجراء موثوق به.

تُستخدم سلاسل الشهادات للتحقق من أن المفتاح العام (PK) الموجود في الشهادة المستهدفة (الشهادة الأولى في السلسلة) والبيانات الأخرى الموجودة فيها تعود فعليًا إلى صاحبها. وللتأكد من ذلك، يتم التحقق من التوقيع على الشهادة المستهدفة باستخدام المفتاح العام الموجود في الشهادة التالية، والتي بدورها يتم التحقق من توقيعها باستخدام الشهادة التي تليها، وهكذا حتى الوصول إلى الشهادة الأخيرة في السلسلة. وبما أن الشهادة الأخيرة تُعدّ مرجعًا موثوقًا، فإن الوصول إليها بنجاح يُثبت أن الشهادة المستهدفة جديرة بالثقة.

الوصف الوارد في الفقرة السابقة هو عرض مبسط لعملية التحقق من صحة مسار الشهادة ، [ 9 ] : §6 والتي تتضمن عمليات تحقق إضافية، مثل التحقق من تواريخ الصلاحية على الشهادات، والبحث عن قوائم إبطال الشهادات ، وما إلى ذلك.

مثال 1: المصادقة المتبادلة بين بنيتين للمفاتيح العامة
مثال 2: تجديد شهادة المرجع المصدق

يمكن أن تكون الشهادة الواحدة جزءًا من سلاسل شهادات مختلفة تمامًا (وجميعها صالحة). ويعود ذلك إلى إمكانية إصدار عدة شهادات من جهات إصدار الشهادات لنفس الموضوع والمفتاح العام، ولكن بتوقيعات مختلفة (من جهات إصدار شهادات مختلفة أو بمفاتيح خاصة مختلفة من نفس جهة الإصدار). لذا، على الرغم من أن شهادة X.509 الواحدة لا يمكن أن تحمل إلا جهة إصدار واحدة وتوقيعًا واحدًا من جهة إصدار الشهادات، إلا أنه يمكن ربطها بشكل صحيح بأكثر من شهادة، مما يُنشئ سلاسل شهادات مختلفة تمامًا. وهذا أمر بالغ الأهمية للمصادقة المتبادلة بين البنى التحتية للمفاتيح العامة (PKIs) والتطبيقات الأخرى. [ 15 ] انظر الأمثلة التالية:

أمثلة

في هذه الرسوم البيانية:

  • يمثل كل مربع شهادة، مع وضع موضوعها بخط عريض.
  • A → B تعني "تم توقيع A بواسطة B" (أو، بتعبير أدق، "تم توقيع A بواسطة المفتاح السري المقابل للمفتاح العام الموجود في B").
  • تحتوي الشهادات ذات اللون نفسه (التي ليست بيضاء/شفافة) على نفس المفتاح العام.

مثال 1: المصادقة المتبادلة على مستوى سلطة التصديق الجذرية (CA) بين بنيتين للمفاتيح العامة (PKI).

لضمان موثوقية شهادات المستخدمين الموجودة في البنية التحتية للمفاتيح العامة 2 (مثل "المستخدم 2") من قِبل البنية التحتية للمفاتيح العامة 1، يقوم مركز المصادقة 1 بإنشاء شهادة (cert2.1) تحتوي على المفتاح العام لمركز المصادقة 2. [ 16 ] الآن، تشترك كل من "cert2" و"cert2.1" (باللون الأخضر) في نفس الموضوع والمفتاح العام، لذا توجد سلسلتان صالحتان لشهادة cert2.2 (المستخدم 2): "cert2.2 → cert2" و"cert2.2 → cert2.1 → cert1".

وبالمثل، يمكن لـ CA2 إنشاء شهادة (cert1.1) تحتوي على المفتاح العام لـ CA1 بحيث يتم الوثوق بشهادات المستخدم الموجودة في PKI 1 (مثل "المستخدم 1") بواسطة PKI 2.

مثال 2: تجديد شهادة المرجع المصدق

فهم بناء مسار التصديق (ملف PDF) . منتدى البنية التحتية للمفاتيح العامة. سبتمبر 2002. مؤرشف من الأصل (ملف PDF) بتاريخ4 فبراير 2019. تم الاطلاع عليه بتاريخ 7 نوفمبر 2014. للسماح بالانتقال السلس من زوج مفاتيح التوقيع القديم إلى زوج مفاتيح التوقيع الجديد، يجب على جهة إصدار الشهادات إصدار شهادة تحتوي على المفتاح العام القديم موقعًا بواسطة مفتاح التوقيع الخاص الجديد، وشهادة أخرى تحتوي على المفتاح العام الجديد موقعًا بواسطة مفتاح التوقيع الخاص القديم. كلتا الشهادتين ذاتيتان الإصدار، لكنهما غير موقعتين ذاتيًا . تجدر الإشارة إلى أن هاتين الشهادتين تُضافان إلى الشهادتين الموقعتين ذاتيًا (واحدة قديمة وأخرى جديدة).

بما أن كلاً من الشهادة cert1 والشهادة cert3 تحتويان على نفس المفتاح العام (القديم)، فهناك سلسلتان صالحتان للشهادات للشهادة cert5: "cert5 → cert1" و"cert5 → cert3 → cert2"، وينطبق الأمر نفسه على الشهادة cert6. وهذا يسمح بأن تكون شهادات المستخدم القديمة (مثل cert5) والشهادات الجديدة (مثل cert6) موثوقة بغض النظر عن نوعها من قبل أي طرف يمتلك إما شهادة المرجع المصدق الجذر الجديدة أو القديمة كمرجع موثوق به أثناء الانتقال إلى مفاتيح المرجع المصدق الجديدة. [ 17 ]

نماذج شهادات X.509

هذا مثال على شهادة X.509 مُفكّكة التشفير، استُخدمت سابقًا من قِبل موقع wikipedia.org والعديد من مواقع ويكيبيديا الأخرى. أصدرتها شركة GlobalSign ، كما هو مُبيّن في حقل "المُصدر". يصف حقل "الموضوع" ويكيبيديا كمنظمة، بينما يصف حقل "اسم الموضوع البديل" (SAN) لنظام أسماء النطاقات (DNS) أسماء المضيفين التي يُمكن استخدامها معها. يحتوي حقل "معلومات المفتاح العام للموضوع" على مفتاح ECDSA عام، بينما تم إنشاء التوقيع في الأسفل باستخدام مفتاح RSA الخاص بشركة GlobalSign. (التوقيعات في هذه الأمثلة مُختصرة).

شهادة الكيان النهائي

للتحقق من صحة شهادة الكيان النهائي هذه، يحتاج المرء إلى شهادة وسيطة تتطابق مع مُصدرها ومعرّف مفتاح السلطة:

جهة الإصدارC=BE، O=GlobalSign nv-sa، CN=GlobalSign Organization Validation CA - SHA256 - G2
معرّف مفتاح السلطة96:DE:61:F1:BD:1C:16:29:53:1C:C0:CC:7D:3B:83:00:40:E6:1A:7C

في اتصال TLS، يقوم الخادم المُهيأ بشكل صحيح بتوفير الشهادة الوسيطة كجزء من عملية المصافحة. ومع ذلك، من الممكن أيضًا استرداد الشهادة الوسيطة عن طريق جلب عنوان URL الخاص بـ "CA Issuers" من شهادة الكيان النهائي.

شهادة متوسطة

هذا مثال على شهادة وسيطة تابعة لهيئة إصدار الشهادات . وقّعت هذه الشهادة شهادة الكيان النهائي المذكورة أعلاه، ووقّعتها شهادة الجذر المذكورة أدناه. لاحظ أن حقل الموضوع في هذه الشهادة الوسيطة يطابق حقل المُصدر في شهادة الكيان النهائي التي وقّعتها. كذلك، يتطابق حقل "معرّف مفتاح الموضوع" في الشهادة الوسيطة مع حقل "معرّف مفتاح الهيئة" في شهادة الكيان النهائي.

شهادة الجذر

هذا مثال على شهادة جذر موقعة ذاتيًا تمثل جهة إصدار شهادات . حقلا المُصدر والموضوع متطابقان، ويمكن التحقق من صحة توقيعها باستخدام مفتاحها العام. يجب أن ينتهي التحقق من سلسلة الثقة هنا. إذا كان برنامج التحقق يمتلك شهادة الجذر هذه في مخزن الثقة الخاص به ، فيمكن اعتبار شهادة الكيان النهائي موثوقة للاستخدام في اتصال TLS. وإلا، تُعتبر شهادة الكيان النهائي غير موثوقة.

الشهادة: [ 18 ] بيانات: الإصدار: 3 (0x2) رقم سري: 04:00:00:00:00:01:15:4ب:5أ:c3:94 خوارزمية التوقيع: sha1WithRSAEncryption الجهة المصدرة: C=BE، O=GlobalSign nv-sa، OU=Root CA، CN=GlobalSign Root CA صحة ليس قبل: 1 سبتمبر 1998 الساعة 12:00:00 بتوقيت غرينتش ليس بعد: 28 يناير 2028 الساعة 12:00:00 بتوقيت غرينتش الموضوع: C=BE، O=GlobalSign nv-sa، OU=Root CA، CN=GlobalSign Root CA معلومات المفتاح العام للموضوع: خوارزمية المفتاح العام: تشفير RSA المفتاح العام: (2048 بت) معامل: 00:da:0e:e6:99:8d:ce:a3:e3:4f:8a:7e:fb:f1:8b: ... الأس: 65537 (0x10001) ملحقات X509v3: استخدام مفتاح X509v3: هام علامة الشهادة، علامة CRL القيود الأساسية لـ X509v3: حرجة كاليفورنيا: صحيح معرّف مفتاح الموضوع X509v3: 60:7B:66:1A:45:0D:97:CA:89:50:2F:7D:04:CD:34:A8:FF:FC:FD:4B خوارزمية التوقيع: sha1WithRSAEncryption d6:73:e7:7c:4f:76:d0:8d:bf:ec:ba:a2:be:34:c5:28:32:b5: ...

حماية

توجد العديد من المنشورات حول مشاكل البنية التحتية للمفاتيح العامة (PKI) من تأليف بروس شناير وبيتر غوتمان وغيرهما من خبراء الأمن. [ 19 ] [ 20 ] [ 21 ]

نقاط الضعف المعمارية

  • استخدام قوائم الحظر للشهادات غير الصالحة (باستخدام قوائم إبطال الشهادات وبروتوكول حالة الشهادة عبر الإنترنت )،
    • إذا لم يثق العميل بالشهادات إلا عند توفر قوائم إبطال الشهادات (CRLs)، فإنه يفقد ميزة العمل دون اتصال بالإنترنت التي تجعل البنية التحتية للمفاتيح العامة (PKI) جذابة. لذا، يثق معظم العملاء بالشهادات حتى في حال عدم توفر قوائم إبطال الشهادات، ولكن في هذه الحالة، يمكن للمهاجم الذي يتحكم بقناة الاتصال تعطيل قوائم إبطال الشهادات. وقد صرّح آدم لانغلي من جوجل بأن فحوصات قوائم إبطال الشهادات ذات الفشل البرمجي أشبه بحزام أمان يعمل بكفاءة إلا عند وقوع حادث. [ 22 ]
  • تُعتبر قوائم الانتظار ذات السعة الكبيرة خيارًا سيئًا بشكل ملحوظ نظرًا لأحجامها الكبيرة وأنماط توزيعها المعقدة.
  • دلالات OCSP الغامضة وانعدام حالة الإلغاء التاريخية،
  • لم يتم التطرق إلى مسألة إلغاء الشهادات الجذرية.
  • مشكلة التجميع : يتم دمج بيانات الهوية (التحقق من الهوية باستخدام مُعرّف)، وبيانات السمات (إرسال مجموعة من السمات المُدققة)، وبيانات السياسات في حاوية واحدة. وهذا يُثير مشاكل تتعلق بالخصوصية، ورسم خرائط السياسات، والصيانة.
  • مشكلة التفويض : لا تستطيع هيئات إصدار الشهادات تقنيًا منع هيئات إصدار الشهادات التابعة لها من إصدار شهادات خارج نطاق أسماء أو مجموعة سمات محدودة؛ فهذه الميزة في معيار X.509 غير مستخدمة. ولذلك، يوجد عدد كبير من هيئات إصدار الشهادات على الإنترنت، ويُعدّ تصنيفها وتصنيف سياساتها مهمة بالغة الصعوبة. كما لا يمكن التعامل مع تفويض السلطة داخل المؤسسة على الإطلاق، كما هو الحال في الممارسات التجارية الشائعة. [ 23 ]
  • مشكلة الاتحاد : سلاسل الشهادات الناتجة عن هيئات إصدار الشهادات الفرعية، وهيئات إصدار الشهادات الوسيطة، والتوقيع المتبادل، تجعل عملية التحقق معقدة ومكلفة من حيث وقت المعالجة. قد تكون دلالات التحقق من المسار غامضة. التسلسل الهرمي مع طرف ثالث موثوق به هو النموذج الوحيد. وهذا غير ملائم عندما تكون علاقة ثقة ثنائية قائمة بالفعل.
  • إن إصدار شهادة التحقق الموسع (EV) لاسم مضيف لا يمنع إصدار شهادة تحقق أقل صلاحية لنفس اسم المضيف، مما يعني أن مستوى التحقق الأعلى لشهادة EV لا يحمي من هجمات الوسيط. [ 24 ]

مشاكل مع جهات إصدار الشهادات

  • غالباً ما يلجأ الشخص أو المؤسسة التي تشتري شهادة إلى أقل جهات إصدار الشهادات تكلفة. ونتيجةً لذلك، خفضت هذه الجهات أسعارها وألغت عمليات التحقق المكلفة، فيما يُعرف بـ" سباق نحو القاع" . تُعالج شهادات التحقق الموسع (EV) جزئياً هذا السباق ، إلا أن قيمتها الأمنية، في نظر خبراء الأمن، تتضاءل. [ 25 ] ووفقاً لبيتر غوتمان ، لا تُضيف شهادات EV أي ضوابط أمنية إضافية، بل تُعيد أرباح جهات إصدار الشهادات إلى مستوياتها قبل "سباق القاع"، وذلك بالسماح لها بفرض رسوم أعلى على خدمة كان ينبغي عليها تقديمها منذ البداية. [ 4 ] كما تُعالج جهات إصدار الشهادات، مثل Let's Encrypt، هذا السباق جزئياً بتوفيرها شهادات مجانية. [ 26 ] وقد أصبحت Let's Encrypt أكبر مزود للشهادات، حيث يستخدمها أكثر من 500 مليون موقع إلكتروني. [ 27 ] [ 28 ]
  • تحاول جهات إصدار الشهادات رفض جميع الضمانات تقريبًا للمستخدم والأطراف المعتمدة في بيان ممارسات إصدار الشهادات (CPS) . على سبيل المثال، تنص شركة آبل في بيان ممارسات إصدار الشهادات الخاص بها على ما يلي: "إلى الحد الذي يسمح به القانون المعمول به، فإن اتفاقيات المشتركين، إن وجدت، تُخلي مسؤولية آبل عن الضمانات، بما في ذلك أي ضمان لقابلية التسويق أو الملاءمة لغرض معين". [ 29 ]
  • وفقًا لبيتر غوتمان، "يستخدم المستخدمون بروتوكول طلب شهادة غير محدد للحصول على شهادة يتم نشرها في موقع غير واضح في دليل غير موجود بدون أي وسيلة حقيقية لإلغائها" [ 21 ].
  • كغيرها من الشركات، تخضع هيئات إصدار الشهادات للقوانين السارية في نطاق اختصاصها، وقد تُجبر قانونًا على المساس بمصالح عملائها ومستخدميها. كما استغلت أجهزة الاستخبارات شهادات مزورة صادرة عن طريق اختراق هيئات إصدار الشهادات بطرق غير قانونية، مثل DigiNotar ، لتنفيذ هجمات الوسيط . ومن الأمثلة الأخرى طلب إلغاء ترخيص هيئة إصدار الشهادات التابعة للحكومة الهولندية، استنادًا إلى قانون هولندي صدر عام ٢٠١٨، يمنح صلاحيات جديدة لأجهزة الاستخبارات والأمن الهولندية [ ٣٠ ].

مشاكل التنفيذ

تعاني التطبيقات من عيوب في التصميم، وأخطاء برمجية، وتفسيرات مختلفة للمعايير، وعدم توافق بين المعايير المختلفة. ومن هذه المشاكل:

  • تقوم العديد من التطبيقات بإيقاف التحقق من الإلغاء:
    • ونظراً إلى اعتبارها عائقاً، لا يتم تطبيق السياسات.
    • إذا تم تفعيلها في جميع المتصفحات افتراضيًا، بما في ذلك توقيع التعليمات البرمجية، فمن المحتمل أن يؤدي ذلك إلى انهيار البنية التحتية.
  • أسماء النطاقات معقدة وغير مفهومة بشكل كافٍ (نقص في التوحيد القياسي، ومشاكل التدويل).
  • يحتوي rfc822Name على ترميزين
  • لم تدعم قيود الاسم والسياسة بشكل كافٍ
  • تم تجاهل استخدام المفتاح، ويتم استخدام الشهادة الأولى في القائمة.
  • يُعدّ تطبيق معرّفات الكائنات المخصصة أمرًا صعبًا
  • لا ينبغي جعل السمات بالغة الأهمية لأن ذلك يتسبب في تعطل البرامج.
  • يؤدي عدم تحديد طول السمات إلى قيود خاصة بالمنتج
  • توجد أخطاء في تنفيذ معيار X.509 تسمح، على سبيل المثال، بتزوير أسماء الموضوعات باستخدام سلاسل نصية منتهية بـ null [ 31 ] أو هجمات حقن التعليمات البرمجية في الشهادات.
  • باستخدام مُعرّفات فرعية غير قانونية [ 32 ] مُضافة إليها 0x80 لمُعرّفات الكائنات ، أو تطبيقات خاطئة، أو باستغلال تجاوزات الأعداد الصحيحة في متصفحات العميل، يُمكن للمهاجم تضمين سمة غير معروفة في طلب توقيع الشهادة (CSR)، والذي ستوقعه هيئة التصديق (CA)، والذي يُفسّره العميل خطأً على أنه "CN" (OID=2.5.4.3). وقد أوضح دان كامينسكي ذلك في المؤتمر السادس والعشرين لـ Chaos Communication بعنوان "العمليات السرية للبنية التحتية للمفاتيح العامة" [ 33 ].

نقاط الضعف في التشفير

تعتمد أنظمة التوقيع الرقمي على دوال تجزئة تشفيرية آمنة للعمل. عندما تسمح بنية المفتاح العام باستخدام دالة تجزئة لم تعد آمنة، يمكن للمهاجم استغلال نقاط الضعف في هذه الدالة لتزوير الشهادات. تحديدًا، إذا تمكن المهاجم من إحداث تصادم في التجزئة ، فبإمكانه إقناع جهة إصدار الشهادات بتوقيع شهادة ذات محتوى بريء، حيث تكون تجزئة هذا المحتوى مطابقة لتجزئة مجموعة أخرى من محتويات الشهادات الخبيثة، التي أنشأها المهاجم بقيم من اختياره. بعد ذلك، يستطيع المهاجم إلحاق التوقيع المقدم من جهة إصدار الشهادات بمحتويات شهادته الخبيثة، مما ينتج عنه شهادة خبيثة تبدو وكأنها موقعة من جهة إصدار الشهادات. ولأن محتويات الشهادة الخبيثة يختارها المهاجم وحده، فقد تختلف تواريخ صلاحيتها أو أسماء مضيفيها عن الشهادة البريئة. بل قد تحتوي الشهادة الخبيثة على حقل "CA: true" مما يُمكّنها من إصدار شهادات موثوقة أخرى.

  • استُخدمت الشهادات المستندة إلى خوارزمية MD2 لفترة طويلة، وكانت عرضة لهجمات ما قبل الصورة . ولأن الشهادة الجذرية كانت تحتوي بالفعل على توقيع ذاتي، فقد تمكن المهاجمون من استخدام هذا التوقيع لإنشاء شهادة وسيطة.
  • في عام 2005، أوضح أرجين لينسترا وبين دي ويجر "كيفية استخدام تصادمات التجزئة لإنشاء شهادتين X.509 تحتويان على توقيعات متطابقة وتختلفان فقط في المفاتيح العامة"، وقد تم ذلك باستخدام هجوم تصادم على دالة التجزئة MD5 . [ 34 ]
  • في عام 2008، قدم ألكسندر سوتيروف ومارك ستيفنز في مؤتمر اتصالات الفوضى هجومًا عمليًا سمح لهما بإنشاء هيئة إصدار شهادات مزيفة، مقبولة من قبل جميع المتصفحات الشائعة، من خلال استغلال حقيقة أن RapidSSL كانت لا تزال تصدر شهادات X.509 المستندة إلى MD5. [ 35 ]
  • في أبريل 2009، وخلال مؤتمر يورو كريبت، [ 36 ] قدم باحثون أستراليون من جامعة ماكواري بحثًا بعنوان "البحث التلقائي عن المسار التفاضلي لخوارزمية SHA-1 ". [ 37 ] وقد تمكن الباحثون من استنتاج طريقة تزيد من احتمالية التصادم بعدة مراتب. [ 38 ]
  • في فبراير 2017، أنتجت مجموعة من الباحثين بقيادة مارك ستيفنز تصادمًا لخوارزمية SHA-1، مما أظهر ضعف هذه الخوارزمية. [ 39 ]

إجراءات التخفيف من نقاط الضعف في التشفير

يتطلب استغلال تصادم التجزئة لتزوير توقيعات X.509 أن يكون المهاجم قادرًا على التنبؤ بالبيانات التي ستوقعها جهة إصدار الشهادات. ويمكن التخفيف من هذا الخطر جزئيًا من خلال قيام جهة إصدار الشهادات بتوليد عنصر عشوائي في الشهادات التي توقعها، وعادةً ما يكون هذا العنصر هو الرقم التسلسلي. وقد اشترط منتدى جهات إصدار الشهادات/المتصفحات وجود عنصر عشوائي في الرقم التسلسلي ضمن متطلباته الأساسية، القسم 7.1، منذ عام 2011. [ 40 ]

اعتبارًا من 1 يناير 2016 تحظر المتطلبات الأساسية إصدار الشهادات باستخدام خوارزمية SHA-1. اعتبارًا من أوائل عام 2017يرفض كل من متصفحي Chrome [ 41 ] وFirefox [ 42 ] الشهادات التي تستخدم خوارزمية SHA-1. اعتبارًا من مايو 2017 يرفض كل من متصفحي Edge [ 43 ] وSafari [ 44 ] شهادات SHA-1. بدأ OpenSSL برفض شهادات SHA-1 افتراضيًا في الإصدار 3.0، الذي صدر في سبتمبر 2021. [ 45 ]

معايير البنية التحتية للمفاتيح العامة (PKI) لـ X.509

  • PKCS7 (معيار بناء جملة الرسائل المشفرة  - المفاتيح العامة مع إثبات الهوية للرسائل الموقعة و/أو المشفرة لـ PKI) [ 46 ]
  • بروتوكول أمان طبقة النقل (TLS) وسلفه SSL  - بروتوكولات تشفير للاتصالات الآمنة عبر الإنترنت. [ 47 ]
  • بروتوكول حالة الشهادة عبر الإنترنت (OCSP) [ 48 ] / قائمة إبطال الشهادات (CRL) [ 9 ]  — يُستخدم هذا للتحقق من حالة إبطال الشهادة
  • PKCS12 (معيار بناء جملة تبادل المعلومات الشخصية)  - يستخدم لتخزين مفتاح خاص مع شهادة المفتاح العام المناسبة [ 49 ]
  • RFC 4158 - بناء مسار الشهادة - إرشادات وتوصيات لبناء مسارات شهادة المفتاح العام X.509 داخل التطبيقات (أي التحقق من صحة شهادة الكيان النهائي باستخدام شهادة CA) 

مجموعة عمل PKIX

في عام ١٩٩٥، شكّلت فرقة عمل هندسة الإنترنت بالتعاون مع المعهد الوطني للمعايير والتكنولوجيا [ ٥٠ ] فريق عمل البنية التحتية للمفتاح العام (X.509). يُشار إلى فريق العمل، الذي اختُتم عمله في يونيو ٢٠١٤ [ ٥١ ] ، باسم "PKIX". وقد أصدر الفريق وثائق RFC وغيرها من وثائق المعايير المتعلقة باستخدام ونشر X.509 عمليًا. وعلى وجه الخصوص، أصدر RFC ٣٢٨٠ وخليفته RFC ٥٢٨٠، اللذين يُحددان كيفية استخدام X.509 في بروتوكولات الإنترنت. 

البروتوكولات والمعايير الرئيسية التي تستخدم شهادات X.509

يستخدم كل من بروتوكول TLS/SSL وبروتوكول HTTPS ملف تعريف RFC 5280 الخاص بـ X.509، وكذلك بروتوكول S/MIME (ملحقات البريد الإلكتروني الآمنة متعددة الأغراض) وطريقة EAP-TLS لمصادقة شبكة Wi-Fi. أي بروتوكول يستخدم TLS، مثل SMTP وPOP وIMAP وLDAP و XMPP وغيرها الكثير، يستخدم X.509 بشكل أساسي. 

يمكن لبروتوكول IPsec استخدام ملف تعريف RFC 4945 لمصادقة النظراء. 

تحدد مواصفات أمان OpenCable ملف تعريف خاص بها لـ X.509 لاستخدامه في صناعة الكابلات.

غالباً ما تحمل أجهزة مثل البطاقات الذكية ووحدات TPM شهادات لتحديد هويتها أو هوية مالكيها. وتكون هذه الشهادات بصيغة X.509.

يُعرّف معيار WS -Security المصادقة إما عبر بروتوكول TLS أو عبر ملف تعريف الشهادة الخاص به. [ 18 ] وتستخدم كلتا الطريقتين معيار X.509.

يستخدم نظام توقيع التعليمات البرمجية Microsoft Authenticode بروتوكول X.509 لتحديد هوية مؤلفي برامج الحاسوب. وتستخدم ميزة التمهيد الآمن في UEFI بروتوكول X.509 للتحقق من هوية برامج تشغيل UEFI أو برامج الإقلاع أثناء عملية التمهيد ، ومنع برامج التشغيل أو برامج الإقلاع المدرجة في القائمة السوداء (باستخدام تبادل المفاتيح المحظور أو قاعدة بيانات dbx). [ 52 ]

يستخدم معيار الاتصالات الصناعية للأتمتة OPC UA معيار X.509.

يستخدم بروتوكول SSH عمومًا نموذج أمان " الثقة عند الاستخدام الأول" ولا يحتاج إلى شهادات. مع ذلك، يدعم تطبيق OpenSSH الشائع نموذج هوية موقّع من جهة مصدقة، يعتمد على تنسيق شهادات خاص به غير X.509. [ 53 ]

انظر أيضاً

مراجع

  1. 1 2 "X.509: تكنولوجيا المعلومات - الربط البيني للأنظمة المفتوحة - الدليل: أطر عمل المفتاح العام وشهادات السمات" . الاتحاد الدولي للاتصالات . تم الاطلاع عليه بتاريخ 6 نوفمبر 2019 .
  2. 1 2 هيس، بيتر؛ كوبر، مات؛ دزامباسوف، يوري أ.؛ جوزيف، سوزان؛ نيكولاس، ريتشارد (سبتمبر 2005). البنية التحتية للمفتاح العام X.509 للإنترنت: بناء مسار التصديق . مجموعة عمل الشبكة. doi : 10.17487/RFC4158 . RFC 4158 .لأغراض إعلامية.
  3. ↑ كوبر، د.؛ سانتيسون، س.؛ فاريل، س.؛ بوين، س.؛ هاوسلي، ر.؛ بولك، و. (مايو 2008). ملف تعريف شهادة البنية التحتية للمفتاح العام X.509 للإنترنت وقائمة إبطال الشهادات (CRL) . IETF . doi : 10.17487/RFC5280 . RFC 5280 .معيار مقترح. تم تحديثه بموجب RFC 9549 و 9598 و 8398 و 8399 و 6818 . يلغي RFC 4630 و 4325 و 3280 . فيما يلي عرض مبسط للنموذج المعماري الذي تعتمده بنية المفتاح العام باستخدام مواصفات X.509 (PKIX).  
  4. 1 2 3 4 غوتمان، بيتر (أبريل 2014). "هندسة الأمن" (ملف PDF) .
  5. ↑ هاوسلي، ر.؛ هوفمان، ب. (مايو 1999). بروتوكولات التشغيل للبنية التحتية للمفتاح العام X.509 للإنترنت: FTP وHTTP . مجموعة عمل الشبكة. doi : 10.17487/RFC2585 . RFC 2585 .المعيار المقترح. القسم 4: تسجيلات MIME.
  6. ↑ "شهادة x509" . وثائق مطوري Apple: مُعرّفات الأنواع الموحدة . شركة Apple Inc.
  7. ↑ "CA:IncludedCAs" . ويكي موزيلا . تم الاطلاع عليه بتاريخ 17 يناير 2017 .
  8. ↑ "الخطأ رقم 110161 - (ocspdefault) تفعيل بروتوكول OCSP افتراضيًا" . موزيلا . تم الاطلاع عليه بتاريخ 17 مارس 2016 .
  9. 1 2 3 4 5 6 7 8 كوبر، د.؛ سانتيسون، س.؛ فاريل، س.؛ بوين، س.؛ هاوسلي، ر.؛ بولك، و. (مايو 2008). ملف تعريف شهادة البنية التحتية للمفتاح العام X.509 للإنترنت وقائمة إبطال الشهادات (CRL) . IETF . doi : 10.17487/RFC5280 . RFC 5280 .معيار مقترح. تم تحديثه بواسطة RFC 9549 و 9598 و 8398 و 8399 و 6818 . يلغي RFC 4630 و 4325 و 3280 .  
  10. ↑ نيلسون ب. بويارد (9 مايو 2002). "كل ما يتعلق بتمديدات الشهادات" . موزيلا. مؤرشف من الأصل في 15 ديسمبر 2018. تم الاطلاع عليه في 10 سبتمبر 2020 .
  11. ↑ "نقل واجهة المستخدم EV إلى معلومات الصفحة" . وثائق كروميوم . 2021. تم الاسترجاع في 12 يوليو 2025 .
  12. ↑ "تحسين مؤشرات الأمان والخصوصية في فايرفوكس 70" . مدونة موزيلا للأمان . 15 أكتوبر 2019. تاريخ الاطلاع: 12 يوليو 2025 .
  13. ↑ "شهادات التحقق الموسع قد ولّت (فعلاً، فعلاً)" . تروي هانت . 13 أغسطس 2019. تاريخ الاطلاع: 12 يوليو 2025 .
  14. ↑ sysadmin1138 (19 مايو 2009). "ما هو ملف PEM وكيف يختلف عن تنسيقات ملفات المفاتيح الأخرى المُولَّدة بواسطة OpenSSL؟" . Server Fault . تم الاطلاع عليه في 19 أكتوبر 2023 .{{cite web}}: CS1 maint: أسماء رقمية: قائمة المؤلفين ( رابط ) تتضمن هذه المقالة نصًا من هذا المصدر، وهو متاح بموجب ترخيص CC BY-SA 2.5 . 
  15. ↑ لويد، ستيف (سبتمبر 2002). فهم بناء مسار الاعتماد (ملف PDF) . منتدى البنية التحتية للمفاتيح العامة. مؤرشف من الأصل (ملف PDF) بتاريخ 4 فبراير 2019. تم الاطلاع عليه بتاريخ 7 نوفمبر 2014 .
  16. ↑ "التصديق المتبادل بين هيئات التصديق الجذرية". سيناريوهات نشر التبعية المؤهلة . مايكروسوفت. أغسطس 2009.
  17. ↑ ناش؛ دوان؛ جوزيف؛ برينك (2001). "دورات حياة المفاتيح والشهادات. تجديد شهادة المرجع المصدق". البنية التحتية للمفاتيح العامة: تطبيق وإدارة الأمن الإلكتروني . مطبعة RSA - أوزبورن/ماكجرو هيل. ISBN 0-07-213123-3.
  18. 1 2 "ملف تعريف رمز الأمان X.509 لخدمات الويب، الإصدار 1.1.1" . أواسيس . تم الاطلاع عليه بتاريخ 14 مارس 2017 .
  19. ↑ كارل إليسون وبروس شناير. "أهم 10 مخاطر على البنية التحتية للمفاتيح العامة" (ملف PDF) . مجلة أمن الحاسوب (المجلد السادس عشر، العدد 1، 2000). مؤرشف من الأصل (ملف PDF) بتاريخ 24 نوفمبر 2015. تم الاطلاع عليه بتاريخ 2 أبريل 2014 .
  20. ↑ بيتر غوتمان . "البنية التحتية للمفاتيح العامة: إنها ليست ميتة، بل في حالة راحة" (ملف PDF) . مجلة IEEE Computer (المجلد: 35، العدد: 8).
  21. 1 2 غوتمان، بيتر . "كل ما لم ترغب بمعرفته عن البنية التحتية للمفاتيح العامة ولكنك اضطررت لاكتشافه" (ملف PDF) . تم الاطلاع عليه بتاريخ 14 نوفمبر 2011 .
  22. ↑ لانغلي، آدم (5 فبراير 2012). "التحقق من الإلغاء وقائمة إبطال الشهادات في متصفح كروم" . إمبريال فايوليت . تم الاطلاع عليه في 2 فبراير 2017 .
  23. ↑ "نموذج خطة عمل لأنظمة الأمن [ 2021 ] " . OGScapital . 27-01-2014. مؤرشف من الأصل في 09-07-2021 . تم الاطلاع عليه في 30-06-2021 .
  24. ↑ مايكل زوسمان؛ ألكسندر سوتيروف (يوليو 2009). "البنية التحتية للمفاتيح العامة للقروض الثانوية: مهاجمة بروتوكول SSL ذي التحقق الموسع" (ملف PDF) . بلاك هات . تم الاطلاع عليه بتاريخ 10 سبتمبر 2020 .
  25. ↑ هانت، تروي (17 سبتمبر 2018). "شهادات التحقق الموسع أصبحت من الماضي" . TroyHunt.com . تاريخ الاسترجاع: 26 فبراير 2019 .
  26. ↑ "Let's Encrypt" . Let's Encrypt . 10-07-2023 . تم الاطلاع عليه بتاريخ 08-04-2025 .
  27. ↑ "من أجل إنترنت أفضل - التقرير السنوي لمجموعة أبحاث أمن الإنترنت لعام 2020" (ملف PDF) . مجموعة أبحاث أمن الإنترنت . 17 نوفمبر 2020. تاريخ الاطلاع: 11 مايو 2021 .
  28. ↑ "إحصائيات Let's Encrypt" . Let's Encrypt . 10-07-2023 . تم الاطلاع عليه بتاريخ 08-04-2025 .
  29. ↑ "جهة إصدار الشهادات - بيان ممارسات إصدار الشهادات" (ملف PDF) . الإصدار 6.1. شركة آبل . 19 أغسطس 2016.
  30. ↑ فان بيلت، كريس. "Logius: مشكلة ثقة الحكومة الهولندية CA" . بوغزيلا . تم الاسترجاع في 31 أكتوبر 2017 .
  31. ↑ موكسي مارلينسبايك (2009). "المزيد من الحيل لهزيمة بروتوكول SSL عمليًا" (ملف PDF) . معهد الدراسات التخريبية. بلاك هات . تم الاطلاع عليه بتاريخ 10 سبتمبر 2020 .
  32. ↑ التوصية ITU-T X.690، البند 8.19.2
  33. ↑ دان كامينسكي (29 ديسمبر 2009). "26C3: العمليات السرية للبنية التحتية للمفاتيح العامة" . مدونة فعاليات نادي دير كاوس للحاسوب . تم الاطلاع عليه بتاريخ 29 سبتمبر 2013 .
  34. ↑ لينسترا، أرجين؛ دي ويجر، بين (19 مايو 2005). حول إمكانية إنشاء تصادمات تجزئة ذات معنى للمفاتيح العامة (ملف PDF) (تقرير فني). لوسنت تكنولوجيز، مختبرات بيل، وجامعة آيندهوفن للتكنولوجيا. مؤرشف (ملف PDF) من الأصل في 14 مايو 2013. تم الاطلاع عليه في 28 سبتمبر 2013 .
  35. ↑ "يُعتبر خوارزمية MD5 ضارة اليوم" . جامعة آيندهوفن للتكنولوجيا. 16 يونيو 2011. تم الاطلاع عليه بتاريخ 29 سبتمبر 2013 .
  36. ↑ "يورو كريبت 2009" . الرابطة الدولية لأبحاث التشفير.
  37. ↑ كاميرون ماكدونالد؛ فيليب هوكس؛ جوزيف بيبرزيك (2009). "اصطدامات SHA-1 الآن" (ملف PDF) . جامعة ماكواري وكوالكوم . تم الاطلاع عليه بتاريخ 10 سبتمبر 2020 .
  38. ↑ دينيس دوير (2 يونيو 2009). "هجمات تصادم SHA-1 تصل إلى 252" . رؤى سكيور وركس . تم الاطلاع عليه بتاريخ 24 فبراير 2016 .
  39. ↑ مارك ستيفنز؛ إيلي بورشتين؛ بيير كاربمان؛ أنج ألبرتيني؛ ياريك ماركوف. "أول تصادم لنموذج SHA-1 الكامل" (ملف PDF) . مركز CWI أمستردام وجوجل للأبحاث. مؤرشف من النسخة الأصلية (ملف PDF) بتاريخ 15 مايو 2018. تم الاطلاع عليه بتاريخ 10 سبتمبر 2020 - عبر Shattered.
  40. ↑ "وثائق المتطلبات الأساسية" . منتدى متصفحات CA. تم الاطلاع عليه بتاريخ 19 مارس 2017 .
  41. ↑ أندرو والي (16 نوفمبر 2016). "شهادات SHA-1 في متصفح كروم" . مدونة جوجل للأمن الإلكتروني . تم الاطلاع عليه بتاريخ 19 مارس 2017 .
  42. ↑ "نهاية SHA-1 على الويب العام" . مدونة موزيلا للأمن . 23 فبراير 2017. تم الاطلاع عليه في 19 مارس 2017 .
  43. ↑ "إشعار أمني من مايكروسوفت رقم 4010323" . تكنت . مايكروسوفت . تم الاطلاع عليه بتاريخ 16 مايو 2017 .
  44. ↑ «لا يدعم متصفح سفاري ومحرك WebKit شهادات SHA-1» . دعم Apple . ١٦ أغسطس ٢٠١٨. تم الاطلاع عليه بتاريخ ١٠ سبتمبر ٢٠٢٠ .
  45. ↑ "openssl/NEWS.md at master · openssl/openssl" . GitHub . تم الاسترجاع في 16 فبراير 2025 .
  46. ↑ ب. كاليسكي (مارس 1998). PKCS #7: صيغة الرسائل المشفرة، الإصدار 1.5 . مجموعة عمل الشبكة. doi : 10.17487/RFC2315 . RFC 2315 .لأغراض إعلامية.
  47. ↑ تي. ديركس؛ إي. ريسكورلا (أغسطس 2008). بروتوكول أمان طبقة النقل (TLS) الإصدار 1.2 . مجموعة عمل IETF TLS. doi : 10.17487/RFC5246 . RFC 5246 .مُلغى. تم إلغاؤه بموجب RFC 8446. يُلغي RFC 3268 و 4346 و 4366 ؛ ويُحدّث RFC 4492 .   
  48. ↑ س. سانتيسون؛ م. مايرز؛ ر. أنكي؛ س. غالبرين؛ س. آدامز (يونيو 2013). بروتوكول حالة الشهادة عبر الإنترنت للبنية التحتية للمفتاح العام للإنترنت X.509 - OCSP . فريق عمل هندسة الإنترنت . doi : 10.17487/RFC6960 . RFC 6960 .معيار مقترح. تم تحديثه بواسطة RFC 8954. يلغي RFC 6277 و 2560 . يُحدّث RFC 5912 .   
  49. ↑ "PKCS 12: معيار بناء جملة تبادل المعلومات الشخصية" . EMC.com . مختبرات RSA. مؤرشف من الأصل في 6 يوليو 2017. تم الاطلاع عليه في 19 مارس 2017 .
  50. ↑ "البنية التحتية للمفتاح العام (X.509) (pkix) - الميثاق" . متتبع بيانات IETF . فريق عمل هندسة الإنترنت . تم الاطلاع عليه في 1 أكتوبر 2013 .
  51. ↑ "صفحات حالة Pkix" . أدوات IETF . تم الاطلاع عليه بتاريخ 10 مارس 2017 .
  52. ↑ سميث، رودريك و. (2012-11-04). "إدارة مُحمِّلات الإقلاع EFI لنظام لينكس: التحكم في الإقلاع الآمن (إدارة المفاتيح من لينكس)" . صفحة رودريك و. سميث على الويب . تم الاطلاع عليها بتاريخ 2025-02-20 .
  53. ↑ "كيفية إنشاء مرجع مصدق SSH للتحقق من صحة المضيفين والعملاء باستخدام أوبونتو" . DigitalOcean . تم الاطلاع عليه بتاريخ 19 مارس 2017 .