جهة إصدار الشهادات

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

في علم التشفير ، تُعرف هيئة إصدار الشهادات ( CA ) بأنها جهة تتولى تخزين الشهادات الرقمية وتوقيعها وإصدارها . تُثبت الشهادة الرقمية ملكية المفتاح العام من قِبل الشخص المذكور في الشهادة. وهذا يُتيح للأطراف الأخرى (الأطراف المعتمدة) الاعتماد على التوقيعات أو على التأكيدات المُقدمة بشأن المفتاح الخاص المُطابق للمفتاح العام المُصدق عليه. تعمل هيئة إصدار الشهادات كطرف ثالث موثوق به، يحظى بثقة كلٍ من صاحب الشهادة (مالكها) والطرف المُعتمد عليها. [ 1 ] ويُحدد معيار X.509 أو EMV تنسيق هذه الشهادات .

من الاستخدامات الشائعة لسلطات إصدار الشهادات توقيع الشهادات المستخدمة في بروتوكول HTTPS ، وهو بروتوكول التصفح الآمن لشبكة الإنترنت العالمية. كما يُستخدم إصدار بطاقات الهوية من قبل الحكومات الوطنية لتوقيع المستندات إلكترونياً. [ 2 ]

ملخص

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

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

إلى جانب هيئات إصدار الشهادات التجارية، تُصدر بعض المؤسسات غير الربحية شهادات رقمية موثوقة للجمهور مجانًا، مثل Let's Encrypt . كما تُعدّ بعض شركات الحوسبة السحابية واستضافة المواقع الإلكترونية الكبرى هيئات إصدار شهادات موثوقة للجمهور، وتُصدر شهادات للخدمات المُستضافة على بنيتها التحتية، مثل IBM Cloud و Amazon Web Services و Cloudflare و Google Cloud Platform .

قد تمتلك المنظمات الكبيرة أو الهيئات الحكومية بنى تحتية خاصة بها للمفاتيح العامة (PKI )، تحتوي كل منها على هيئة إصدار شهادات خاصة بها. أي موقع يستخدم شهادات موقعة ذاتيًا يعمل كهيئة إصدار شهادات خاصة به.

تخضع البنوك التجارية التي تصدر بطاقات الدفع EMV لإشراف هيئة إصدار شهادات EMV، [ 5 ] حيث تقوم أنظمة الدفع بتوجيه معاملات الدفع التي تتم عند نقاط البيع ( POS ) إلى البنك المُصدر للبطاقة لتحويل الأموال من حساب حامل البطاقة إلى حساب المستلم. تُقدم كل بطاقة دفع، بالإضافة إلى بياناتها، شهادة جهة إصدار البطاقة إلى نقطة البيع. تُوقع شهادة جهة الإصدار بواسطة شهادة هيئة إصدار شهادات EMV. تسترجع نقطة البيع المفتاح العام لهيئة إصدار شهادات EMV من ذاكرتها، وتتحقق من صحة شهادة جهة الإصدار ومصداقية بطاقة الدفع قبل إرسال طلب الدفع إلى نظام الدفع.

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

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

مقدمو الخدمات

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

مع ذلك، فإن سوق شهادات خوادم TLS/SSL الموثوقة عالميًا يهيمن عليه عدد محدود من الشركات متعددة الجنسيات. ويواجه هذا السوق عوائق كبيرة أمام دخوله نظرًا لمتطلباته التقنية. [ 7 ] ورغم عدم اشتراط ذلك قانونًا، قد يختار مزودو الخدمة الجدد الخضوع لعمليات تدقيق أمني سنوية (مثل WebTrust [ 8 ] لهيئات إصدار الشهادات في أمريكا الشمالية و ETSI في أوروبا [ 9 ] ) ليتم إدراجهم كجذر موثوق به من قِبل متصفح الويب أو نظام التشغيل.

اعتبارًا من 24 أغسطس 2020  يُعتبر 147 شهادة جذرية، تمثل 52 منظمة، موثوقة في متصفح موزيلا فايرفوكس ، [ 10 ] و168 شهادة جذرية، تمثل 60 منظمة، موثوقة في نظام macOS ، [ 11 ] و255 شهادة جذرية، تمثل 101 منظمة، موثوقة في نظام مايكروسوفت ويندوز . [ 12 ] اعتبارًا من نظام أندرويد 4.2 (جيلي بين)، يحتوي نظام أندرويد حاليًا على أكثر من 100 جهة مصدقة يتم تحديثها مع كل إصدار. [ 13 ]

في 18 نوفمبر 2014، أعلنت مجموعة من الشركات والمنظمات غير الربحية، بما في ذلك مؤسسة الحدود الإلكترونية ، وموزيلا، وسيسكو، وأكامي، عن إطلاق "ليتس إنكريبت" ، وهي هيئة إصدار شهادات غير ربحية توفر شهادات X.509 مجانية مُصدّقة للنطاقات ، بالإضافة إلى برامج تُمكّن من تثبيت الشهادات وصيانتها. [ 14 ] تُشغّل "ليتس إنكريبت" من قِبل " مجموعة أبحاث أمن الإنترنت" المُنشأة حديثًا ، وهي منظمة غير ربحية في كاليفورنيا مُعترف بها كمنظمة معفاة من الضرائب الفيدرالية. [ 15 ]

