إخفاقات تأكيد الاتصال عبر بروتوكول أمان طبقة النقل (TLS)/طبقة المقابس الآمنة

أنت تعرض مستندات Apigee Edge.
انتقل إلى مستندات Apigee X. معلومات

المشكلة

يحدث إخفاق تأكيد اتصال بروتوكول أمان طبقة النقل أو طبقة المقابس الآمنة عندما لا يتمكن العميل والخادم من إجراء اتصال باستخدام بروتوكول TLS/SSL. عند حدوث هذا الخطأ في Apigee Edge، يعمل البرنامج تطبيق حالة HTTP 503 مع الرسالة الخدمة غير متوفرة. إِنْتَ سيظهر هذا الخطأ بعد أي طلب بيانات من واجهة برمجة التطبيقات يحدث فيه إخفاق تأكيد اتصال بروتوكول أمان طبقة النقل (TLS)/طبقة المقابس الآمنة (SSL).

رسائل الخطأ

HTTP/1.1 503 Service Unavailable

يمكنك أيضًا مشاهدة رسالة الخطأ هذه عند إخفاق تأكيد اتصال بروتوكول أمان طبقة النقل (TLS)/طبقة المقابس الآمنة (SSL):

Received fatal alert: handshake_failure

الأسباب المحتملة

إن بروتوكول أمان طبقة النقل (TLS) الذي يسبقه SSL) هو تقنية الأمان القياسية إنشاء رابط مشفر بين خادم ويب وعميل ويب، مثل متصفح أو تطبيق. تأكيد الاتصال هي عملية تتيح لعميل وخادم طبقة النقل الآمنة (TLS)/طبقة المقابس الآمنة (SSL) إنشاء مجموعة من البيانات السرية والمفاتيح التي يمكنهم التواصل معها. وأثناء هذه العملية، يجري العميل والخادم ما يلي:

  1. وافِق على إصدار البروتوكول المطلوب استخدامه.
  2. تحديد خوارزمية التشفير المراد استخدامها.
  3. مصادقة بعضها البعض من خلال تبادل الشهادات الرقمية والتحقق منها

إذا نجحت عملية تأكيد اتصال بروتوكول أمان طبقة النقل (TLS)/طبقة المقابس الآمنة (SSL)، فإن عميل بروتوكول أمان طبقة النقل (TLS)/طبقة المقابس الآمنة (SSL) ينقل البيانات إلى كل منهما بشكل آمن. وبخلاف ذلك، في حالة حدوث فشل في تأكيد اتصال بروتوكول أمان طبقة النقل (TLS)/طبقة المقابس الآمنة (SSL)، يتم إنهاء الاتصال ويقوم البرنامج تتلقى خطأ 503 Service Unavailable.

في ما يلي الأسباب المحتملة لتعذُّر تأكيد اتصال بروتوكول أمان طبقة النقل (TLS) أو طبقة المقابس الآمنة (SSL):

السبب الوصف مَن يمكنه تنفيذ خطوات تحديد المشاكل وحلّها
عدم تطابق البروتوكول البروتوكول الذي يستخدمه العميل غير متوافق مع الخادم. مستخدمو السحابة الإلكترونية الخاصة والعامة
عدم تطابق حزمة الرموز لا يدعم الخادم مجموعة التشفير التي يستخدمها العميل. مستخدمو السحابة الإلكترونية الخاصة والعامة
الشهادة غير صحيحة لا يتطابق اسم المضيف في عنوان URL الذي يستخدمه العميل مع اسم المضيف في الشهادة. بتخزينها في نهاية الخادم. مستخدمو السحابة الإلكترونية الخاصة والعامة
يتم تخزين سلسلة شهادات غير كاملة أو غير صالحة في نهاية العميل أو الخادم. مستخدمو السحابة الإلكترونية الخاصة والعامة
يرسل العميل شهادة غير صحيحة أو منتهية الصلاحية إلى الخادم أو من الخادم للعميل. مستخدمو السحابة الإلكترونية الخاصة والعامة
خادم مُفعَّل لإشارة اسم الخادم (SNI) تم تفعيل "مؤشر اسم الخادم" (SNI) في خادم الخلفية. ومع ذلك، لا يمكن للعميل التواصل مع خوادم SNI. مستخدمو Private Cloud فقط

البروتوكول عدم تطابق

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

