X509_verify_cert و X509_STORE_CTX_verify¶

X509_verify_cert() تحاول بناء والتحقق من سلسلة شهادات للشهادة الهدف المعينة في ctx. سياق التحقق، من النوع X509_STORE_CTX، يجب أولاً إنشاؤه باستخدام X509_STORE_CTX_new(3) وتهيئته باستخدام X509_STORE_CTX_init(3). يحمل الشهادة الهدف، مخزن الثقة، كومة اختيارية من الشهادات غير الموثوقة التي قد تساعد في بناء السلسلة، معاملات تحقق مثل الأعلام والغرض من التحقق، دالة استدعاء تحقق اختيارية، وبعد الاستدعاء، نتيجة التحقق.

يمكن استخدام X509_STORE_CTX لتحقق واحد فقط. استدعاء X509_verify_cert() مرة ثانية على نفس السياق دون إعادة تهيئته يفشل بقيمة إرجاع سالبة، وX509_STORE_CTX_get_error(3) يعيد لاحقاً X509_V_ERR_INVALID_CALL.

عندما يكون الهدف شهادة، تؤدي الدالة الخطوات التالية بالترتيب. الخطوة الأولى التي تفشل توقف التحقق، إلا حيث تتنازل دالة استدعاء التحقق صراحة عن الخطأ (انظر "دالة استدعاء التحقق" أدناه):

1.

بناء السلسلة. بدءاً من الشهادة الهدف، تبحث آلية التحقق عن مُصدِر للشهادة الموجودة حالياً في أعلى السلسلة، مستمدة المرشحين من كومة ctx غير الموثوقة ومن مخزن الثقة. افتراضياً، يكون البحث غير الموثوق أولاً: تُفحص الكومة غير الموثوقة قبل مخزن الثقة. تعيين X509_V_FLAG_TRUSTED_FIRST على معاملات تحقق ctx يعكس هذا. عندما يفشل بحث غير موثوق أولاً في الوصول إلى مرساة ثقة وX509_V_FLAG_NO_ALT_CHAINS غير معين، يُعاد البحث ببادئات غير موثوقة أقصر تدريجياً في محاولة لإيجاد مسار موثوق بديل. طول السلسلة محدود بحد العمق المُهيأ (انظر X509_VERIFY_PARAM_set_depth(3))؛ تجاوزه يُنتج X509_V_ERR_CERT_CHAIN_TOO_LONG. إذا أمكن أكثر من سلسلة واحدة، تُؤخذ واحدة فقط.

فشل بناء سلسلة إلى مرساة ثقة يُنتج خطأ مثل X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT، X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY، X509_V_ERR_SELF_SIGNED_CERT_IN_CHAIN، X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT، أو X509_V_ERR_CERT_CHAIN_TOO_LONG.

2.

التحقق من امتدادات الشهادة وفق RFC 5280، بما في ذلك القيود الأساسية، استخدام المفتاح والغرض من التحقق المُعين عبر X509_VERIFY_PARAM_set_purpose(3).

3.

فحوصات مستوى الأمان ضد مستوى الاستيثاق المُهيأ، تغطي أحجام مفاتيح المُصدِر (X509_V_ERR_CA_KEY_TOO_SMALL) وقوة خوارزمية التوقيع (X509_V_ERR_CA_MD_TOO_WEAK). يُفحص مفتاح الورقة بشكل منفصل قبل بدء بناء السلسلة (X509_V_ERR_EE_KEY_TOO_SMALL).

4.

فحوصات الهوية ضد أي أسماء مضيفين أو عناوين بريد إلكتروني أو عناوين IP مُهيأة على معاملات التحقق (X509_VERIFY_PARAM_set1_host(3) وما يتصل بها).

5.

فحوصات الإلغاء عبر CRLs وعند التهيئة، OCSP. مجموعة الفحوصات المُنفذة تُتحكم بها أعلام مثل X509_V_FLAG_CRL_CHECK وX509_V_FLAG_CRL_CHECK_ALL.

6.

فحوصات التوقيع وفترة الصلاحية على كل شهادة في السلسلة، متنقلاً من مرساة الثقة نزولاً إلى الهدف. توقيع الشهادة الختامية للسلسلة غير مُتحقق منه: تُؤخذ الثقة من وجودها في مخزن الثقة بدلاً من توقيعها. ينطبق هذا على مرساة ثقة ذاتية التوقيع تقليدية وعندما يكون X509_V_FLAG_PARTIAL_CHAIN سارياً، على وسيط غير ذاتي التوقيع مُرقى إلى حالة مرساة. X509_V_FLAG_CHECK_SS_SIGNATURE يطلب التحقق من التوقيع الذاتي على مُنهٍ ذاتي التوقيع؛ ليس له تأثير عندما يكون المُنهٍ شهادة غير ذاتية التوقيع. تُفحص فترات الصلاحية على كل شهادة، بما في ذلك المُنهٍ.