بحسب شركة Netcraft في مايو 2015، وهي المعيار الصناعي لمراقبة شهادات TLS النشطة، "على الرغم من أن بيئة TLS العالمية تنافسية، إلا أنها تهيمن عليها حفنة من هيئات إصدار الشهادات الرئيسية - ثلاث هيئات (Symantec وComodo CA وGoDaddy) تستحوذ على ثلاثة أرباع جميع شهادات TLS الصادرة على خوادم الويب العامة. وقد احتلت Symantec (أو VeriSign قبل استحواذ Symantec عليها) الصدارة منذ بدء دراستنا، حيث تستحوذ حاليًا على ما يقارب ثلث جميع الشهادات. ولتوضيح تأثير اختلاف المنهجيات، من بين مليون موقع من أكثر المواقع ازدحامًا، أصدرت Symantec 44% من الشهادات الصالحة والموثوقة المستخدمة - وهو ما يزيد بشكل ملحوظ عن حصتها السوقية الإجمالية." [ 16 ]

اعتبارًا من يوليو 2024 تُدرج شركة W3Techs، المتخصصة في جمع الإحصاءات حول استخدام سلطات إصدار الشهادات بين أفضل 10 ملايين موقع على Alexa وأفضل مليون موقع على Tranco، أكبر خمس سلطات من حيث حصة الاستخدام المطلقة كما يلي. [ 17 ]

رتبةجهة الإصدارالاستخدامالحصة السوقية
1Let's Encrypt60.6%64.1%
2غلوبال ساين22.3%23.6%
3سيكتيجو (المعروفة سابقًا باسم كومودو كاليفورنيا)5.7%6.0%
4مجموعة غودادي3.7%3.9%
5مجموعة ديجي سيرت1.8%1.9%

معايير التحقق

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

تقدم العديد من هيئات إصدار الشهادات شهادات التحقق الموسع (EV) كبديل أكثر دقة لشهادات التحقق من النطاق. يهدف التحقق الموسع إلى التحقق ليس فقط من ملكية اسم النطاق، بل أيضًا من معلومات هوية إضافية تُضمّن في الشهادة. تعرض بعض المتصفحات هذه المعلومات الإضافية في مربع أخضر في شريط عنوان الموقع. من عيوب التحقق الموسع كحل لنقاط ضعف التحقق من النطاق، إمكانية حصول المهاجمين على شهادة تحقق من النطاق للنطاق المستهدف، واستخدامها أثناء الهجوم؛ في هذه الحالة، سيلاحظ المستخدم غياب الشريط الأخضر الذي يحمل اسم الشركة. يبقى التساؤل قائمًا حول ما إذا كان المستخدمون سيدركون هذا الغياب كمؤشر على هجوم جارٍ: فقد أظهر اختبار أُجري باستخدام متصفح إنترنت إكسبلورر 7 عام 2009 أن غياب تحذيرات التحقق الموسع لم يُلاحظ من قِبل المستخدمين، بينما يُظهر متصفح مايكروسوفت الأحدث، إيدج ليجاسي ، فرقًا أكبر بكثير بين شهادات التحقق الموسع وشهادات التحقق من النطاق، حيث تتميز شهادات التحقق من النطاق بقفل رمادي مجوف.

نقاط ضعف التحقق

يعاني التحقق من النطاق من بعض القيود الأمنية الهيكلية. على وجه الخصوص، فهو عرضة دائمًا للهجمات التي تسمح للمهاجم بمراقبة طلبات التحقق من النطاق التي ترسلها هيئات إصدار الشهادات. قد تشمل هذه الهجمات استهداف بروتوكولات DNS أو TCP أو BGP (التي تفتقر إلى الحماية التشفيرية التي توفرها بروتوكولات TLS/SSL)، أو اختراق أجهزة التوجيه. ويمكن أن تحدث هذه الهجمات إما على الشبكة القريبة من هيئة إصدار الشهادات، أو بالقرب من نطاق الضحية نفسه.

إحدى أكثر تقنيات التحقق من صحة النطاق شيوعًا هي إرسال بريد إلكتروني يحتوي على رمز أو رابط مصادقة إلى عنوان بريد إلكتروني يُرجّح أن يكون مسؤولًا إداريًا عن النطاق. قد يكون هذا عنوان البريد الإلكتروني للتواصل التقني المُدرج في سجل WHOIS الخاص بالنطاق ، أو بريدًا إلكترونيًا إداريًا مثل admin@ أو administrator@ أو webmaster@ أو hostmaster@ أو postmaster@ . [ 18 ] [ 19 ] قد تقبل بعض جهات إصدار الشهادات التأكيد باستخدام root@ أو info@ أو support@ في النطاق. [ 20 ] تقوم فكرة التحقق من صحة النطاق على أن المالك الشرعي للنطاق فقط هو من يستطيع قراءة رسائل البريد الإلكتروني المُرسلة إلى هذه العناوين الإدارية.