التشخيص

  1. تحديد ما إذا كان الخطأ قد حدث في الشمال أو southbound. لمزيد من الإرشادات حول جعل هذا قرار، راجع تحديد مصدر المشكلة
  2. تشغيل tcpdump لجمع مزيد من المعلومات:
    • إذا كنت مستخدمًا خاصًا على السحابة الإلكترونية، يمكنك جمع tcpdump البيانات على العميل أو الخادم ذي الصلة. يمكن أن يكون العميل هو تطبيق العميل (للعمليات الواردة، أو الاتصالات باتجاه الشمال) أو الرسائل معالِج البيانات (للاتصالات الصادرة أو للاتصالات الجنوبية). يمكن أن يكون الخادم هو جهاز توجيه الحافة ( الواردة أو الاتصالات الواردة أو الشمالية) أو خادم الخلفية (بالنسبة إلى الاتصالات الصادرة أو تلك في منطقة جنوبية) استنادًا إلى قرارك من الخطوة 1.
    • إذا كنت من مستخدمي Cloud Public، يمكنك جمع tcpdump البيانات فقط على تطبيق العميل (للاتصالات الواردة أو للاتصالات الشمالية) أو خادم الخلفية (للاتصالات الصادرة أو الجنوبية)، لأنك لا يمكنه الوصول إلى جهاز توجيه Edge أو معالج الرسائل.
    tcpdump -i any -s 0 host IP address -w File name
    عرض بيانات tcpdump لمزيد من المعلومات حول استخدام tcpdump الأمر.
  3. تحليل بيانات tcpdump باستخدام أداة Wireshark أو أداة مشابهة
  4. فيما يلي تحليل نموذجي tcpdump باستخدام Wireshark:
    • في هذا المثال، حدث إخفاق تأكيد اتصال TLS/SSL بين معالج الرسائل خادم الخلفية (الاتصال الصادر أو الاتصال الجنوبي).
    • توضّح الرسالة رقم 4 في مخرجات tcpdump أدناه أنّ معالج الرسائل (المصدر) أرسل "العميل مرحبًا" إلى خادم الخلفية (الوجهة).

    • إذا نقرت على الرسالة Client Hello، يعني ذلك أنّ معالج الرسائل يستخدم خدمة بروتوكول TLSv1.2، كما هو موضح أدناه:

    • توضح الرسالة رقم 5 أن خادم الخلفية يعترف بعبارة "Client Hello" رسالة من معالج الرسائل.
    • يرسل خادم الخلفية تنبيهًا فادحًا : إغلاق الإشعار على الفور إلى معالج الرسائل (الرسالة رقم 6). وهذا يعني أن تأكيد اتصال بروتوكول أمان طبقة النقل (TLS) أو طبقة المقابس الآمنة (SSL) سيؤدي إلى إخفاق الاتصال الإغلاق.

    • يوضح استعراض الرسالة رقم 6 أن سبب إخفاق تأكيد اتصال TLS/SSL هو أن لا يدعم خادم الخلفية إلا بروتوكول TLSv1.0 كما هو موضح أدناه:

    • وذلك بسبب عدم تطابق بين البروتوكول الذي يستخدمه معالج الرسائل خادم الخلفية، أرسل خادم الخلفية الرسالة التالية: رسالة تنبيه فادحة: إغلاق إشعار

الدقة

يعمل معالج الرسائل على Java 8 ويستخدم بروتوكول TLSv1.2 بشكل افتراضي. إذا كانت الخلفية لا يعتمد الخادم بروتوكول TLSv1.2، لذا يمكنك اتخاذ إحدى الخطوات التالية لحل هذا الإصدار:

  1. عليك ترقية خادم الخلفية لدعم بروتوكول TLSv1.2. هذا حل موصى به كان بروتوكول TLSv1.2 أكثر أمانًا.
  2. إذا لم تتمكّن من ترقية خادم الخلفية على الفور لسبب ما، يمكنك فرض استخدام بروتوكول TLSv1.0 على معالج الرسائل للاتصال خادم الخلفية باتباع الخطوات التالية:
    1. إذا لم يتم تحديد خادم هدف في تعريف TargetEndpoint للخادم الوكيل، يمكنك ضبط العنصر Protocol إلى TLSv1.0 كما هو موضح أدناه: 
      <TargetEndpoint name="default">
 …
 <HTTPTargetConnection>
   <SSLInfo>
       <Enabled>true</Enabled>
       <Protocols>
           <Protocol>TLSv1.0</Protocol>
       </Protocols>
   </SSLInfo>
   <URL>https://myservice.com</URL>
 </HTTPTargetConnection>
 …
</TargetEndpoint>
    2. إذا قمت بتهيئة الخادم الهدف للخادم الوكيل، ثم استخدم هذه الإدارة لواجهة برمجة تطبيقات الإدارة لتعيين البروتوكول على TLSv1.0 في علامة تهيئة الخادم الهدف.

عدم تطابق الرموز

قد يظهر لك إخفاق تأكيد اتصال بروتوكول أمان طبقة النقل (TLS)/طبقة المقابس الآمنة (SSL) إذا لم تكن خوارزمية مجموعة الرموز التي يستخدمها العميل يتوافق مع الخادم إما عند الاتصال الوارد (الشمالي) أو الصادر (للخارج) في Apigee Edge. راجع أيضًا فهم الروابط الشمالية والجنوبية

