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

مراقبة واجهة برمجة التطبيقات

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

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

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

التتبّع

الإجراء الثاني: استخدام أداة التتبُّع

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

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

2. تأكَّد من تفعيل Show all FlowInfos (إظهار جميع عمليات التدفق):

   
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- error-code وX-Apigee-error-source وX-Apigee-Message-ID كما هو موضّح أدناه:

   ( عرض صورة أكبر حجمًا)

   
9. لاحِظ قيم X-Apigee-fault-code وX-Apigee-fault-code وX-Apigee-fault-code:

عناوين الأخطاء	القيمة
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. إذا كنت من مستخدمي السحابة الإلكترونية الخاصة، يمكنك استخدام سجلات وصول NGINX لتحديد المعلومات الأساسية حول HTTP 503 Service Unavailable.

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 الذي يتطابق مع قيمةX-Apigee-fault-code، حدِّد قيمة X-Apigee-fault-code

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

   ( عرض صورة أكبر حجمًا)

   

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

   العناوين	القيمة
   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

المرحلة الثانية: مقارنة شهادة خادم الخلفية والشهادات المخزّنة في Truststores لمعالج الرسائل

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

   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، حدد البيئات > المراجع. دوِّن الاسم الوارد في عمود المرجع لمرجع Truststore المحدد. سيكون هذا هو اسم متجرك الموثوق به.

      ( عرض صورة أكبر حجمًا)

      

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

      myCompanyTruststoreRef: myCompanyTruststore

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

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

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

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

      مستخدم Cloud خاص:

      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

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

      الشهادات من مثال Truststore myCompanyTruststore هي:

      [
        "serverCert"
      ]
      

   2. الحصول على تفاصيل الشهادة للشهادة المحدَّدة من أحد ملفات تخزين المفاتيح أو Truststore تعرض واجهة برمجة التطبيقات هذه معلومات عن شهادة معيّنة في 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"
      

      مستخدم 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",
      

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

   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
      

      شهادة الجذر مفقودة تمامًا في Truststore لمعالج الرسائل.

   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 لتطبيقات العميل

اسم النطاق المؤهل بالكامل صحيح

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

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>