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

أنت الآن بصدد الاطّلاع على مستندات Apigee Edge.
انتقِل إلى مستندات Apigee X. info

المشكلة

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

رسائل الخطأ

HTTP/1.1 503 Service Unavailable

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

Received fatal alert: handshake_failure

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

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

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

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

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

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

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

التشخيص

1. حدِّد ما إذا كان الخطأ قد حدث في الاتصال الصاعد أو الهابط. للحصول على إرشادات إضافية حول تحديد مصدر المشكلة، راجِع مقالة تحديد مصدر المشكلة.
2. شغِّل الأداة المساعدة tcpdump لجمع المزيد من المعلومات:
   • إذا كنت مستخدمًا للسحابة الإلكترونية الخاصة، يمكنك جمع بيانات tcpdump في العميل أو الخادم المعنيّ. يمكن أن يكون العميل هو تطبيق العميل (للاتصالات الواردة أو المتجهة شمالاً) أو "معالج الرسائل" (للاتصالات الصادرة أو المتجهة جنوبًا). يمكن أن يكون الخادم هو جهاز توجيه الحافة (للاتصالات الواردة أو الشمالية) أو خادم الخلفية (للاتصالات الصادرة أو الجنوبية) استنادًا إلى ما حدّدته في الخطوة 1.
   • إذا كنت مستخدمًا لخدمات السحابة الإلكترونية العامة، يمكنك جمع بيانات tcpdump على تطبيق العميل فقط (لعمليات الربط الواردة أو الشمالية) أو خادم الخلفية (لعمليات الربط الصادرة أو الجنوبية)، لأنّه ليس لديك إذن الوصول إلى Edge Router أو Message Processor.

   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" إلى خادم الخلفية (الوجهة).
     

     

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

     

   • تعرض الرسالة رقم 5 أنّ خادم الخلفية يقرّ باستلام الرسالة "Client Hello" من "معالج الرسائل".
   • يرسل خادم الخلفية على الفور Fatal Alert : Close Notify إلى معالج الرسائل (الرسالة رقم 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.
   • إذا كنت مستخدمًا لخدمات السحابة الإلكترونية العامة، يمكنك جمع بيانات tcpdump على تطبيق العميل فقط (لعمليات الربط الواردة أو الشمالية) أو خادم الخلفية (لعمليات الربط الصادرة أو الجنوبية)، لأنّه ليس لديك إذن الوصول إلى Edge Router أو Message Processor.

   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 أدناه أنّ تطبيق العميل (المصدر) أرسل رسالة "Client Hello" إلى Edge Router (الوجهة).

     

   • يُظهر اختيار رسالة Client Hello أنّ تطبيق العميل يستخدم بروتوكول TLSv1.2.

     

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

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

       

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

     

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

الدقة

يجب التأكّد من أنّ العميل يستخدم خوارزميات مجموعة رموز المتوافقة مع الخادم. لحلّ المشكلة الموضّحة في قسم "التشخيص" السابق، نزِّل حزمة Java Cryptography Extension (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

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

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

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

التشخيص

1. دوِّن اسم المضيف المستخدَم في عنوان URL الذي يعرضه طلب البيانات التالي من Edge Management API:

   curl -v https://myorg.domain.com/v1/getinfo

   مثال:

   curl -v https://api.enterprise.apigee.com/v1/getinfo

2. الحصول على الاسم الشائع المستخدَم في الشهادة المخزَّنة في ملف تخزين المفاتيح المحدّد يمكنك استخدام واجهات برمجة التطبيقات التالية لإدارة 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 Management API.
      
      إذا كنت مستخدمًا للسحابة الإلكترونية الخاصة:
      

      curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs/cert-name
      

      إذا كنت مستخدمًا في السحابة الإلكترونية العامة:
      

      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 أعلاه) واسم الموضوع في الشهادة غير متطابقَين، سيحدث خطأ في عملية المصافحة بين بروتوكول أمان طبقة النقل (TLS) وطبقة المقابس الآمنة (SSL).

الدقة

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

• احصل على شهادة (إذا لم تكن لديك شهادة) يتضمّن الاسم الشائع (CN) الخاص بموضوعها شهادة حرف بدل، ثم حمِّل سلسلة الشهادات الكاملة الجديدة إلى ملف تخزين المفاتيح. على سبيل المثال:

  "subject": "CN=*.domain.com, OU=Domain Control Validated, O=*.domain.com",

• احصل على شهادة (إذا لم تكن لديك شهادة) تتضمّن اسمًا شائعًا حاليًا، ولكن استخدِم your-org.your-domain كاسم بديل للموضوع، ثم حمِّل سلسلة الشهادات الكاملة إلى ملف تخزين المفاتيح.

المراجع

ملفات تخزين المفاتيح وملفات تخزين الشهادات الموثوقة

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

التشخيص

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

      curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs
      

      إذا كنت مستخدمًا في السحابة الإلكترونية العامة:
      

      curl -v https://api.enterprise.apigee.com/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs
      

   2. الحصول على تفاصيل الشهادة في ملف تخزين المفاتيح:
      
      إذا كنت مستخدمًا في Private Cloud:
      

      curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs/cert-name
      

      إذا كنت مستخدمًا في السحابة الإلكترونية العامة:
      

      curl -v https://api.enterprise.apigee.com/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs/cert-name
      

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

   نموذج شهادة وسيطة وشهادة جذر لا يتطابق فيهما جهة الإصدار مع موضوع الشهادة

   
   

الدقة

1. احصل على شهادة (إذا لم تكن لديك شهادة) تتضمّن سلسلة شهادات كاملة وصالحة.
2. شغِّل أمر openssl التالي للتأكّد من أنّ سلسلة الشهادات صحيحة وكاملة:

   openssl verify -CAfile root-cert -untrusted intermediate-cert main-cert

3. حمِّل سلسلة الشهادات التي تم التحقّق منها إلى ملف تخزين المفاتيح.

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

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

التشخيص

1. حدِّد ما إذا كان الخطأ قد حدث في الاتصال الصاعد أو الهابط. للحصول على إرشادات إضافية حول تحديد مصدر المشكلة، راجِع مقالة تحديد مصدر المشكلة.
2. شغِّل الأداة المساعدة tcpdump لجمع المزيد من المعلومات:
   • إذا كنت مستخدمًا للسحابة الإلكترونية الخاصة، يمكنك جمع بيانات tcpdump في العميل أو الخادم المعنيّ. يمكن أن يكون العميل هو تطبيق العميل (للاتصالات الواردة أو المتجهة شمالاً) أو "معالج الرسائل" (للاتصالات الصادرة أو المتجهة جنوبًا). يمكن أن يكون الخادم هو جهاز توجيه الحافة (للاتصالات الواردة أو الشمالية) أو خادم الخلفية (للاتصالات الصادرة أو الجنوبية) استنادًا إلى ما حدّدته في الخطوة 1.
   • إذا كنت مستخدمًا لخدمات السحابة الإلكترونية العامة، يمكنك جمع بيانات tcpdump على تطبيق العميل فقط (لعمليات الربط الواردة أو الشمالية) أو خادم الخلفية (لعمليات الربط الصادرة أو الجنوبية)، لأنّه ليس لديك إذن الوصول إلى Edge Router أو Message Processor.

   tcpdump -i any -s 0 host IP address -w File name
   

   راجِع بيانات tcpdump لمزيد من المعلومات حول استخدام الأمر tcpdump.
3. حلِّل بيانات tcpdump باستخدام Wireshark أو أداة مشابهة.
4. من ناتج tcpdump، حدِّد المضيف (العميل أو الخادم) الذي يرفض الشهادة أثناء خطوة التحقّق.
5. يمكنك استرداد الشهادة المُرسَلة من الطرف الآخر من ناتج tcpdump، شرط ألا تكون البيانات مشفّرة. سيكون ذلك مفيدًا للمقارنة لمعرفة ما إذا كانت هذه الشهادة تتطابق مع الشهادة المتوفرة في مستودع الشهادات الموثوقة.
6. راجِع نموذج tcpdump لاتصال طبقة المقابس الآمنة بين "معالج الرسائل" وخادم الخلفية.

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

   
   

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

      
      

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

      

   8. تتوفّر شهادة خادم الخلفية وسلسلتها الكاملة ضمن قسم "الشهادات"، كما هو موضّح في الشكل أعلاه.
7. إذا تبيّن أنّ الشهادة غير معروفة إما من خلال جهاز التوجيه (في اتجاه الشمال) أو معالج الرسائل (في اتجاه الجنوب) كما هو موضّح في المثال أعلاه، اتّبِع الخطوات التالية:
   1. احصل على الشهادة وسلسلتها المخزّنة في ملف truststore المحدّد. (يُرجى الرجوع إلى إعدادات المضيف الافتراضي الخاصة بالموجه وإعدادات نقطة النهاية المستهدَفة الخاصة بمعالج الرسائل). يمكنك استخدام واجهات برمجة التطبيقات التالية للحصول على تفاصيل الشهادة:
      1. الحصول على اسم الشهادة في مستودع الثقة:

         curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/truststore-name/certs

      2. الحصول على تفاصيل الشهادة في مستودع الثقة:

         curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/truststore-name/certs/cert-name

   2. تحقَّق مما إذا كانت الشهادة المخزَّنة في Truststore لجهاز التوجيه (في اتجاه الشمال) أو "معالج الرسائل" (في اتجاه الجنوب) تتطابق مع الشهادة المخزَّنة في Keystore لتطبيق العميل (في اتجاه الشمال) أو الخادم المستهدف (في اتجاه الجنوب)، أو مع الشهادة التي تم الحصول عليها من ناتج tcpdump. وفي حال عدم التطابق، يكون ذلك هو سبب تعذّر تأكيد الاتصال عبر بروتوكول أمان طبقة النقل أو طبقة المقابس الآمنة.
8. إذا تبيّن أنّ الشهادة غير معروفة إما من خلال تطبيق العميل (في اتجاه الشمال) أو الخادم المستهدف (في اتجاه الجنوب)، اتّبِع الخطوات التالية:
   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. تحقَّق مما إذا كانت الشهادة المخزَّنة في ملف تخزين المفاتيح الخاص بجهاز التوجيه (في اتجاه الشمال) أو "معالج الرسائل" (في اتجاه الجنوب) تتطابق مع الشهادة المخزَّنة في ملف truststore الخاص بتطبيق العميل (في اتجاه الشمال) أو الخادم المستهدف (في اتجاه الجنوب)، أو مع الشهادة التي تم الحصول عليها من ناتج tcpdump. وفي حال عدم التطابق، يكون ذلك هو سبب تعذُّر تأكيد الاتصال عبر طبقة المقابس الآمنة (SSL).
9. إذا تبيّن أنّ الشهادة التي أرسلها خادم أو عميل منتهية الصلاحية، سيرفض العميل أو الخادم المستلِم الشهادة وستظهر لك رسالة التنبيه التالية في tcpdump:

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

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

الدقة

لحلّ المشكلة الموضّحة في المثال أعلاه، عليك تحميل شهادة خادم الخلفية الصالحة إلى Trustore على "معالج الرسائل".

يلخّص الجدول التالي الخطوات اللازمة لحلّ المشكلة استنادًا إلى سببها.

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

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

عليك أولاً تحديد اسم المضيف ورقم المنفذ للخادم المستخدَم والتحقّق مما إذا كان بروتوكول SNI مفعَّلاً أم لا.

تحديد الخادم المفعَّل عليه SNI

1. نفِّذ الأمر openssl وحاوِل الاتصال باسم مضيف الخادم ذي الصلة (جهاز توجيه Edge أو خادم الخلفية) بدون إدخال اسم الخادم، كما هو موضّح أدناه:

   openssl s_client -connect hostname:port

   قد تحصل على الشهادات، وقد تلاحظ أحيانًا تعذُّر المصافحة في أمر openssl، كما هو موضّح أدناه:
   

   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 وحاوِل الاتصال باسم مضيف الخادم ذي الصلة (جهاز توجيه Edge أو خادم الخلفية) من خلال تمرير اسم الخادم كما هو موضّح أدناه:

   openssl s_client -connect hostname:port -servername hostname

3. إذا حدث خطأ في المصافحة في الخطوة 1 أو حصلت على شهادات مختلفة في الخطوة 1 والخطوة 2، يشير ذلك إلى أنّ الخادم المحدّد مفعّل عليه SNI.

بعد التأكّد من أنّ الخادم يتيح استخدام SNI، يمكنك اتّباع الخطوات أدناه للتحقّق مما إذا كان تعذُّر إتمام عملية المصافحة بين TLS وSSL ناتجًا عن عدم قدرة العميل على التواصل مع خادم SNI.

التشخيص

1. حدِّد ما إذا كان الخطأ قد حدث في الاتصال الصاعد أو الهابط. للحصول على إرشادات إضافية حول تحديد مصدر المشكلة، راجِع مقالة تحديد مصدر المشكلة.
2. شغِّل الأداة المساعدة tcpdump لجمع المزيد من المعلومات:
   • إذا كنت مستخدمًا للسحابة الإلكترونية الخاصة، يمكنك جمع بيانات tcpdump في العميل أو الخادم المعنيّ. يمكن أن يكون العميل هو تطبيق العميل (للاتصالات الواردة أو المتجهة شمالاً) أو "معالج الرسائل" (للاتصالات الصادرة أو المتجهة جنوبًا). يمكن أن يكون الخادم هو جهاز توجيه الحافة (للاتصالات الواردة أو الشمالية) أو خادم الخلفية (للاتصالات الصادرة أو الجنوبية) استنادًا إلى ما حدّدته في الخطوة 1.
   • إذا كنت مستخدمًا لخدمات السحابة الإلكترونية العامة، يمكنك جمع بيانات tcpdump على تطبيق العميل فقط (لعمليات الربط الواردة أو الشمالية) أو خادم الخلفية (لعمليات الربط الصادرة أو الجنوبية)، لأنّه ليس لديك إذن الوصول إلى Edge Router أو Message Processor.

   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.