التشخيص

  1. تحديد ما إذا كان الخطأ قد حدث في اتصال الشمال أو الجنوب. للحصول على مزيد من الإرشادات حول اتخاذ هذا القرار، اطلع على تحديد مصدر المشكلة.
  2. تشغيل tcpdump لجمع مزيد من المعلومات:
    • إذا كنت مستخدمًا خاصًا على السحابة الإلكترونية، يمكنك جمع tcpdump البيانات على العميل أو الخادم ذي الصلة. يمكن أن يكون العميل هو تطبيق العميل (للعمليات الواردة، أو الاتصالات باتجاه الشمال) أو الرسائل معالِج البيانات (للاتصالات الصادرة أو للاتصالات الجنوبية). يمكن أن يكون الخادم هو جهاز توجيه الحافة ( الواردة أو الاتصالات الواردة أو الشمالية) أو خادم الخلفية (بالنسبة إلى الاتصالات الصادرة أو تلك في منطقة جنوبية) استنادًا إلى قرارك من الخطوة 1.
    • إذا كنت من مستخدمي Cloud Public، يمكنك جمع tcpdump البيانات فقط على تطبيق العميل (للاتصالات الواردة أو للاتصالات الشمالية) أو خادم الخلفية (للاتصالات الصادرة أو الجنوبية)، لأنك لا يمكنه الوصول إلى جهاز توجيه Edge أو معالج الرسائل.
    tcpdump -i any -s 0 host IP address -w File name
    عرض بيانات tcpdump لمزيد من المعلومات حول استخدام الأمر tcpdump.
  3. تحليل بيانات tcpdump باستخدام أداة Wireshark أو أي أداة أخرى تعرفها
  4. في ما يلي تحليل نموذجي لمخرج tcpdump باستخدام Wireshark:
    • في هذا المثال، حدث إخفاق تأكيد اتصال TLS/SSL بين تطبيق العميل جهاز توجيه الحافة (اتصال شمالي). تم جمع مخرجات "tcpdump" على Edge. الموجه.

    • توضّح الرسالة رقم 4 في إخراج tcpdump أدناه أنّ تطبيق العميل (المصدر) قد أرسل "العميل مرحبًا" إلى جهاز توجيه Edge (الوجهة).

    • يوضح تحديد رسالة Client Hello أن تطبيق العميل يستخدم TLSv1.2.

    • توضح الرسالة رقم 5 أن جهاز توجيه Edge يعترف بعبارة "Client Hello" رسالة من تطبيق العميل.
    • يرسل جهاز توجيه Edge على الفور تنبيه فادح : تعذّر تأكيد الاتصال إلى تطبيق العميل (الرسالة رقم 6). وهذا يعني إخفاق تأكيد اتصال بروتوكول أمان طبقة النقل (TLS)/طبقة المقابس الآمنة (SSL) وأن الاتصال سيتم إغلاقها.
    • عند النظر في الرسالة رقم 6، يمكنك الاطّلاع على المعلومات التالية:
      • يدعم جهاز توجيه Edge بروتوكول TLSv1.2. وهذا يعني أن البروتوكول يتطابق بين تطبيق العميل وجهاز توجيه Edge.

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

    • قد يكون الخطأ نتيجة إحدى المشاكل التالية:
      • لا يستخدم تطبيق العميل خوارزميات مجموعة التشفير التي تدعمها جهاز توجيه الحافة.
      • يدعم جهاز توجيه Edge SNI، لكن تطبيق العميل لا يرسل اسم الخادم.
    • تسرد الرسالة رقم 4 في مخرجات tcpdump خوارزميات مجموعة الرموز المتوافقة مع العميل. التطبيق كما هو موضح أدناه:

    • يتم سرد قائمة خوارزميات مجموعة التشفير التي يدعمها جهاز توجيه Edge في القائمة ملف /opt/nginx/conf.d/0-default.conf. في هذا المثال، يعتبر جهاز توجيه الحافة لا يتوافق إلا مع خوارزميات مجموعة التشفير عالي التشفير.
    • لا يستخدم تطبيق العميل أيًا من خوارزميات مجموعة التشفير العالي. ويعد عدم التطابق هذا هو سبب تعذّر تأكيد اتصال بروتوكول أمان طبقة النقل (TLS)/طبقة المقابس الآمنة (SSL).
    • بما أنّه تم تفعيل إشارة SNI على جهاز توجيه Edge، انتقِل للأسفل إلى الرسالة رقم 4 في الناتج tcpdump من أن تطبيق العميل يرسل اسم الخادم بشكل صحيح، كما هو موضح في كما هو موضّح أدناه:


    • وإذا كان هذا الاسم صالحًا، فيمكنك استنتاج أن تأكيد اتصال بروتوكول أمان طبقة النقل (TLS)/طبقة المقابس الآمنة (SSL) لأن خوارزميات مجموعة التشفير التي يستخدمها تطبيق العميل غير مدعومة في جهاز توجيه الحافة.

الدقة

ويجب أن تتأكد من استخدام العميل لخوارزميات مجموعة التشفير التي يدعمها الخادم. لحل المشكلة الموضحة في المقالة السابقة التشخيص، فقم بتنزيل وتثبيت حزمة إضافة تشفير Java (JCE) وتضمينها في Java لدعم خوارزميات مجموعة التشفير عالي التشفير.

الشهادة غير صحيحة

