503 الخدمة غير متاحة - تعذّر تأكيد الاتصال بطبقة المقابس الآمنة (SSL)

API Monitoring

الإجراء 1: استخدام "مراقبة واجهة برمجة التطبيقات"

لتشخيص الخطأ باستخدام "مراقبة واجهة برمجة التطبيقات"، اتّبِع الخطوات التالية:

1. سجِّل الدخول إلى واجهة مستخدم Apigee Edge بصفتك مستخدمًا لديه دور مناسب.

2. انتقِل إلى المؤسسة التي تريد التحقيق في المشكلة فيها.

   
3. انتقِل إلى صفحة تحليل > مراقبة واجهة برمجة التطبيقات > التحقيق.
4. اختَر الفترة الزمنية المحدّدة التي لاحظت فيها الأخطاء.

5. رسم بياني لرمز الخطأ مقابل الوقت

6. اختَر الخلية التي تحتوي على رمز الخطأ messaging.adaptors.http.flow.SslHandshakeFailed كما هو موضّح أدناه:

   ( عرض صورة أكبر)

   

7. تظهر المعلومات حول رمز الخطأ messaging.adaptors.http.flow.SslHandshakeFailed كما هو موضّح أدناه:

   ( عرض صورة أكبر)

   

8. انقر على عرض السجلات ووسِّع صف الطلب الذي تعذّر تنفيذه.

   ( عرض صورة أكبر)

   
9. من نافذة السجلّات، سجِّل التفاصيل التالية:
   • معرّف رسالة الطلب
   • رمز الحالة: 503
   • مصدر الخطأ: target
   • رمز الخطأ: messaging.adaptors.http.flow.SslHandshakeFailed

التتبّع

الإجراء رقم 2: استخدام أداة "التتبُّع"

لتشخيص الخطأ باستخدام "أداة التتبُّع"، اتّبِع الخطوات التالية:

1. فعِّل جلسة التتبُّع، ثم اتّبِع إحدى الخطوتَين التاليتَين:
   • انتظِر حدوث الخطأ 503 Service Unavailable برمز الخطأ messaging.adaptors.http.flow.SslHandshakeFailed، أو
   • إذا كان بإمكانك إعادة إظهار المشكلة، أرسِل طلب بيانات من واجهة برمجة التطبيقات لإعادة إظهارها 503 Service Unavailable

2. تأكَّد من تفعيل خيار عرض جميع معلومات FlowInfo:

   
3. اختَر أحد الطلبات التي تعذّر تنفيذها وافحص التتبُّع.
4. تنقَّل بين مراحل التتبُّع المختلفة وحدِّد مكان حدوث الخطأ.

5. سيظهر الخطأ عادةً بعد المرحلة بدء عملية طلب الاستهداف كما هو موضّح أدناه:

   ( عرض صورة أكبر)

   
6. يُرجى ملاحظة قيم ما يلي من التتبُّع:
   • الخطأ: SSL Handshake failed sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
   • error.cause: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
   • error.class: com.apigee.errors.http.server.ServiceUnavailableException
   • تشير قيمة الخطأ SSL Handshake failed sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target إلى تعذُّر المصافحة عبر طبقة المقابس الآمنة (SSL)، لأنّ "معالج الرسائل" في Apigee Edge لم يتمكّن من التحقّق من صحة شهادة خادم الخلفية.
7. انتقِل إلى مرحلة AX (تسجيل بيانات "إحصاءات Google") في التتبُّع وانقر عليها.

8. انتقِل للأسفل إلى قسم عناوين أخطاء تفاصيل المرحلة وحدِّد قيم X-Apigee-fault-code وX-Apigee-fault-source وX-Apigee-Message-ID كما هو موضّح أدناه:

   ( عرض صورة أكبر)

   
9. دوِّن قيم X-Apigee-fault-code وX-Apigee-fault-source وX-Apigee-Message-ID:

عناوين الأخطاء	القيمة
X-Apigee-fault-code	messaging.adaptors.http.flow.SslHandshakeFailed
X-Apigee-fault-source	target
X-Apigee-Message-ID	MESSAGE_ID

NGINX

الإجراء رقم 3: استخدام سجلّات الوصول إلى NGINX

لتشخيص الخطأ باستخدام سجلّات الوصول إلى NGINX، اتّبِع الخطوات التالية:

1. إذا كنت مستخدمًا في Private Cloud، يمكنك استخدام سجلات الوصول إلى NGINX لتحديد المعلومات الأساسية حول 503 Service Unavailable عبر HTTP.

2. تحقَّق من سجلّات الوصول إلى NGINX:

   /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log