لطالما شكلت تطبيقات التحقق من صحة النطاق مصدرًا للثغرات الأمنية. ففي إحدى الحالات، أظهر باحثون أمنيون أن المهاجمين تمكنوا من الحصول على شهادات لمواقع البريد الإلكتروني لأن جهة إصدار الشهادات كانت على استعداد لاستخدام عنوان بريد إلكتروني مثل ssladmin@domain.com لنطاق domain.com، ولكن لم تكن جميع أنظمة البريد الإلكتروني قد حجزت اسم المستخدم "ssladmin" لمنع المهاجمين من تسجيله. [ 21 ]

قبل عام 2011، لم تكن هناك قائمة موحدة بعناوين البريد الإلكتروني التي يمكن استخدامها للتحقق من صحة النطاق، لذا لم يكن واضحًا لمسؤولي البريد الإلكتروني أي العناوين يجب حجزها. حددت النسخة الأولى من متطلبات CA/Browser Forum الأساسية، التي اعتُمدت في نوفمبر 2011، قائمةً بهذه العناوين. سمح هذا لمضيفي البريد بحجز تلك العناوين للاستخدام الإداري، مع أن هذه الاحتياطات لا تزال غير مُعممة. في يناير 2015، سجّل رجل فنلندي اسم المستخدم "hostmaster" في النسخة الفنلندية من Microsoft Live، وتمكّن من الحصول على شهادة تحقق من صحة النطاق لـ live.fi، على الرغم من أنه لم يكن مالكًا لاسم النطاق. [ 22 ]

إصدار شهادة

إجراءات الحصول على شهادة المفتاح العام

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

إذا كان المستخدم يثق في هيئة التصديق ويمكنه التحقق من توقيعها، فيمكنه أيضاً أن يفترض أن مفتاحاً عاماً معيناً ينتمي بالفعل إلى الشخص المحدد في الشهادة. [ 24 ]

مثال

يمكن استخدام التشفير بالمفتاح العام لتشفير البيانات المتبادلة بين طرفين. يحدث هذا عادةً عند تسجيل دخول المستخدم إلى أي موقع يستخدم بروتوكول HTTP الآمن . في هذا المثال، لنفترض أن المستخدم يسجل دخوله إلى الموقع الإلكتروني لبنكه www.bank.example لإجراء معاملات مصرفية عبر الإنترنت . عند فتح المستخدم للموقع www.bank.example، يتلقى مفتاحًا عامًا مع جميع البيانات التي يعرضها متصفحه. يمكن استخدام المفتاح العام لتشفير البيانات من العميل إلى الخادم، ولكن الإجراء الآمن هو استخدامه في بروتوكول يُحدد مفتاح تشفير متماثل مشترك مؤقت؛ حيث يمكن تشفير الرسائل في بروتوكول تبادل المفاتيح هذا باستخدام المفتاح العام للبنك، بحيث لا يملك سوى خادم البنك المفتاح الخاص لقراءتها. [ 25 ]

ثم تستمر بقية عملية الاتصال باستخدام المفتاح المتناظر الجديد (الذي يمكن التخلص منه)، فعندما يُدخل المستخدم بعض المعلومات على صفحة البنك ويرسلها (أي يُعيد إرسال المعلومات إلى البنك)، يقوم متصفح الويب الخاص به بتشفير البيانات التي أدخلها. وبالتالي، حتى لو تمكن شخص ما من الوصول إلى البيانات (المشفرة) التي أرسلها المستخدم إلى www.bank.example، فلن يتمكن هذا المتطفل من قراءتها أو فك تشفيرها.

لا تكون هذه الآلية آمنة إلا إذا تأكد المستخدم من أن الموقع الذي يراه في متصفحه هو موقع البنك. فإذا أدخل المستخدم www.bank.example، وتم اختراق اتصاله، وأرسل موقع ويب مزيف (ينتحل صفة موقع البنك) معلومات الصفحة إلى متصفح المستخدم، فبإمكان هذا الموقع المزيف إرسال مفتاح عام مزيف إلى المستخدم (مع العلم أن الموقع المزيف يمتلك مفتاحًا خاصًا مطابقًا له). سيقوم المستخدم بملء النموذج ببياناته الشخصية وإرسال الصفحة، وبذلك سيتمكن الموقع المزيف من الوصول إلى بيانات المستخدم.

