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

التتبّع

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

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

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

2. تأكَّد من تفعيل عرض كل 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 إلى إخفاق تأكيد اتصال طبقة المقابس الآمنة، لأنّ معالج الرسائل في Apigee Edge لم يتمكّن من التحقّق من صحة بيانات خادم الخلفية الشهادة.
7. انتقِل إلى مرحلة AX (البيانات المسجَّلة في "إحصاءات Google") في عملية التتبُّع وانقر عليها.

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

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

   
9. دوِّن قيم X-Apigee-fault-code وX-Apigee-fault-code، و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. إذا كنت مستخدمًا للسحابة الإلكترونية الخاص، يمكنك استخدام سجلات وصول 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 قيمة messaging.adaptors.http.flow.SslHandshakeFailed، ثم تحديد قيمة X-Apigee-fault-source..

   نموذج الخطأ 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

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

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 المحدّد. سيكون هذا Truststore.

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

      

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

      myCompanyTruststoreRef: myCompanyTruststore

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

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

      مستخدم Cloud العام:

      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.

      مستخدم Cloud العام:

      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 (اسم المجال المؤهل بالكامل) صحيح

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

1. إذا لم تكن لديك شهادة خادم خلفية مع اسم FQDN (اسم المجال المؤهل بالكامل) الصحيح، ثم شراء الشهادة المناسبة من مرجع تصديق (CA) مناسب.

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

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

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

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

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

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

   في المثال الذي تمت مناقشته أعلاه، إذا تم إدخال اسم مضيف خادم الخلفية بشكل غير صحيح يمكنك إصلاحها باستخدام FQDN (اسم المجال المؤهل بالكامل) من شهادة خادم الخلفية، التي تكون 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>