7.

التحقق من قيود الاسم وفق RFC 5280 قسم 4.2.1.10؛ انظر NAME_CONSTRAINTS_check(3) لتفاصيل البدائية المطابقة وأنواع الأسماء العامة التي تغطيها.

8.

التحقق من مسار RFC 3779 لامتدادات تفويض رقم AS وعنوان IP، مُنفذ افتراضياً ما لم يُبنَ OpenSSL مع no-rfc3779.

9.

التحقق من سياسة الشهادة، مُنفذ فقط عندما يكون X509_V_FLAG_POLICY_CHECK معيناً.

عدة قيم X509_V_FLAG_* تعدل سلوك هذه الفحوصات؛ أُطلق على ممثلين منها في الخطوة ذات الصلة أعلاه، لكن القائمة هناك ليست شاملة. المجموعة الكاملة لأعلام التحقق، والتأثير الذي يملكه كل واحد، والدوال المستخدمة للاستعلام عنها وتعديلها موثقة في X509_VERIFY_PARAM_set_flags(3).

نادراً ما تستدعي التطبيقات X509_verify_cert() مباشرة. تُستدعى داخلياً بواسطة OpenSSL أثناء تحقق S/MIME وCMS وأثناء مصافحة TLS.

X509_STORE_CTX_verify() تتصرف بشكل مطابق لـ X509_verify_cert() باستثناء اختيار الشهادة الهدف: إذا لم يُعين هدف على ctx (انظر X509_STORE_CTX_set_cert(3)) والكومة غير الموثوقة غير فارغة، تُعتمد الشهادة الأولى في الكومة غير الموثوقة كهدف قبل بدء التحقق. إذا عُين هدف صراحة، تستخدمه X509_STORE_CTX_verify() ولا تستشير الكومة غير الموثوقة لهذا الغرض.

أهداف المفتاح العام الخام¶

عندما يكون هدف التحقق مفتاحاً عاماً خاماً بدلاً من شهادة (مُعين عبر X509_STORE_CTX_init_rpk(3))، تتحقق كلتا الدالتين من المفتاح العام الخام بدلاً من سلسلة شهادات. مجموعة الفحوصات الممكنة مُخفضة بشكل كبير: لا توجد امتدادات أو أسماء أو CRLs أو توقيعات للتحقق منها. يمكن استيثاق المفتاح العام الخام فقط عبر سجلات DANE TLSA، إما مُصنعة محلياً أو مُحصلة بواسطة التطبيق من DNS. يمكن إضافة سجلات DANE TLSA للمفتاح العام الخام عبر SSL_add_expected_rpk(3) أو SSL_dane_tlsa_add(3).

X509_build_chain¶

X509_build_chain() يبني سلسلة شهادات تبدأ من target، باستخدام نفس خوارزمية بناء السلسلة مثل X509_verify_cert() (انظر "X509_verify_cert و X509_STORE_CTX_verify" أعلاه). يستخدم داخليًا بنية X509_STORE_CTX مرتبطة بسياق المكتبة libctx وسلسلة استعلام الخصائص propq، وكلاهما قد يكون NULL. دور certs يعتمد على store:

• إذا كان store غير NULL، يُعامل certs كقائمة اختيارية من الشهادات الوسيطة غير الموثوقة التي قد تساعد في إكمال السلسلة، ويجب أن تصل السلسلة إلى مرساة ثقة موجودة في store. إذا تعذر بناء سلسلة إلى مرساة ثقة، تفشل الدالة وتُرجع NULL.
• إذا كان store هو NULL، يُثبَّت certs ككومة موثوقة للسياق الداخلي (انظر X509_STORE_CTX_set0_trusted_stack(3)). في هذا الوضع، تبني الدالة السلسلة قدر ما تستطيع ولكنها لا تتطلب الوصول إلى مرساة: إذا فشل بناء السلسلة في منتصف الطريق، تُرجع السلسلة الجزئية المبنية حتى الآن.

لأن X509_STORE_CTX الداخلي يُخصص ويُحرر داخل X509_build_chain()، فإن أعلام سياسة البحث مثل X509_V_FLAG_TRUSTED_FIRST و X509_V_FLAG_NO_ALT_CHAINS وحد العمق المكوَّن تأخذ دائمًا قيمها المبدئية، ولا يُبلَّغ عن رمز X509_V_ERR_* المحدد الذي تسبب في فشل بناء السلسلة: تشير الدالة فقط إلى النجاح أو الفشل من خلال قيمة الإرجاع (وعندما يكون store هو NULL، قد تُرجع أيضًا سلسلة جزئية).