يحدث إخفاق تأكيد اتصال بروتوكول أمان طبقة النقل (TLS) أو طبقة المقابس الآمنة (SSL) إذا كانت لديك شهادات غير صحيحة في ملف تخزين المفاتيح الموثوق به، إما عند الاتصال الوارد (الشمالي) أو الصادر (للخارج) في Apigee Edge. يمكن أيضًا مراجعة فهم الروابط الشمالية والجنوبية

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

تسرد الأقسام التالية أمثلة على رسائل الخطأ وخطوات تشخيص هذه المشكلة وحلها. المشكلة.

رسائل الخطأ

قد تظهر لك رسائل خطأ مختلفة بناءً على سبب إخفاق تأكيد اتصال بروتوكول أمان طبقة النقل (TLS)/طبقة المقابس الآمنة (SSL). في ما يلي نموذج لرسالة الخطأ التي قد تظهر لك عند استدعاء خادم وكيل لواجهة برمجة التطبيقات:

* SSL certificate problem: Invalid certificate chain
* Closing connection 0
curl: (60) SSL certificate problem: Invalid certificate chain
More details here: http://curl.haxx.se/docs/sslcerts.html

الأسباب المحتملة

الأسباب الشائعة لهذه المشكلة هي:

السبب الوصف مَن يمكنه تنفيذ خطوات تحديد المشاكل وحلّها
عدم تطابق اسم المضيف ليس اسم المضيف المستخدَم في عنوان URL والشهادة في مخزن مفاتيح جهاز التوجيه تطابق. على سبيل المثال، يحدث عدم التطابق إذا كان اسم المضيف المستخدَم في عنوان URL هو myorg.domain.com بينما تحتوي الشهادة على اسم المضيف في CN الخاص بها على أنه CN=something.domain.com.

 مستخدمو Edge Private وPublic Cloud
شهادة غير مكتملة أو غير صحيحة سلسلة سلسلة الشهادات غير كاملة أو غير صحيحة. مستخدمو Edge Private وPublic Cloud فقط
الشهادة المنتهية الصلاحية أو غير المعروفة المُرسَلة من قِبل الخادم أو العميل يرسل الخادم أو العميل شهادة منتهية الصلاحية أو غير معروفة إما في أقصى الشمال أو الاتصال الجنوبي. مستخدمو Edge Private Cloud وEdge Public Cloud

اسم المضيف عدم تطابق