3. ابحث لمعرفة ما إذا كانت هناك أي أخطاء 503 برمز الخطأ messaging.adaptors.http.flow.SslHandshakeFailed خلال مدة زمنية محددة (إذا حدثت المشكلة في الماضي) أو ما إذا كانت هناك أي طلبات لا تزال غير ناجحة مع 503.

4. إذا عثرت على أي أخطاء 503 مع تطابق X-Apigee-fault-code مع قيمة messaging.adaptors.http.flow.SslHandshakeFailed، حدِّد قيمة X-Apigee-fault-source.

   مثال على الخطأ 503 من سجلّ الوصول إلى NGINX:

   ( عرض صورة أكبر)

   

   يحتوي نموذج الإدخال أعلاه من سجلّ الوصول إلى NGINX على القيم التالية لكل من X-Apigee-fault-code وX-Apigee-fault-source:

   العناوين	القيمة
   X-Apigee-fault-code	messaging.adaptors.http.flow.SslHandshakeFailed
   X-Apigee-fault-source	target

سجلّات "معالج الرسائل"

الإجراء رقم 4: استخدام سجلّات "معالج الرسائل"

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

2. ابحث عن معرّف رسالة الطلب المحدّد في سجلّ "معالج الرسائل" (/opt/apigee/var/log/edge-message-processor/logs/system.log). قد يظهر لك الخطأ التالي:

   org:myorg env:test api:MyProxy rev:1
   messageid:myorg-28247-3541813-1
   NIOThread@1 ERROR HTTP.CLIENT - HTTPClient$Context.handshakeFailed() :
   SSLClientChannel[Connected: Remote:X.X.X.X:443
   Local:192.168.194.140:55102]@64596 useCount=1
   bytesRead=0 bytesWritten=0 age=233ms  lastIO=233ms
   isOpen=true handshake failed, message: General SSLEngine problem
   

   يشير الخطأ أعلاه إلى تعذُّر تأكيد الاتصال عبر طبقة المقابس الآمنة (SSL) بين "معالج الرسائل" وخادم الخلفية.

   سيتبع ذلك استثناء مع تتبُّع تسلسل استدعاء الدوال البرمجية بالتفصيل كما هو موضّح أدناه:

   org:myorg env:test api:MyProxy rev:1
   messageid:myorg-28247-3541813-1
   NIOThread@1 ERROR ADAPTORS.HTTP.FLOW - RequestWriteListener.onException() :
   RequestWriteListener.onException(HTTPRequest@1522922c)
   javax.net.ssl.SSLHandshakeException: General SSLEngine problem
   	at sun.security.ssl.Handshaker.checkThrown(Handshaker.java:1478)
   	at sun.security.ssl.SSLEngineImpl.checkTaskThrown(SSLEngineImpl.java:535)
   	... <snipped>
   Caused by: javax.net.ssl.SSLHandshakeException: General SSLEngine problem
   	at sun.security.ssl.Alerts.getSSLException(Alerts.java:203)
   	at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1728)
   	... <snipped>
   Caused by: sun.security.validator.ValidatorException: PKIX path building failed:
   sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid
   certification path to requested target
   	at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:397)
   	at sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:302)
   	... <snipped>
     

   يُرجى العِلم أنّ تعذُّر المصافحة يرجع إلى:

   Caused by: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

   يشير ذلك إلى تعذُّر تأكيد الاتصال عبر طبقة المقابس الآمنة (SSL) لأنّ "معالج الرسائل" في Apigee Edge لم يتمكّن من التحقّق من صحة شهادة خادم الخلفية.

المرحلة 1

المرحلة 1: تحديد سلسلة شهادات خادم الخلفية

استخدِم إحدى الطرق التالية لتحديد سلسلة شهادات خادم الخلفية:

openssl s_client -connect BACKEND_SERVER_HOST_NAME:PORT#

Certificate chain
 0 s:/CN=mocktarget.apigee.net
   i:/C=US/O=Google Trust Services LLC/CN=GTS CA 1D4
 1 s:/C=US/O=Google Trust Services LLC/CN=GTS CA 1D4
   i:/C=US/O=Google Trust Services LLC/CN=GTS Root R1
 2 s:/C=US/O=Google Trust Services LLC/CN=GTS Root R1
   i:/C=US/O=Google Trust Services LLC/CN=GTS Root R1

المرحلة 2

المرحلة 2: مقارنة شهادة خادم الخلفية بالشهادات المخزَّنة في ملف truststore الخاص بـ "معالج الرسائل"