عند النجاح، تبدأ الكومة المُرجعة بـ target مُشار إليه حديثًا يليه شهادات المُصدِر التي وُجدت. تُضمَّن شهادة موقعة ذاتيًا في أعلى السلسلة في الكومة المُرجعة عندما يكون with_self_signed هو 1، أو عندما تتكون السلسلة فقط من target (مثلًا لأن target نفسه موقَّع ذاتيًا أو لم يُعثر على مُصدِر إضافي). عندما تحتوي السلسلة على أكثر من عنصر واحد ويكون with_self_signed هو 0، يُحذف الجزء العلوي الموقَّع ذاتيًا من النتيجة.

المتصل مسؤول عن تحرير الكومة المُرجعة.

عند استدعاء الاستدعاء¶

يوجد نمطان متميزان للاستدعاء:

إخطار الخطأ (ok = 0)

يُستدعى الاستدعاء مع ضبط ok على 0 في كل مرة يفشل فيها فحص. قبل الاستدعاء، تسجل آلية التحقق رمز X509_V_ERR_* الذي يصف الفشل على ctx، وبالنسبة لأخطاء مستوى الشهادة، تسجل أيضًا العمق الذي اكتُشف فيه الخطأ والشهادة المعنية. يفحص الاستدعاء هذه عبر X509_STORE_CTX_get_error(3)، X509_STORE_CTX_get_error_depth(3)، و X509_STORE_CTX_get_current_cert(3). الأخطاء المتعلقة بـ CRL و OCSP تُحدِّث رمز الخطأ فقط؛ يحتفظ العمق والشهادة الحالية بقيمهما من سياق سابق.

إخطار النجاح لكل شهادة (ok = 1)

أثناء مرور التوقيع والصلاحية، بعد فحص كل شهادة في السلسلة بنجاح، يُستدعى الاستدعاء مع ضبط ok على 1. تصف الشهادة الحالية والمُصدِر الحالي وعمق الخطأ (القابلة للاستعلام على التوالي عبر X509_STORE_CTX_get_current_cert(3)، X509_STORE_CTX_get0_current_issuer(3)، و X509_STORE_CTX_get_error_depth(3)) الشهادة التي قُبلت للتو. قد يستخدم الاستدعاء هذا لتسجيل التقدم، لكن يجب أن يُرجع قيمة غير صفرية، وإلا يُوقف التحقق.

تتحكم قيمة إرجاع الاستدعاء's في التحقق اللاحق:

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

الأخطاء اللاصقة¶

عندما يتنازل الاستدعاء الراجع عن خطأ بإرجاع قيمة غير صفرية، يُعامل الفحص الأساسي كأنه ناجح لأغراض تدفق التحكم، لكن رمز الخطأ المسجل على ctx لا يُعاد ضبطه إلى X509_V_OK. لذلك، فإن العودة الناجحة اللاحقة من X509_verify_cert() لا تعني أن X509_STORE_CTX_get_error(3) سيعيد X509_V_OK: فقد يحتفظ بآخر رمز خطأ تم التنازل عنه. هذا مقصود. فقط الاستدعاء الراجع نفسه مسموح له باستبدال رمز الخطأ، عبر X509_STORE_CTX_set_error(3)، وعلى مسؤوليته الخاصة فقط.

المخاطر¶

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