التشخيص

  1. لاحظ اسم المضيف المستخدم في عنوان URL الذي يعرضه طلب البيانات التالي من واجهة برمجة التطبيقات لإدارة Edge: 
    curl -v https://myorg.domain.com/v1/getinfo
     مثل: 
    curl -v https://api.enterprise.apigee.com/v1/getinfo
  2. يمكنك الحصول على CN المستخدم في الشهادة المخزنة في مخزن مفاتيح معين. يمكنك استخدام صفحة اتباع واجهات برمجة تطبيقات إدارة Edge التالية للحصول على تفاصيل الشهادة:
    1. احصل على اسم الشهادة في ملف تخزين المفاتيح:

      إذا كنت مستخدمًا خاصًا على السحابة الإلكترونية، يمكنك استخدام Management API على النحو التالي:
      curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs
       إذا كنت مستخدمًا للسحابة الإلكترونية العامة، يمكنك استخدام Management API على النحو التالي:
      curl -v https://api.enterprise.apigee.com/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs
    2. احصل على تفاصيل الشهادة في ملف تخزين المفاتيح باستخدام واجهة برمجة تطبيقات إدارة Edge.

      إذا كنت مستخدمًا خاصًا على Cloud:
      curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs/cert-name
      إذا كنت من مستخدمي Cloud عامًا:
      curl -v https://api.enterprise.apigee.com/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs/cert-name

      نموذج الشهادة:

      "certInfo": [
    {
      "basicConstraints": "CA:FALSE",
      "expiryDate": 1456258950000,
      "isValid": "No",
      "issuer": "SERIALNUMBER=07969287, CN=Go Daddy Secure Certification Authority, OU=http://certificates.godaddy.com/repository, O=\"GoDaddy.com, Inc.\", L=Scottsdale, ST=Arizona, C=US",
      "publicKey": "RSA Public Key, 2048 bits",
      "serialNumber": "07:bc:a7:39:03:f1:56",
      "sigAlgName": "SHA1withRSA",
      "subject": "CN=something.domain.com, OU=Domain Control Validated, O=something.domain.com",
      "validFrom": 1358287055000,
      "version": 3
    },

      يحتوي اسم الموضوع في الشهادة الأساسية على CN something.domain.com.

      لأنّ اسم المضيف المستخدَم في عنوان URL لطلب واجهة برمجة التطبيقات (راجِع الخطوة رقم 1 أعلاه) والموضوع في الشهادة، فستحصل على فشل تأكيد اتصال بروتوكول أمان طبقة النقل/طبقة المقابس الآمنة.

الدقة

يمكن حل هذه المشكلة بإحدى الطريقتين التاليتين:

  • الحصول على شهادة (إذا لم يسبق لك الحصول على شهادة) حيث يحتوي الاسم الشائع للموضوع على حرف بدل الشهادة، ثم تحميل سلسلة الشهادات الكاملة الجديدة إلى ملف تخزين المفاتيح. على سبيل المثال: 
    "subject": "CN=*.domain.com, OU=Domain Control Validated, O=*.domain.com",
  • الحصول على شهادة (إذا لم يكن لديك واحدة بالفعل) تحتوي على اسم (CN) موجود بالفعل، ولكن استخدم your-orgyour-domain كاسم بديل للموضوع، ثم حمِّل النسخة الكاملة سلسلة الشهادات إلى ملف تخزين المفاتيح.

المراجع

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

سلسلة شهادات غير مكتملة أو غير صحيحة

التشخيص

  1. يمكنك الحصول على CN المستخدم في الشهادة المخزنة في مخزن مفاتيح معين. يمكنك استخدام صفحة اتباع واجهات برمجة تطبيقات إدارة Edge التالية للحصول على تفاصيل الشهادة:
    1. احصل على اسم الشهادة في ملف تخزين المفاتيح:

      إذا كنت مستخدمًا خاصًا على Cloud:
      curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs
      إذا كنت من مستخدمي Cloud عامًا:
      curl -v https://api.enterprise.apigee.com/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs
    2. يمكنك الحصول على تفاصيل الشهادة في ملف تخزين المفاتيح:

      إذا كنت مستخدمًا خاصًا على Cloud:
      curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs/cert-name
      إذا كنت من مستخدمي Cloud عامًا:
      curl -v https://api.enterprise.apigee.com/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs/cert-name
    3. التحقق من صحة الشهادة وسلسلتها والتأكد من التزامها بالإرشادات الواردة في المقالة آلية عمل سلاسل الشهادات لضمان أنها صالحة وكاملة سلسلة شهادات. إذا كانت سلسلة الشهادات المخزنة في ملف تخزين المفاتيح إما غير مكتمل أو غير صالح، فسترى تأكيد اتصال TLS/SSL إخفاقًا.
    4. يوضح الرسم البياني التالي نموذج شهادة تتضمن سلسلة شهادات غير صالحة، التي لا تتطابق فيها الشهادات المتوسطة والجذرية:

      5. نموذج للشهادة المتوسطة والجذرية حيث يمكن لجهات الإصدار عدم تطابق الموضوع


الدقة

  1. الحصول على شهادة (إذا لم يكن لديك واحدة بالفعل) تتضمن شهادة كاملة وصالحة سلسلة شهادات.
  2. شغّل أمر opensl التالي للتحقق من صحة سلسلة الشهادات مكتمل: 
    openssl verify -CAfile root-cert -untrusted intermediate-cert main-cert
  3. حمِّل سلسلة الشهادات التي تم التحقّق منها إلى ملف تخزين المفاتيح.

منتهي الصلاحية أو غير معروف الشهادة المُرسَلة من الخادم أو العميل

إذا أرسل الخادم/العميل شهادة غير صحيحة/منتهية الصلاحية إما في جهة الشمال أو عند الاتصال في الجزء الجنوبي، يرفض الطرف الآخر (الخادم/العميل) الشهادة مما يؤدي إلى إخفاق تأكيد اتصال TLS/SSL.

التشخيص

  1. تحديد ما إذا كان الخطأ قد حدث في الشمال أو southbound. لمزيد من الإرشادات حول جعل هذا قرار، راجع تحديد مصدر المشكلة
  2. تشغيل tcpdump لجمع مزيد من المعلومات:
    • إذا كنت مستخدمًا خاصًا على السحابة الإلكترونية، يمكنك جمع tcpdump البيانات على العميل أو الخادم ذي الصلة. يمكن أن يكون العميل هو تطبيق العميل (للعمليات الواردة، أو الاتصالات باتجاه الشمال) أو الرسائل معالِج البيانات (للاتصالات الصادرة أو للاتصالات الجنوبية). يمكن أن يكون الخادم هو جهاز توجيه الحافة ( الواردة أو الاتصالات الواردة أو الشمالية) أو خادم الخلفية (بالنسبة إلى الاتصالات الصادرة أو تلك في منطقة جنوبية) استنادًا إلى قرارك من الخطوة 1.
    • إذا كنت من مستخدمي Cloud Public، يمكنك جمع tcpdump البيانات فقط على تطبيق العميل (للاتصالات الواردة أو للاتصالات الشمالية) أو خادم الخلفية (للاتصالات الصادرة أو الجنوبية)، لأنك لا يمكنه الوصول إلى جهاز توجيه Edge أو معالج الرسائل.
    tcpdump -i any -s 0 host IP address -w File name
    عرض بيانات tcpdump لمزيد من المعلومات حول استخدام الأمر tcpdump.
  3. حلِّل بيانات tcpdump باستخدام أداة Wireshark أو أداة مماثلة.
  4. من مخرجات tcpdump، حدِّد المضيف (العميل أو الخادم) الذي يرفض الشهادة أثناء خطوة التحقق.
  5. يمكنك استرداد الشهادة المُرسَلة من الطرف الآخر من إخراج tcpdump، بشرط أن يكون عدم تشفير البيانات. سيكون هذا مفيدًا للمقارنة إذا تطابقت هذه الشهادة مع الشهادة المتوفرة في Truststore.
  6. راجِع نموذج tcpdump للاتصال بطبقة المقابس الآمنة (SSL) بين معالج الرسائل خادم الخلفية.

    نموذج tcpdump يعرض خطأ غير معروف في الشهادة


    1. يرسل معالج الرسائل (العميل) "Client Hello" إلى خادم الخلفية (الخادم) في الرسالة رقم 59.
    2. يرسل خادم الخلفية رسالة "Server Hello" إلى معالج الرسائل في الرسالة رقم 61.
    3. يتحققان بشكل تبادلي من خوارزميات مجموعة التشفير والبروتوكول المستخدمة.
    4. يرسل خادم الخلفية رسالة Certificate and Server Hello Done (تم مرحبًا الخادم) إلى معالج الرسائل في الرسالة رقم 68.
    5. يرسل معالج الرسائل التنبيه الخطير "Description: شهادة غير معروف" في الرسالة رقم 70.
    6. بعد الاطّلاع على الرسالة رقم 70، لا تتوفر أي تفاصيل إضافية أخرى. من رسالة التنبيه كما هو موضح أدناه:


    7. راجِع الرسالة رقم 68 للحصول على تفاصيل حول الشهادة المُرسَلة من الخلفية. كما هو موضح في الرسم التالي:

    8. تتوفّر كل من شهادة خادم الخلفية وسلسلته الكاملة. أسفل "الشهادات" كما هو موضح في الشكل أعلاه.
  7. إذا تم اكتشاف أن الشهادة غير معروفة إما عن طريق جهاز التوجيه (شمال) أو معالج الرسائل (إلى الخارج) كما في المثال الموضح أعلاه، ثم اتبع الخطوات:
    1. احصل على الشهادة وسلسلةها المخزَّنة في المخزن الموثوق به المحدد. (راجع إلى إعدادات المضيف الافتراضي لجهاز التوجيه ونقطة النهاية المستهدفة معالج الرسائل). يمكنك استخدام واجهات برمجة التطبيقات التالية للحصول على تفاصيل الشهادة:
      1. احصل على اسم الشهادة في Truststore: 
        curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/truststore-name/certs
      2. احصل على تفاصيل الشهادة في Truststore: 
        curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/truststore-name/certs/cert-name
    2. تحقق مما إذا كانت الشهادة مخزنة في Truststore لجهاز التوجيه (شمال) أو يتطابق معالج الرسائل (للتصدير) مع الشهادة التي تم تخزينها في ملف تخزين مفاتيح لتطبيق العميل (northbound) أو الخادم المستهدف (خارجيًا)، أو قيمة يتم الحصول عليها من الناتج tcpdump. إذا كان هناك عدم تطابق، فإن هذا هو سبب فشل تأكيد اتصال TLS/SSL.
  8. إذا تم اكتشاف أن الشهادة غير معروفة إما من خلال تطبيق العميل (northbound) أو الخادم الهدف (خارجيًا)، ثم اتبع الخطوات التالية:
    1. يمكنك الحصول على سلسلة الشهادات الكاملة المستخدمة في الشهادة المخزنة في ملف ملف تخزين المفاتيح. (راجع إعدادات المضيف الافتراضي لجهاز التوجيه ونقطة النهاية المستهدفة). تهيئة معالج الرسائل). يمكنك استخدام واجهات برمجة التطبيقات التالية تفاصيل الشهادة:
      1. احصل على اسم الشهادة في ملف تخزين المفاتيح: 
        curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs
      2. يمكنك الحصول على تفاصيل الشهادة في ملف تخزين المفاتيح:
        curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs/cert-name
    2. تحقق مما إذا كانت الشهادة المخزنة في ملف تخزين مفاتيح جهاز التوجيه (شمال) أو يطابق معالج الرسائل (خارجيًا) الشهادة المخزنة في المخزن الموثوق به تطبيق عميل (northbound) أو الخادم المستهدف (خارجيًا)، أو الخادم الذي التي تم الحصول عليها من ناتج tcpdump. إذا كان هناك عدم تطابق، فإن ذلك هو سبب طبقة المقابس الآمنة فشل تأكيد الاتصال.
  9. إذا انتهت صلاحية الشهادة المُرسَلة من قِبل خادم/عميل، فحينئذٍ العميل/الخادم يرفض الشهادة، وسترى رسالة التنبيه التالية في tcpdump:

    تنبيه (المستوى: فادح، الوصف: انتهت صلاحية الشهادة)

  10. تحقق من انتهاء صلاحية الشهادة في ملف تخزين المفاتيح للمضيف المناسب.