هذا ما تهدف آلية سلطة إصدار الشهادات إلى منعه. سلطة إصدار الشهادات (CA) هي منظمة تخزن المفاتيح العامة وأصحابها، ويثق كل طرف في عملية الاتصال بهذه المنظمة (ويعرف مفتاحها العام). عندما يستقبل متصفح المستخدم المفتاح العام من www.bank.example، فإنه يستقبل أيضًا توقيعًا رقميًا لهذا المفتاح (مع بعض المعلومات الإضافية، في ما يُسمى شهادة X.509 ). يمتلك المتصفح بالفعل المفتاح العام لسلطة إصدار الشهادات، وبالتالي يمكنه التحقق من التوقيع، والوثوق بالشهادة والمفتاح العام الموجود فيها: بما أن www.bank.example يستخدم مفتاحًا عامًا تُصدّق عليه سلطة إصدار الشهادات، فإن موقعًا مزيفًا لـ www.bank.example لا يمكنه إلا استخدام نفس المفتاح العام. ولأن الموقع المزيف لا يعرف المفتاح الخاص المقابل، فإنه لا يستطيع إنشاء التوقيع اللازم للتحقق من صحته. [ 26 ]

حماية

يصعب ضمان صحة مطابقة البيانات مع الكيان عند تقديم البيانات إلى هيئة إصدار الشهادات (ربما عبر شبكة إلكترونية)، وعند تقديم بيانات اعتماد الشخص/الشركة/البرنامج الطالب للشهادة. لهذا السبب، غالبًا ما تستخدم هيئات إصدار الشهادات التجارية مزيجًا من تقنيات المصادقة، بما في ذلك الاستفادة من الجهات الحكومية، وبنية الدفع التحتية، وقواعد بيانات وخدمات جهات خارجية، وخوارزميات مخصصة. في بعض أنظمة المؤسسات، يمكن استخدام أشكال محلية للمصادقة، مثل Kerberos، للحصول على شهادة يمكن استخدامها بدورها من قبل جهات خارجية معتمدة. يُشترط في بعض الحالات أن يكون الموثق على معرفة شخصية بالطرف الذي يتم توثيق توقيعه؛ وهذا معيار أعلى مما تلتزم به العديد من هيئات إصدار الشهادات. وفقًا لتقرير نقابة المحامين الأمريكية حول إدارة المعاملات عبر الإنترنت، فإن النقاط الرئيسية للقوانين الفيدرالية وقوانين الولايات الأمريكية التي سُنّت بشأن التوقيعات الرقمية هي "منع اللوائح المحلية المتضاربة والمُرهقة، وإثبات أن الكتابات الإلكترونية تفي بالمتطلبات التقليدية المرتبطة بالوثائق الورقية". علاوة على ذلك، فإن قانون التوقيع الإلكتروني الأمريكي وقانون UETA المقترح [ 27 ] يساعدان في ضمان ما يلي:

  1. لا يجوز إنكار الأثر القانوني أو الصلاحية أو قابلية التنفيذ لأي توقيع أو عقد أو سجل آخر يتعلق بهذه المعاملة لمجرد كونه في شكل إلكتروني؛
  2. لا يجوز إنكار الأثر القانوني أو الصلاحية أو قابلية التنفيذ لعقد يتعلق بمثل هذه المعاملة لمجرد استخدام توقيع إلكتروني أو سجل إلكتروني في تكوينه.

على الرغم من التدابير الأمنية المتخذة للتحقق من هويات الأفراد والشركات بدقة، إلا أن هناك خطرًا يتمثل في قيام جهة إصدار شهادات واحدة بإصدار شهادة مزورة لشخص منتحل. كما يُمكن تسجيل الأفراد والشركات بأسماء متطابقة أو متشابهة جدًا، مما قد يُؤدي إلى حدوث لبس. وللحد من هذا الخطر، تقترح مبادرة شفافية الشهادات تدقيق جميع الشهادات في سجل عام غير قابل للتزوير، مما قد يُساعد في منع التصيد الاحتيالي . [ 28 ] [ 29 ]

في عمليات النشر واسعة النطاق، قد لا تكون أليس على دراية بجهة إصدار الشهادات الخاصة ببوب (ربما لكل منهما خادم جهة إصدار شهادات مختلف)، لذا قد تتضمن شهادة بوب أيضًا المفتاح العام لجهة إصدار الشهادات الخاصة به، والموقع من قِبل جهة إصدار شهادات أخرى (CA 2) ، والتي من المفترض أن تتعرف عليها أليس. تؤدي هذه العملية عادةً إلى تسلسل هرمي أو شبكة من جهات إصدار الشهادات وشهاداتها.

إلغاء الشهادة

يمكن إلغاء الشهادة قبل انتهاء صلاحيتها، مما يشير إلى أنها لم تعد صالحة. وبدون الإلغاء، سيتمكن المهاجم من استغلال هذه الشهادة المخترقة أو الصادرة بشكل خاطئ حتى تاريخ انتهاء صلاحيتها. [ 30 ] لذا، يُعدّ الإلغاء جزءًا أساسيًا من بنية المفتاح العام . [ 31 ] يتم الإلغاء بواسطة هيئة إصدار الشهادات، التي تُصدر بيان إلغاء موثق تشفيرًا . [ 32 ]

