الخلاصة
- يحمل امتداد TLS 1.3 المسمى
certificate_authoritiesأسماء مميزة X.501 مرتبة ومشفرة بصيغة DER. تساعد هذه الأسماء الطرف المقابل على اختيار شهادة، لكنها لا تحمل شهادة سلطة التصديق أو مفتاحاً موثوقاً أو مساراً جرى التحقق منه أو إذناً تطبيقياً. - قد يرسله العميل في ClientHello لتوجيه اختيار شهادة الخادم، وقد يرسله الخادم في CertificateRequest لتوجيه اختيار شهادة العميل. تشابه البنية لا يوحد اتجاه القرار ولا الجهة المسؤولة عنه.
- السجل القابل للتدقيق يفصل بين إنشاء القائمة، واختيار بيانات الاعتماد، والتحقق من مسار الشهادة، وربط الهوية الموثقة بصلاحية داخل التطبيق.
نجاح تقني يعقبه رفض صحيح
لدى عميل mTLS أكثر من شهادة. تقارن المكتبة أسماء جهات الإصدار بالقائمة التي قدمها الخادم، فتختار شهادة مناسبة وتثبت امتلاك المفتاح الخاص. يبني الخادم مساراً إلى مرساة موجودة في مخزن التحقق الجاري ويقبله.
لا ينشئ ذلك حقاً داخل التطبيق. قد يشير SAN إلى مساحة أسماء أخرى، أو تكون عضوية المستأجر منتهية، أو لا يسمح الدور بقراءة السر أو تغيير المسار. التحقق من المسار يثبت بيانات اعتماد ضمن قيود محددة؛ أما الإذن فيحكم الفعل المطلوب.
لهذا لا يصلح حقل مثل ca_allowed=true حكماً أمنياً. فهو لا يبين هل شوهد اسم فقط، أم اختيرت شهادة، أم قبلت مرساة بعينها، أم سمح التطبيق بالعملية. يمكن أن تختلف النتائج الأربع من دون أي تناقض بروتوكولي.
الاسم المميز ليس مفتاح الثقة
خصصت IANA القيمة 47 لامتداد certificate_authorities. وتعرف RFC 9846 محتواه بأنه متجه غير فارغ من أسماء X.501 المميزة المشفرة بصيغة DER. قد يشير الاسم إلى مرساة ثقة مرغوبة أو إلى سلطة تصديق تابعة، ويستخدم لتوجيه الاختيار.
لا يتضمن الاسم المفتاح العام للسلطة أو قيودها أو سياساتها أو السجل الفعلي في مخزن الثقة. يمكن لشهادتي سلطة تصديق أن تحملا subject واحداً ومفتاحين مختلفين. ويمكن استخراج subject من شهادة لا تملك أصلاً صلاحية سلطة تصديق. لذلك لا يحدد تطابق الاسم المفتاح الذي يثق به المرسل.
يتطلب التحقق وفق RFC 5280 مرساة فعلية ويفحص التواقيع والفترات الزمنية والقيود الأساسية وقيود الأسماء واستعمالات المفتاح ومدخلات السياسة. وقد تغيب المرساة عن السلسلة المنقولة لأنها وزعت مستقلة. لا يعوض الاسم أياً من هذه الفحوص.
يثبت الوجود فقط أن المرسل أعلن هذا الاسم المشفر في سياق الرسالة. ولا يثبت قبول كل شهادة صادرة تحته. كما أن الغياب لا يثبت انعدام الثقة كلياً؛ فقد تكون القائمة مختصرة للخصوصية أو الحجم أو لفئة محددة من بيانات الاعتماد.
اتجاهان يكشفان معلومات مختلفة
عندما يضع العميل القائمة في ClientHello، فهو يساعد الخادم على اختيار شهادته وسلسلة بديلة محتملة. وعندما يضعها الخادم في CertificateRequest، فهو يوجه العميل إلى شهادة مصادقة مناسبة. يتبدل منشئ القائمة ومستهلكها بين الحالتين.
تنبه وثائق OpenSSL إلى أن أسماء سلطات التصديق الصادرة من العميل تصل إلى الخادم كنص ظاهر. نسخ مخزن ثقة مؤسسة بكامله قد يكشف أسماء داخلية وبنية PKI. ومن الجهة الأخرى، تزيد قائمة الخادم الكبيرة حجم المصافحة وكلفة التحليل وقد تغير سلوك الاختيار.
لا يستخدم TLS 1.3 امتداد trusted_ca_keys القديم. وقد يحمل ClientHello المتوافق مع نسخ أقدم إشارات قديمة أيضاً؛ لذا يجب أن يسجل الرصد النسخة المتفاوض عليها والرسالة والاتجاه ورقم الامتداد معاً.
الاختيار تقاطع قيود لا بحث عن اسم وحيد
اسم سلطة التصديق عامل واحد فقط. تدخل أيضاً signature_algorithms، وأحياناً signature_algorithms_cert، ونوع المفتاح وتوافر المفتاح الخاص وخوارزمية توقيع الشهادة وKey Usage وEKU وSNI ومرشحات OID والصلاحية والسلاسل التي يمكن بناؤها محلياً.
أسباب استبعاد المرشحين دليل أساسي. قد يطابق الاسم لكن يفشل EKU، أو تتوافر الخوارزمية من دون المفتاح الخاص، أو تعجز السلسلة عن بلوغ السلطة المطلوبة. بصمة الشهادة النهائية وحدها لا تشرح القرار.
إذا لم يجد العميل شهادة مناسبة، يحدد TLS 1.3 نتيجة صريحة: رسالة Certificate فارغة. يستطيع الخادم المتابعة وفق ملفه التشغيلي أو الرفض بـ certificate_required. الفراغ حقيقة قابلة للملاحظة، وليس عيباً ينبغي إخفاؤه بهوية غير مرتبطة.
قائمة الإعلان منفصلة عن مخزن التحقق
يفصل OpenSSL بين واجهات ضبط أسماء سلطات التصديق المرسلة للطرف الآخر وواجهات تحميل الشهادات الموثوقة. إعداد القائمة لا يجعل الجهات المذكورة موثوقة؛ مواقع التحقق ومراسي الثقة تحمل بصورة مستقلة.
يكشف اختبار سلبي هذا الحد بوضوح: أعلن subject لسلطة ما من دون وضع مفتاحها في مخزن التحقق. قد يختار العميل سلسلة مطابقة، بينما يرفضها الخادم على نحو صحيح بـ unknown_ca. ويمكن عكس الحالة أيضاً، فتكون سلسلة موثوقة محلياً من دون أن يظهر اسمها في القائمة.
قد يغير التحديث الحي جانباً واحداً فقط. لذلك تحتاج القائمة والمخزن إلى جيل وهاش ووقت تفعيل مستقل، وإلى ربط كل اتصال بالجيل الذي نفذه فعلاً.
كما أن أداة OpenSSL لتحميل أسماء سلطات العميل تستخرج subjects ولا تقصر الإدخال على شهادات سلطات التصديق. نجاح قراءة الملف يثبت التحليل، لا أهلية كل إدخال للثقة.
بعد المصادقة يبدأ قرار الصلاحية
بعد وصول السلسلة، يعالج المدقق المسار والمرساة والقيود والغرض. ثم تفسر قواعد البروتوكول SAN وغيره من دلالات الهوية. ويبقى على التطبيق ربط الهوية المعيارية بمستأجر وحساب وعبء عمل ودور وفعل.
قد يعتمد الربط على صيغة SAN دقيقة، أو زوج issuer–subject، أو OID للسياسة، أو سجل التحاق، أو استحقاق خارجي. لذلك يمكن رفض شهادة صحيحة تماماً لأسباب صلاحية صحيحة تماماً.
ولا يستطيع العميل الاستنتاج من اكتمال المصافحة وحده أن الخادم يعده مصادقاً عليه للعملية المطلوبة. قد يلزم جواب صريح من طبقة التطبيق. اكتمال TLS ليس تفويضاً تلقائياً.
توفر OpenSSL وGnuTLS وBoringSSL callbacks للاختيار ووظائف منفصلة للتحقق. وجود callback في الإعداد يثبت الإمكان فقط؛ أما استدعاء مؤرخ مرتبط بالاتصال فيثبت التنفيذ. وتقيد BoringSSL عمر بعض مشاهد أسماء CA بنطاق callback، لذا يجب نسخ DER أو تجزئته ضمن ذلك النطاق.
في استئناف TLS 1.3 بواسطة PSK قد لا يحدث CertificateRequest جديد في المصافحة الرئيسية. إذا لم يجر تبادل شهادة، فلا يجوز للقياس أن يدعي قراراً جديداً بشأن قائمة CA أو هوية العميل.
اختبارات تمنع الإشارة من تجاوز حدودها
أعلن DN من دون مفتاح موثوق مقابل. أنشئ سلطتي تصديق تحملان subject واحداً وثق بواحدة فقط. قدم شهادة يطابق اسمها لكن تفشل في EKU أو الصلاحية أو السياسة أو توافر المفتاح، واحفظ سبب كل استبعاد.
دع المسار ينجح ثم ارفض subject عند حد المستأجر. أزل جميع بيانات الاعتماد الملائمة وراقب Certificate فارغة وقرار الخادم اللاحق. غير القائمة والمخزن كل واحد على حدة وتحقق من أن إنذار الانحراف يسمي الجيل المختلف.
التقط ClientHello لقياس كشف معلومات المؤسسة، واختبر متجهات كبيرة، واستأنف جلسة من دون زيادة عداد المصادقة الجديدة. افصل حالات configured وinvoked وselected وverified وauthorized.
يتكون سلم الدليل من: اسم معلن، مجموعة مرشحين، شهادة مختارة، إثبات امتلاك المفتاح، مسار متحقق منه، هوية مفسرة، وفعل مسموح. لكل درجة سلطة مستقلة.
المصادر
- https://www.rfc-editor.org/rfc/rfc9846.html
- https://www.rfc-editor.org/rfc/rfc5280.html
- https://www.rfc-editor.org/rfc/rfc6066.html
- https://www.rfc-editor.org/rfc/rfc9525.html
- https://www.rfc-editor.org/rfc/rfc9325.html
- https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml
- https://docs.openssl.org/3.3/man3/SSL_CTX_set0_CA_list/
- https://docs.openssl.org/3.0/man3/SSL_load_client_CA_file/
- https://docs.openssl.org/3.6/man3/SSL_CTX_load_verify_locations/
- https://docs.openssl.org/3.6/man3/SSL_CTX_set_client_cert_cb/
- https://gnutls.org/manual/html_node/Using-a-callback-to-select-the-certificate-to-use.html
- https://gnutls.org/manual/html_node/Verifying-a-certificate-in-the-context-of-TLS-session.html
- https://boringssl.googlesource.com/boringssl/+/refs/heads/master/include/openssl/ssl.h
- https://heng.lu/running-code-primary-the-patch-needed-to-preserve-the-internet-original-design/
إحاطة الأعضاء
سياق أعمق للملف الشخصي
سجّل الدخول بمستوى العضوية المناسب لفتح الإحاطة الكاملة وملاحظات المصادر.
للدائرة الاستراتيجية فقط
الدائرة الاستراتيجية
مفتوح لجميع القراء. افتح إحاطات الملف الشخصي بعد الانضمام وتسجيل الدخول.
انضم إلى الدائرة الاستراتيجيةلأعضاء تحالف القيادات فقط
تحالف القيادات
لأصحاب الأصول الفكرية المؤهلين وللإدارة؛ سجّل الدخول للوصول إلى إحاطات التحالف.
انضم إلى تحالف القيادات