الدقة

لحلّ المشكلة المحدّدة في المثال أعلاه، حمِّل ملف تعريف خادم الخلفية الصالح الشهادة إلى الأقران في معالج الرسائل.

يلخص الجدول التالي خطوات حل المشكلة بناءً على سبب المشكلة.

السبب الوصف الحلّ
شهادة منتهية الصلاحية NorthBound
  • انتهت صلاحية الشهادة المخزنة في ملف تخزين المفاتيح في جهاز التوجيه.
  • انتهت صلاحية الشهادة المخزنة في ملف تخزين المفاتيح لتطبيق العميل (ثنائي الاتجاه طبقة المقابس الآمنة).
 حمّل شهادة جديدة وسلسلتها الكاملة إلى ملف تخزين المفاتيح على الملف المضيف.
SouthBound
  • انتهت صلاحية الشهادة المخزّنة في ملف تخزين المفاتيح في الخادم المستهدَف.
  • انتهت صلاحية الشهادة المخزنة في ملف تخزين المفاتيح في معالج الرسائل (ثنائي الاتجاه طبقة المقابس الآمنة).
 حمّل شهادة جديدة وسلسلتها الكاملة إلى ملف تخزين المفاتيح على الملف المضيف.
شهادة غير معروفة NorthBound
  • لا تتطابق الشهادة المخزنة في المخزن الموثوق به لتطبيق العميل شهادة جهاز التوجيه.
  • لا تتطابق الشهادة المخزنة في المخزن الموثوق به لجهاز التوجيه مع العميل شهادة التطبيق (طبقة المقابس الآمنة ثنائية الاتجاه).
 حمِّل الشهادة الصالحة إلى Truststore على المضيف المناسب.