1. تحديد سلسلة شهادات خادم الخلفية
2. حدِّد الشهادة المخزّنة في truststore الخاص بـ "معالج الرسائل" باتّباع الخطوات التالية:

   1. احصل على اسم مرجع ملف truststore من العنصر TrustStore في القسم SSLInfo في TargetEndpoint.

      لنلقِ نظرة على نموذج SSLInfo في إعداد TargetEndpoint:

      <TargetEndpoint name="default">
      ...
         <HTTPTargetConnection>
            <Properties />
            <SSLInfo>
               <Enabled>true</Enabled>
               <ClientAuthEnabled>true</ClientAuthEnabled>
               <KeyStore>ref://myKeystoreRef</KeyStore>
               <KeyAlias>myKey</KeyAlias>
               <TrustStore>
                  ref://myCompanyTrustStoreRef
               </TrustStore>
            </SSLInfo>
         </HTTPTargetConnection>
         ...
      </TargetEndpoint>

   2. في المثال أعلاه، اسم مرجع TrustStore هو myCompanyTruststoreRef.

   3. في واجهة مستخدم Edge، اختَر البيئات > المراجع. دوِّن الاسم في عمود المرجع لمرجع ملف تخزين الشهادات المحدّد. سيكون هذا هو اسم مستودع الثقة.

      ( عرض صورة أكبر)

      

   4. في المثال أعلاه، اسم ملف truststore هو:

      myCompanyTruststoreRef: myCompanyTruststore

3. احصل على الشهادات المخزَّنة في مستودع الشهادات الموثوقة (التي تم تحديدها في الخطوة السابقة) باستخدام واجهات برمجة التطبيقات التالية:

   1. الحصول على جميع الشهادات لملف تخزين مفاتيح أو ملف تخزين موثوق تعرض واجهة برمجة التطبيقات هذه جميع الشهادات في مستودع المفاتيح الموثوق به المحدّد.

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

      curl -v -X GET https//api.enterprise.apigee.com/v1/organizations/ORGANIZATION_NAME/environments/ENVIRONMENT_NAME/keystores/KEYSTORE_NAME/certs -H "Authorization: Bearer $TOKEN"
      

      مستخدم السحابة الإلكترونية الخاصة:

      curl -v -X GET http://MANAGEMENT_HOST:PORT_#/v1/organizations/ORGANIZATION_NAME/environments/ENVIRONMENT_NAME/keystores/KEYSTORE_NAME/certs -H "Authorization: Bearer $TOKEN"
      

      المكان:

      • ‫ORGANIZATION_NAME هو اسم المؤسسة
      • ENVIRONMENT_NAME هو اسم البيئة
      • KEYSTORE_NAME هو اسم ملف تخزين المفاتيح
      • يتم ضبط $TOKEN على رمز الدخول عبر OAuth 2.0 كما هو موضّح في الحصول على رمز دخول عبر OAuth 2.0
      • تم توضيح خيارات curl المستخدَمة في هذا المثال في مقالة استخدام curl

      نموذج الناتج:

      الشهادات من متجر الثقة النموذجي myCompanyTruststore هي:

      [
        "serverCert"
      ]

   2. الحصول على تفاصيل الشهادة المحدّدة من Keystore أو Truststore تعرض واجهة برمجة التطبيقات هذه معلومات حول شهادة معيّنة في مستودع ثقة معيّن.

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

      curl -v -X GET https//api.enterprise.apigee.com/v1/organizations/ORGANIZATION_NAME/environments/ENVIRONMENT_NAME/keystores/KEYSTORE_NAME/certs/CERT_NAME -H "Authorization: Bearer $TOKEN"
      

      مستخدم Private Cloud

      curl -v -X GET http://MANAGEMENT_HOST:PORT_#>/v1/organizations/ORGANIZATION_NAME/environments/ENVIRONMENT_NAME/keystores/KEYSTORE_NAME/certs/CERT_NAME -H "Authorization: Bearer $TOKEN"
      

      المكان:

      • ‫ORGANIZATION_NAME هو اسم المؤسسة
      • ENVIRONMENT_NAME هو اسم البيئة
      • KEYSTORE_NAME هو اسم ملف تخزين المفاتيح
      • تمثّل CERT_NAME اسم الشهادة
      • يتم ضبط $TOKEN على رمز الدخول عبر OAuth 2.0 كما هو موضّح في الحصول على رمز دخول عبر OAuth 2.0
      • تم توضيح خيارات curl المستخدَمة في هذا المثال في مقالة استخدام curl

      مثال على الناتج

      تعرض تفاصيل serverCert الموضوع والجهة المصدرة على النحو التالي:

      شهادة الورقة/الكيان:

      "subject": "CN=mocktarget.apigee.net",
      "issuer": "CN=GTS CA 1D4, O=Google Trust Services LLC, C=US",

      الشهادة الوسيطة:

      "subject" : "CN=GTS CA 1D4, O=Google Trust Services LLC, C=US",
      "issuer" : "CN=GTS Root R1, O=Google Trust Services LLC, C=US",