• التنازلات الشاملة. الاستدعاء الراجع الذي يعيد 1 دون شروط يحول X509_verify_cert() إلى "قبول أي شيء" ويكون خاطئًا دائمًا تقريبًا خارج التشخيصات. افحص رمز الخطأ عبر X509_STORE_CTX_get_error(3) وتنازل فقط عن الأكواد المحددة التي تنويها.
• إفشال إشعار النجاح. نظرًا لأن الاستدعاء الراجع يُستدعى أيضًا مع ok = 1، فإن الاستدعاء الراجع الذي يعيد 0 بالخطأ في تلك الحالة يتسبب في فشل التحقق حتى مع نجاح كل فحص. لا يمكن للمستدعي تمييز هذا عن فشل حقيقي بناءً على قيمة الإرجاع وحدها.
• مسح رمز الخطأ. قاعدة الخطأ اللاصق موجودة بحيث يبقى الخطأ المتنازل عنه مرئيًا للمستدعي بعد عودة التحقق. الاستدعاء الراجع الذي يستدعي X509_STORE_CTX_set_error(3) مع X509_V_OK يخفي هذه المعلومات ويمكنه أيضًا إخفاء خطأ لاحق إذا استُدعي الاستدعاء الراجع مرة أخرى قبل اكتمال التحقق.
• تغيير سياق التحقق. يكون X509_STORE_CTX نشطًا أثناء الاستدعاء الراجع: دوال التحقق تقرأ بنشاط سلسلته ومعاملاته وحالته الأخرى. استدعاء دوال تغيير السياق من داخل الاستدعاء الراجع -- على سبيل المثال، استبدال السلسلة المُتحقق منها عبر X509_STORE_CTX_set0_verified_chain(3)، أو تبديل مخزن الثقة أو المكدس غير الموثوق، أو تغيير أعلام التحقق أو العمق أو الغرض أو الهدف -- يمكن أن يفسد التحقق الجاري، أو ينتج سلوكًا غير متناسق بين خطوات لاحقة من خط الأنابيب، أو، في حالة السلسلة المُتحقق منها، يتسبب في استخدام بعد التحرير. المعدِّلات الوحيدة المعقولة من داخل الاستدعاء الراجع هي المحددات المتعلقة بالخطأ (X509_STORE_CTX_set_error(3)، X509_STORE_CTX_set_error_depth(3)، X509_STORE_CTX_set_current_cert(3))، وحتى تلك يجب استخدامها باعتدال (انظر "الأخطاء اللاصقة").
• عمل ثقيل في الاستدعاء الراجع. يكون الاستدعاء الراجع على المسار الساخن لكل فحص شهادة؛ العمل المكلف المنفذ هناك سيُبطئ كل مصافحة TLS أو تحقق S/MIME يستخدم السياق المحيط.
• الثقة بالعمق وحده. عمق الخطأ، من X509_STORE_CTX_get_error_depth(3)، يسجل مكان اكتشاف الخطأ أثناء معالجة السلسلة، وليس موضع الشهادة في السلسلة النهائية. استشر دائمًا X509_STORE_CTX_get_current_cert(3) بالإضافة إلى العمق عند اتخاذ قرار التنازل.
• الهشاشة فيما يتعلق بترتيب الفحص. مجموعة الأخطاء التي يلاحظها الاستدعاء الراجع، والترتيب الذي يلاحظها به، يعتمدان على الترتيب الداخلي الذي تُنفذ به فحوصات التحقق. عندما تحتوي شهادة على أكثر من مشكلة واحدة، فقط الفحص الأول الذي يكتشف مشكلة يتسبب في استدعاء الاستدعاء الراجع لتلك الشهادة؛ لا تُصل الفحوصات اللاحقة إلا إذا تنازل الاستدعاء الراجع عن الخطأ السابق. هذا الترتيب تفصيل تنفيذي وليس جزءًا من الواجهة البرمجية المستقرة: إعادة هيكلة تعيد ترتيب الفحوصات الداخلية دون تغيير عقد النجاح/الفشل الثنائي لـ X509_verify_cert() قد تغير مع ذلك أي رمز X509_V_ERR_* يراه الاستدعاء الراجع، أو ما إذا كان رمز معين يُبلغ عنه أصلًا. الاستدعاءات الراجعة التي تتفرع على رمز خطأ محدد يُبلغ عنه، أو التي تفترض أن الفحوصات السابقة قد صفت بالفعل شروطًا معينة، يمكنها بالتالي تغيير السلوك بصمت عبر إصدارات OpenSSL. اكتب الاستدعاءات الراجعة دفاعيًا: أعد جلب رمز الخطأ والشهادة الحالية عبر X509_STORE_CTX_get_error(3) و X509_STORE_CTX_get_current_cert(3) من جديد في كل استدعاء، وعامل "هذا الرمز لا يظهر أبدًا" كافتراض قد يُبطل. بشكل أكثر جوهرية، نظرًا لأن مجموعة وترتيب إشعارات الأخطاء ليس عقدًا مستقرًا، لا يمكن الاعتماد على الاستدعاء الراجع لملاحظة أي شرط أو تسلسل شروط معين؛ هذا يجعله آلية غير سليمة لفرض أو تعديل سياسة الأمان. استخدام الاستدعاء الراجع للتحقق لتغيير نتائج التحقق -- للتنازل عن الأخطاء، أو لحقن قبول شرطي، أو لبوابة السلوك على رمز X509_V_ERR_* محدد يُبلغ عنه -- غير مشجع بالتالي في كود الإنتاج. احتفظ بالاستدعاء الراجع لأغراض التشخيص والتسجيل، حيث التغييرات المستقبلية في الأخطاء التي تظهر، أو في أي ترتيب، ليست ذات صلة بالأمان.

الاستدعاء الراجع الافتراضي لا يتنازل عن شيء وهو الخيار الآمن؛ إنه السلوك الصحيح لجميع استخدامات الإنتاج تقريبًا.