SouthBound
  • لا تتطابق الشهادة المخزنة في المخزن الموثوق للخادم الهدف مع شهادة معالج الرسائل.
  • لا تتطابق الشهادة المخزنة في المخزن الموثوق به لمعالج الرسائل شهادة الخادم الهدف (طبقة المقابس الآمنة ثنائية الاتجاه).
 حمِّل الشهادة الصالحة إلى Truststore على المضيف المناسب.

تم تفعيل إشارة اسم الخادم (SNI) الخادم

قد يحدث إخفاق تأكيد اتصال بروتوكول أمان طبقة النقل (TLS) أو طبقة المقابس الآمنة (SSL) عندما يتصل البرنامج بخادم تفعيل إشارة الاسم (SNI) الخادم، لكن البرنامج غير مُفعّل فيه إشارة اسم الخادم (SNI). قد يحدث هذا إما في الطرف الشمالي أو اتصال جنوبي في Edge.

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

تحديد الخادم الذي يدعم إشارة اسم الخادم (SNI)

  1. نفِّذ الأمر openssl وجرِّب الاتصال باسم مضيف الخادم ذي الصلة (Edge) جهاز التوجيه أو خادم الخلفية) بدون إدخال اسم الخادم، كما هو موضّح أدناه: 
    openssl s_client -connect hostname:port
    قد تحصل على الشهادات، وقد تلاحظ في بعض الأحيان فشل تأكيد الاتصال في الأمر opensl، كما هو موضح أدناه:
    CONNECTED(00000003)
9362:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:/BuildRoot/Library/Caches/com.apple.xbs/Sources/OpenSSL098/OpenSSL098-64.50.6/src/ssl/s23_clnt.c:593
  2. نفِّذ الأمر openssl وجرِّب الاتصال باسم مضيف الخادم ذي الصلة. (جهاز توجيه الحافة أو خادم الخلفية) عن طريق تمرير اسم الخادم كما هو موضح أدناه: 
    openssl s_client -connect hostname:port -servername hostname
  3. إذا لم تنجح عملية تأكيد الاتصال في الخطوة 1 أو إذا حصلت على شهادات مختلفة في الخطوة رقم 1 الخطوة رقم 2، فإنها تشير إلى أن الخادم المحدد تم تمكين إشارة اسم الخادم (SNI).

بعد تحديد أن الخادم تم تفعيل إشارة اسم الخادم (SNI) به، يمكنك اتّباع الخطوات أدناه التحقق مما إذا كان سبب إخفاق تأكيد اتصال بروتوكول أمان طبقة النقل (TLS)/طبقة المقابس الآمنة (SSL) هو عدم تمكن العميل من الاتصال خادم SNI.