4. تأكَّد من تطابق شهادة الخادم الفعلية التي تم الحصول عليها في الخطوة 1 مع الشهادة المخزَّنة في ملف truststore الذي تم الحصول عليه في الخطوة 3. في حال عدم التطابق، يكون ذلك هو سبب المشكلة.

   من المثال الموضّح أعلاه، لنلقِ نظرة على شهادة واحدة في كل مرة:

   1. شهادة غير مخوّلة للتصديق:

      من خادم الخلفية:

      s:/CN=mocktarget.apigee.net
      i:/C=US/O=Google Trust Services LLC/CN=GTS CA 1D4

      من مستودع الثقة الخاص ببرنامج معالجة الرسائل (العميل):

      "subject": "CN=mocktarget.apigee.net",
      "issuer": "CN=GTS CA 1D4, O=Google Trust Services LLC, C=US",

      تتطابق شهادة الورقة النهائية المخزَّنة في Truststore مع شهادة خادم الخلفية.

   2. الشهادة المتوسطة:

      من خادم الخلفية:

      s:/C=US/O=Google Trust Services LLC/CN=GTS CA 1D4
      i:/C=US/O=Google Trust Services LLC/CN=GTS Root R1

      من مستودع الثقة الخاص ببرنامج معالجة الرسائل (العميل):

      "subject" : "CN=GTS CA 1D4, O=Google Trust Services LLC, C=US",
      "issuer" : "CN=GTS Root R1, O=Google Trust Services LLC, C=US",

      تتطابق الشهادة الوسيطة المخزَّنة في مستودع الشهادات الموثوقة مع شهادة خادم الخلفية.

   3. شهادة الجذر:

      من خادم الخلفية:

      s:/C=US/O=Google Trust Services LLC/CN=GTS Root R1
      i:/C=US/O=Google Trust Services LLC/CN=GTS Root R1

      شهادة الجذر غير متوفّرة تمامًا في مستودع الثقة الخاص بـ "معالج الرسائل".

   4. بما أنّ شهادة الجذر غير متوفّرة في truststore، يعرض معالج الرسائل الاستثناء التالي:

      sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

      ويعرض الرمز 503 Service Unavailable مع رمز الخطأ messaging.adaptors.http.flow.SslHandshakeFailed على تطبيقات العميل.

اسم المجال المؤهَّل بالكامل الصحيح

تعديل مخزن المفاتيح الخاص بخادم الخلفية باستخدام اسم المجال المؤهَّل بالكامل الصحيح وسلسلة شهادات صالحة وكاملة:

1. إذا لم تكن لديك شهادة خادم خلفي تتضمّن اسم النطاق المؤهّل بالكامل الصحيح، عليك الحصول على الشهادة المناسبة من مرجع تصديق مناسب.

2. تأكَّد من أنّ لديك سلسلة شهادات صالحة وكاملة لخادم الخلفية.

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

خادم الخلفية الصحيح

عدِّل نقطة النهاية المستهدَفة باستخدام اسم المضيف الصحيح لخادم الخلفية:

1. إذا تم تحديد اسم المضيف بشكل غير صحيح في نقطة النهاية المستهدَفة، عدِّل نقطة النهاية المستهدَفة لتضمين اسم المضيف الصحيح الذي يتطابق مع اسم النطاق المؤهَّل بالكامل في شهادة خادم الخلفية.

2. احفظ التغييرات في خادم وكيل واجهة برمجة التطبيقات.

   في المثال الموضّح أعلاه، إذا تم تحديد اسم مضيف خادم الخلفية بشكل غير صحيح، يمكنك إصلاح ذلك باستخدام اسم النطاق المؤهّل بالكامل من شهادة خادم الخلفية، أي backend.apigee.net كما يلي:

   <TargetEndpoint name="default">
      …
      <HTTPTargetConnection>
         <Properties />
         <SSLInfo>
            <Enabled>true</Enabled>
            <TrustStore>ref://myTrustStoreRef</TrustStore>
         </SSLInfo>
         <URL>https://backend.apigee.net/resource</URL>
      </HTTPTargetConnection>
   </TargetEndpoint>