عند توزيع معلومات الإلغاء على العملاء، تُوازن سرعة اكتشاف الإلغاء (وبالتالي الفترة الزمنية المتاحة للمهاجم لاستغلال شهادة مخترقة) مع استخدام الموارد في الاستعلام عن حالات الإلغاء ومخاوف الخصوصية. [ 33 ] إذا كانت معلومات الإلغاء غير متوفرة (سواءً بسبب خطأ أو هجوم)، يجب على العملاء تحديد ما إذا كانوا سيتعاملون مع الشهادة كما لو كانت ملغاة (مما يُقلل من توافرها ) أو سيتعاملون معها كما لو كانت غير ملغاة (مما يسمح للمهاجمين بتجاوز الإلغاء). [ 34 ]

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

المنظمات الصناعية

المتطلبات الأساسية

ينشر منتدى هيئات التصديق/المتصفحات المتطلبات الأساسية [ 41 ] ، وهي قائمة بالسياسات والمتطلبات التقنية التي يجب على هيئات التصديق اتباعها. وتُعد هذه المتطلبات شرطًا أساسيًا لإدراج الشهادات في مخازن شهادات متصفحي فايرفوكس [ 42 ] وسفاري [ 43 ] .

في 14 أبريل 2025، أقر منتدى CA/Browser اقتراعًا لتقليل مدة صلاحية شهادات SSL/TLS إلى 47 يومًا كحد أقصى بحلول 15 مارس 2029. [ 44 ]

تاريخ البدءأقصى مدى الحياةتم تقديمه فيوتيرة تجديد الشهادة
1 يوليو 201260 شهرًاالإصدار 1.0 من المتطلبات الأساسية. §9.4
1 أبريل 201539 شهرًاالإصدار 1.3.0 من المتطلبات الأساسية. §6.3.2
1 مارس 2018825 يومًاالإصدار 1.4.4 من المتطلبات الأساسية. §6.3.2
1 سبتمبر 2020398 يومًاسنة واحدة
15 مارس 2026200 يومSC-081v3ستة أشهر
15 مارس 2027100 يومSC-081v33 أشهر
15 مارس 202947 يومًاSC-081v3شهر واحد

تسوية هيئة التصديق

إذا أمكن اختراق هيئة التصديق، فإن أمن النظام بأكمله سيضيع، مما قد يؤدي إلى تقويض جميع الكيانات التي تثق في هيئة التصديق المخترقة.

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

وقعت إحدى أبرز حالات التلاعب بشهادات المصادقة في عام ٢٠٠١، عندما أصدرت هيئة VeriSign شهادتين لشخص ادعى تمثيله لشركة مايكروسوفت. تحمل الشهادتان اسم "شركة مايكروسوفت"، مما أتاح استخدامها لخداع المستخدمين وإيهامهم بأن تحديثات برامج مايكروسوفت صادرة عنها، بينما هي في الواقع ليست كذلك. تم اكتشاف عملية الاحتيال في أوائل عام ٢٠٠١، واتخذت مايكروسوفت وVeriSign إجراءات للحد من آثار المشكلة. [ ٤٥ ] [ ٤٦ ]

في عام 2008، باعت شركة Certstar، وهي شركة إعادة بيع معتمدة من Comodo CA، شهادة لموقع mozilla.com إلى إيدي نيغ، الذي لم يكن لديه أي صلاحية لتمثيل Mozilla. [ 47 ]

في عام 2011، تم الحصول على شهادات مزورة من شركتي Comodo CA و DigiNotar ، [ 48 ] [ 49 ] ويُزعم أن قراصنة إيرانيين قاموا بذلك. وهناك أدلة على استخدام شهادات DigiNotar المزورة في هجوم وسيط في إيران. [ 50 ]

في عام 2012، اتضح أن شركة Trustwave أصدرت شهادة جذر فرعية استُخدمت لإدارة حركة المرور بشفافية (هجوم الوسيط)، مما سمح فعلياً للمؤسسات بالتجسس على حركة مرور الشبكة الداخلية SSL باستخدام الشهادة الفرعية. [ 51 ]

في عام 2012، احتوى برنامج Flame الخبيث (المعروف أيضًا باسم SkyWiper) على وحدات برمجية تصادمت مع شهادة صالحة صادرة عن ترخيص خادم Microsoft Terminal Server باستخدام خوارزمية التجزئة MD5 المعيبة. وبذلك، تمكن مطورو البرنامج من شن هجوم تصادم باستخدام التجزئة المذكورة في الشهادة. [ 52 ] [ 53 ]