التشخيص

  1. تحديد ما إذا كان الخطأ قد حدث في الشمال أو southbound. لمزيد من الإرشادات حول جعل هذا قرار، راجع تحديد مصدر المشكلة
  2. تشغيل tcpdump لجمع مزيد من المعلومات:
    • إذا كنت مستخدمًا خاصًا على السحابة الإلكترونية، يمكنك جمع tcpdump البيانات على العميل أو الخادم ذي الصلة. يمكن أن يكون العميل هو تطبيق العميل (للعمليات الواردة، أو الاتصالات باتجاه الشمال) أو الرسائل معالِج البيانات (للاتصالات الصادرة أو للاتصالات الجنوبية). يمكن أن يكون الخادم هو جهاز توجيه الحافة ( الواردة أو الاتصالات الواردة أو الشمالية) أو خادم الخلفية (بالنسبة إلى الاتصالات الصادرة أو تلك في منطقة جنوبية) استنادًا إلى قرارك من الخطوة 1.
    • إذا كنت من مستخدمي Cloud Public، يمكنك جمع tcpdump البيانات فقط على تطبيق العميل (للاتصالات الواردة أو للاتصالات الشمالية) أو خادم الخلفية (للاتصالات الصادرة أو الجنوبية)، لأنك لا يمكنه الوصول إلى جهاز توجيه Edge أو معالج الرسائل.
    tcpdump -i any -s 0 host IP address -w File name
    عرض بيانات tcpdump لمزيد من المعلومات حول استخدام الأمر tcpdump.
  3. تحليل ناتج tcpdump باستخدام Wireshark أو أداة مماثلة.
  4. وفي ما يلي نموذج من تحليل tcpdump باستخدام Wireshark:
    1. في هذا المثال، حدث فشل تأكيد اتصال TLS/SSL بين رسالة Edge معالج البيانات وخادم الخلفية (الاتصال الصادر)
    2. توضّح الرسالة رقم 4 في ناتج tcpdump أدناه أنّ معالج الرسائل (المصدر) قد أرسل رسالة "Client Hello" إلى خادم الخلفية (الوجهة).

    3. تحديد "Client Hello" تُظهر أن الرسالة يستخدم المعالج بروتوكول TLSv1.2.

    4. توضح الرسالة رقم 4 أن خادم الخلفية يتعرف على عبارة "Client Hello" رسالة من معالج الرسائل.
    5. يرسل خادم الخلفية على الفور تنبيه خطير : تأكيد الاتصال تعذّر وصول معالج الرسائل (الرسالة رقم 5). وهذا يعني أن تأكيد اتصال TLS/SSL أخفق وسيتم إغلاق الاتصال.
    6. راجِع الرسالة رقم 6 لاكتشاف المعلومات التالية
      • يدعم خادم الخلفية بروتوكول TLSv1.2. وهذا يعني أن البروتوكول تطابقها بين معالج الرسائل وخادم الخلفية.
      • ومع ذلك، سيستمر خادم الخلفية في إرسال تنبيه خطير: تأكيد الاتصال. تعذّر وصول معالج الرسائل كما هو موضح في الشكل أدناه:

    7. قد يحدث هذا الخطأ لأحد الأسباب التالية:
      • لا يستخدم معالج الرسائل خوارزميات مجموعة الرموز المدعومة من قبل خادم الخلفية.
      • تم تفعيل إشارة اسم الخادم (SNI) على خادم الخلفية، ولكن تطبيق العميل لا يرسل اسم الخادم.
    8. راجِع الرسالة رقم 3 (Client Hello) في ناتج tcpdump بمزيد من التفاصيل. لاحظ أن الإضافة: server_name غير متوفّر، كما هو موضّح أدناه:

    9. وهذا يؤكد أن معالج الرسائل لم يرسل server_name إلى خادم الخلفية الذي تم تفعيل ميزة SNI فيه.
    10. وهذا هو سبب إخفاق تأكيد اتصال بروتوكول أمان طبقة النقل (TLS)/طبقة المقابس الآمنة (SSL) وسبب إخفاق الواجهة الخلفية إرسال الخادم تنبيه فادح: تعذُّر تأكيد الاتصال إلى الرسالة المعالج.
  5. يجب التحقق من أنّ jsse.enableSNIExtension property في تم ضبط system.properties على "خطأ" في "معالج الرسائل" لتأكيد أنّ معالج الرسائل غير مفعَّل للاتصال بالخادم المُفعّل فيه إشارة اسم الخادم (SNI).

الدقة

تمكين معالج(معالجات) الرسائل من الاتصال بالخوادم التي تدعم SNI من خلال تنفيذ الخطوات التالية:

  1. إنشاء/opt/apigee/customer/application/message-processor.properties (إذا لم يكن موجودًا من قبل).
  2. أضِف السطر التالي إلى هذا الملف: conf_system_jsse.enableSNIExtension=true
  3. تم قطع مالك هذا الملف إلى apigee:apigee: 
    chown apigee:apigee /opt/apigee/customer/application/message-processor.properties
  4. أعِد تشغيل معالج الرسائل. 
    /opt/apigee/apigee-service/bin/apigee-service message-processor restart
  5. إذا كان لديك أكثر من معالج رسائل واحد، فكرر الخطوات من 1 إلى 4 في جميع معالِجات الرسائل.

إذا لم تتمكن من تحديد سبب إخفاق تأكيد اتصال بروتوكول أمان طبقة النقل (TLS)/طبقة المقابس الآمنة (SSL) وحلّ المشكلة أو كنت بحاجة إلى مزيد من المساعدة، يُرجى التواصل مع دعم Apigee Edge شارِك التفاصيل الكاملة حول المشكلة مع ناتج tcpdump.