في عام ٢٠١٥، أصدرت جهة إصدار شهادات صينية تُدعى MCS Holdings، تابعة لسجل النطاقات المركزي الصيني، شهادات غير مصرح بها لنطاقات جوجل. [ ٥٤ ] [ ٥٥ ] ونتيجةً لذلك، أزالت جوجل كلاً من MCS وجهة إصدار الشهادات الجذرية من متصفح كروم، وألغت الشهادات. [ ٥٦ ]

تخزين المفاتيح

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

تستخدم هيئات إصدار الشهادات أحيانًا مراسم خاصة عند إنشاء مفاتيح التوقيع، وذلك لضمان عدم التلاعب بالمفاتيح أو نسخها.

ضعف تنفيذ مخطط الطرف الثالث الموثوق به

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

تُعدّ هذه المسألة الدافع الرئيسي وراء تطوير بروتوكول مصادقة الكيانات المسماة المستند إلى نظام أسماء النطاقات (DANE). وفي حال اعتماده بالتزامن مع امتدادات أمان نظام أسماء النطاقات (DNSSEC)، سيُقلّل DANE بشكل كبير، إن لم يُلغِ تمامًا، دور الأطراف الثالثة الموثوقة في البنية التحتية للمفاتيح العامة (PKI) للنطاق.

انظر أيضاً

مراجع

  1. ↑ تشين، هونغ يو (19 أغسطس 2021). "شهادات المفتاح العام الديناميكية مع سرية التوجيه" . إلكترونيات . 10 (16): 2009. doi : 10.3390/electronics10162009 . ISSN 2079-9292 . 
  2. ↑ "ما هي جهة إصدار الشهادات (CA)؟ "
  3. ↑ فيلانويفا، جون كارل. "كيف تعمل الشهادات الرقمية - نظرة عامة" . www.jscape.com . تاريخ الاسترجاع: 5 سبتمبر 2021 .
  4. ↑ "قائمة شهادات المرجع المصدق المضمنة من موزيلا - موزيلا" . Mozilla.org. مؤرشف من الأصل بتاريخ 4 أغسطس 2013. تم الاطلاع عليه بتاريخ 11 يونيو 2014 .
  5. ↑ "هيئة إصدار شهادات EMV" . هيئة إصدار شهادات EMV العالمية. 2 أكتوبر 2010. تم الاطلاع عليه في 17 فبراير 2019 .
  6. ↑ زاكير دوروميريك؛ جيمس كاستن؛ مايكل بيلي؛ ج. أليكس هالدرمان (12 سبتمبر 2013). "تحليل منظومة شهادات HTTPS" (ملف PDF) . مؤتمر قياس الإنترنت . SIGCOMM . مؤرشف (ملف PDF) من الأصل في 22 ديسمبر 2013. تم الاطلاع عليه في 20 ديسمبر 2013 .
  7. ↑ "ما هي شهادة SSL؟" . مؤرشف من الأصل بتاريخ 2015-11-03 . تم الاطلاع عليه بتاريخ 2022-03-19 .
  8. ↑ "webtrust" . webtrust. مؤرشف من الأصل بتاريخ 18-08-2013 . تم الاطلاع عليه بتاريخ 02-03-2013 .
  9. ↑ كيرك هول (أبريل 2013). "المعايير واللوائح الصناعية المطبقة على جهات منح الشهادات" (ملف PDF) . تريند مايكرو. مؤرشف (ملف PDF) من الأصل بتاريخ 4 مارس 2016. تم الاطلاع عليه بتاريخ 11 يونيو 2014 .
  10. ↑ "CA:IncludedCAs - MozillaWiki" . wiki.mozilla.org . مؤرشف من الأصل بتاريخ 25-03-2017 . تم الاطلاع عليه بتاريخ 18-03-2017 .
  11. ↑ "قائمة شهادات الجذر الموثوقة المتاحة في macOS High Sierra" . دعم Apple . تم الاطلاع عليه بتاريخ 24 أغسطس 2020 .
  12. ↑ "قائمة شهادات المرجع المصدق المضمنة من مايكروسوفت" . ccadb-public.secure.force.com . تم الاطلاع عليه بتاريخ 24 أغسطس 2020 .
  13. ↑ "الأمان باستخدام HTTPS وSSL" . developer.android.com . مؤرشف من الأصل بتاريخ 2017-07-08 . تم الاطلاع عليه بتاريخ 2017-06-09 .
  14. ↑ «Let's Encrypt: توفير بروتوكول SSL/TLS في كل مكان» (بيان صحفي). Let's Encrypt. مؤرشف من الأصل بتاريخ 18 نوفمبر 2014. تم الاطلاع عليه بتاريخ 20 نوفمبر 2014 .
  15. ↑ "نبذة عنا" . Let's Encrypt. مؤرشف من الأصل بتاريخ 10-06-2015 . تم الاطلاع عليه بتاريخ 07-06-2015 .
  16. ↑ "إحصاء شهادات SSL - Netcraft" . news.netcraft.com . 13 مايو 2015. مؤرشف من الأصل بتاريخ 16 مايو 2015.
  17. ↑ "إحصائيات استخدام سلطات شهادات SSL للمواقع الإلكترونية، ديسمبر 2025 - W3Techs" . w3techs.com .
  18. ↑ "المتطلبات الأساسية لإصدار وإدارة الشهادات الموثوقة علنًا، الإصدار 1.2.3" (ملف PDF) . مؤرشف (PDF) من الأصل بتاريخ 23 مارس 2015. تم الاطلاع عليه بتاريخ 20 مارس 2015 .
  19. ↑ "CA/الممارسات المحظورة أو الإشكالية - MozillaWiki" . wiki.mozilla.org . مؤرشف من الأصل بتاريخ 21-07-2017 . تم الاطلاع عليه بتاريخ 06-07-2017 .
  20. ↑ "أسئلة وأجوبة حول بروتوكول SSL - الأسئلة المتكررة - Rapid SSL" . www.rapidssl.com . مؤرشف من الأصل بتاريخ 2015-02-06.
  21. ↑ زوسمان، مايك (2009). لم تُوجّه اتهامات جنائية: اختراق البنية التحتية للمفاتيح العامة (ملف PDF) . مؤتمر DEF CON 17. لاس فيغاس. مؤرشف (ملف PDF) من الأصل بتاريخ 15 أبريل 2013.
  22. ↑ «أنشأ رجل فنلندي حساب بريد إلكتروني بسيطًا هذا - وحصل على شهادة أمان من مايكروسوفت» . tivi.fi. ١٨ مارس ٢٠١٥. مؤرشف من الأصل بتاريخ ٨ أغسطس ٢٠١٥.
  23. ↑ "مسؤوليات جهة إصدار الشهادات" . مؤرشف من الأصل بتاريخ 12 فبراير 2015. تم الاطلاع عليه بتاريخ 12 فبراير 2015 .
  24. ↑ "عالم الشبكات" . 17 يناير 2000.
  25. ↑ التشفير التطبيقي وأمن الشبكات: المؤتمر الدولي الثاني، ACNS 2004، جبل هوانغشان، الصين، 8-11 يونيو 2004. وقائع المؤتمر . سبرينغر. يونيو 2004. ISBN 9783540222170.
  26. ↑ دليل مختصر لإدارة دورات حياة الشهادات . Realtimepublishers.com. 2006. ISBN 9781931491594.
  27. ↑ "التوقيعات والسجلات الإلكترونية" (ملف PDF) . مؤرشف (ملف PDF) من الأصل بتاريخ 2016-03-04 . تم الاطلاع عليه بتاريخ 2014-08-28 .
  28. ↑ "شفافية الشهادات" . مؤرشف من الأصل بتاريخ 1 نوفمبر 2013. تم الاطلاع عليه بتاريخ 3 نوفمبر 2013 .
  29. ↑ ب. لوري؛ أ. لانغلي؛ إ. كاسبر (يونيو 2013). شفافية الشهادات . فريق عمل هندسة الإنترنت . doi : 10.17487/RFC6962 . ISSN 2070-1721 . RFC 6962 . تجريبي.
  30. ↑ سميث، ديكنسون وسيمونز 2020 ، ص. 1.
  31. 1 2 شيفر، سانت أندريه وفوساتي 2022 ، 7.5. إلغاء الشهادة.
  32. ↑ تشونغ وآخرون 2018 ، ص. 3.
  33. ↑ سميث، ديكنسون وسيمونز 2020 ، ص. 10.
  34. ^ لاريش وآخرون. 2017 ، ص. 542.
  35. ↑ سميث، ديكنسون وسيمونز 2020 ، ص. 1-2.
  36. ↑ «تشكيل مجلس قوة متعدد البائعين لمعالجة قضايا الشهادات الرقمية» . عالم الشبكات . 14 فبراير 2013. مؤرشف من الأصل في 28 يوليو 2013.
  37. ↑ "توحيد هيئات إصدار الشهادات الرئيسية باسم أمن بروتوكول SSL" . دارك ريدينج . 14 فبراير 2013.{{cite web}}: CS1 maint: deprecated archiveal service ( link )
  38. ↑ "مؤسس منتدى CA/Browser" . 3 ديسمبر 2007. مؤرشف من الأصل في 23 أغسطس 2014. تم الاطلاع عليه في 23 أغسطس 2014 .
  39. ↑ "منتدى CA/المتصفح" . مؤرشف من الأصل بتاريخ 12-05-2013 . تم الاطلاع عليه بتاريخ 23-04-2013 .
  40. ↑ ويلسون، ويلسون. "تاريخ منتدى CA/Browser" (ملف PDF) . DigiCert. مؤرشف (ملف PDF) من الأصل بتاريخ 12 مايو 2013. تم الاطلاع عليه بتاريخ 23 أبريل 2013 .
  41. ↑ "المتطلبات الأساسية" . منتدى CAB. 4 سبتمبر 2013. مؤرشف من الأصل في 7 يناير 2014. تم الاطلاع عليه في 14 أبريل 2017 .
  42. ↑ "سياسة متجر الجذر لموزيلا" . موزيلا. مؤرشف من الأصل في 15 أبريل 2017. تم الاطلاع عليه في 14 أبريل 2017 .
  43. ↑ "برنامج شهادة الجذر من Apple" . Apple. مؤرشف من الأصل في 20 مارس 2017. تم الاسترجاع في 14 أبريل 2017 .
  44. ↑ "منتدى كاليفورنيا/المتصفح يُقرّ اقتراعًا لتقليص مدة صلاحية شهادات SSL/TLS إلى 47 يومًا كحد أقصى" . بزنس واير . 14 أبريل 2025. تاريخ الاطلاع: 13 مايو 2025 .
  45. ↑ "CA-2001-04" . Cert.org. 31 ديسمبر 2001. مؤرشف من الأصل في 2 نوفمبر 2013. تم الاطلاع عليه في 11 يونيو 2014 .
  46. ↑ مايكروسوفت، المحدودة (21 فبراير 2007). "نشرة مايكروسوفت الأمنية MS01-017: شهادات رقمية خاطئة صادرة عن VeriSign تُشكّل خطر انتحال الهوية" . مؤرشفة من الأصل بتاريخ 26 أكتوبر 2011. تم الاطلاع عليها بتاريخ 9 نوفمبر 2011 .
  47. ↑ سيلتزر، لاري. "بائع شهادات SSL يبيع شهادة CSSL لموقع Mozilla.com لشخص ما" . eWeek . تم الاطلاع عليه بتاريخ 5 ديسمبر 2021 .
  48. ↑ برايت، بيتر (28 مارس 2011). "هاكر إيراني مستقل يعلن مسؤوليته عن اختراق كومودو" . آرس تكنيكا. مؤرشف من الأصل في 29 أغسطس 2011. تم الاطلاع عليه بتاريخ 1 سبتمبر 2011 .
  49. ↑ برايت، بيتر (30 أغسطس 2011). "شهادة احتيالية أخرى تثير نفس التساؤلات القديمة حول سلطات إصدار الشهادات" . آرس تكنيكا. مؤرشف من الأصل في 12 سبتمبر 2011. تم الاطلاع عليه في 1 سبتمبر 2011 .
  50. ↑ ليدن، جون (2011-09-06). "داخل 'عملية الزنبق الأسود': تحليل اختراق ديجي نوتار" . ذا ريجستر . مؤرشف من الأصل في 2017-07-03.
  51. ↑ «أصدرت شركة Trustwave شهادة وسيطة» . The H Security . 2012-02-07. مؤرشف من الأصل في 2012-03-13 . تم الاطلاع عليه في 2012-03-14 .
  52. ↑ شرح هجوم تصادم برمجية Flame الخبيثة | مدونة مركز استجابة أمن مايكروسوفت | msrc.microsoft.com . تاريخ الاسترجاع: 13 أكتوبر 2023 .
  53. ↑ غودين، دان (7 يونيو 2012). "اختراق في عالم التشفير يُظهر أن فليم صُممت على يد علماء عالميين" . آرس تكنيكا . تاريخ الاسترجاع: 13 أكتوبر 2023 .
  54. ↑ فيشر، دينيس (23 مارس 2015). "جهة إصدار شهادات جوجل غير مصرح بها مرتبطة بمسجل صيني" . ثريت بوست . تم الاطلاع عليه بتاريخ 27 سبتمبر 2023 .
  55. ↑ لانغلي، آدم (23 مارس 2015). "الحفاظ على أمان الشهادات الرقمية" . مدونة جوجل للأمان . تم الاطلاع عليه بتاريخ 27 سبتمبر 2023 .
  56. ↑ لوينثال، توم (31 مارس 2015). "مركز معلومات العملات الرقمية الصيني يصدر شهادات مزورة في انتهاك خطير لثقة العملات الرقمية" . لجنة حماية الصحفيين . تاريخ الاسترجاع: 13 أكتوبر 2023 .
  57. ↑ أوزبورن، تشارلي. "شركة سيمانتك تفصل موظفين لإصدارهم شهادات جوجل غير مصرح بها - زد نت" . زد نت . مؤرشف من الأصل بتاريخ 2016-10-02.
  58. ↑ "اكتشاف شهادات رقمية غير مصرح بها من جوجل" . linkedin.com . 12 أغسطس 2014.
  59. ↑ «في أعقاب إصدار شهادات غير مصرح بها من قبل مركز المعلومات الوطني الهندي لشهادات المحاسبين القانونيين، هل لا يزال من الممكن اعتبار هيئات المحاسبين القانونيين الحكومية «أطرافًا ثالثة موثوقة»؟» casecurity.org . 24 يوليو 2014. مؤرشف من الأصل في 3 أكتوبر 2016.

المراجع