سرویس 503 در دسترس نیست - SSL Handshake Failure

مانیتورینگ API

روش شماره 1: استفاده از مانیتورینگ API

برای تشخیص خطا با استفاده از API Monitoring:

1. به عنوان کاربر با نقش مناسب وارد رابط کاربری Apigee Edge شوید .

2. به سازمانی که می‌خواهید در آن موضوع را بررسی کنید بروید.

   
3. به صفحه Analyze > API Monitoring > Investigate بروید.
4. بازه زمانی خاصی را که در آن خطاها را مشاهده کرده اید انتخاب کنید.

5. کد خطا را در برابر زمان ترسیم کنید.

6. سلولی را انتخاب کنید که دارای کد خطای messaging.adaptors.http.flow.SslHandshakeFailed است مانند شکل زیر:

   ( مشاهده تصویر بزرگتر )

   

7. اطلاعات مربوط به کد خطا messaging.adaptors.http.flow.SslHandshakeFailed مطابق شکل زیر نمایش داده می شود:

   ( مشاهده تصویر بزرگتر )

   

8. روی View logs کلیک کنید و ردیف درخواست ناموفق را گسترش دهید.

   ( مشاهده تصویر بزرگتر )

   
9. از پنجره Logs به جزئیات زیر توجه کنید:
   • شناسه پیام درخواستی
   • کد وضعیت: 503
   • منبع خطا: target
   • کد خطا: messaging.adaptors.http.flow.SslHandshakeFailed

ردیابی

روش شماره 2: با استفاده از ابزار Trace

برای تشخیص خطا با استفاده از ابزار Trace:

1. جلسه ردیابی و یکی را فعال کنید
   • صبر کنید تا خطای 503 Service Unavailable با کد خطا messaging.adaptors.http.flow.SslHandshakeFailed رخ دهد، یا
   • اگر می‌توانید مشکل را بازتولید کنید، با API تماس بگیرید تا مشکل 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 نشان می دهد که SSL Handshake شکست خورد، همانطور که Apigee Edge پردازشگر پیام نتوانست گواهی سرور پشتیبان را تأیید کند.
7. در Trace به فاز AX (Analytics Data Recorded) بروید و روی آن کلیک کنید.

8. به قسمت Phase Details Error Headers بروید و مقادیر 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 برای تعیین اطلاعات کلیدی در مورد 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-source است:

   سرصفحه ها	ارزش
   X-Apigee-fault-code	messaging.adaptors.http.flow.SslHandshakeFailed
   X-Apigee-fault-source	target

گزارش‌های پردازشگر پیام

روش شماره 4: استفاده از گزارش های پردازشگر پیام

1. شناسه پیام یکی از درخواست‌های ناموفق را با استفاده از API Monitoring، Trace tool یا NGINX Access Logs همانطور که در مراحل تشخیص رایج توضیح داده شده است، تعیین کنید.

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 Handshake ناموفق است زیرا پردازشگر پیام Apigee Edge قادر به تأیید اعتبار گواهی سرور باطن نیست.

فاز 1

فاز 1: زنجیره گواهی سرور باطن را تعیین کنید

از یکی از روش های زیر برای تعیین زنجیره گواهی سرور backend استفاده کنید:

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. زنجیره گواهی سرور backend را تعیین کنید .
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 UI، Environments > References را انتخاب کنید. به نام موجود در ستون Reference برای مرجع خاص Truststore توجه کنید. این نام فروشگاه اعتماد شما خواهد بود.

      ( مشاهده تصویر بزرگتر )

      

   4. در مثال بالا، نام Truststore این است:

      myCompanyTrussttoreRef : myCompanyTruststore

3. گواهی های ذخیره شده در Truststore (که در مرحله قبل تعیین شد) را با استفاده از API های زیر دریافت کنید:

   1. همه گواهی‌های یک فروشگاه کلید یا فروشگاه اعتماد را دریافت کنید . این API تمام گواهی‌های موجود در فروشگاه اعتماد خاص را فهرست می‌کند.

      کاربر عمومی ابر:

      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 شما تنظیم شده است همانطور که در Obtain an Access OAuth 2.0 توضیح داده شده است.
      • گزینه های curl مورد استفاده در این مثال در Use curl توضیح داده شده است

      خروجی نمونه:

      گواهی‌های نمونه Truststore myCompanyTruststore عبارتند از:

      [
        "serverCert"
      ]

   2. جزئیات گواهی را برای گواهی خاص از فروشگاه Keystore یا Truststore دریافت کنید . این API اطلاعات مربوط به یک گواهی خاص را در فروشگاه اعتماد خاص برمی گرداند.

      کاربر عمومی ابر:

      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 شما تنظیم شده است همانطور که در Obtain an Access OAuth 2.0 توضیح داده شده است.
      • گزینه های curl مورد استفاده در این مثال در Use 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 با سرور Backend مطابقت دارد.

   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 با سرور Backend مطابقت دارد.

   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 به برنامه های سرویس گیرنده برمی گرداند.

FQDN صحیح

فروشگاه کلید سرور باطن را با FQDN صحیح، زنجیره گواهی معتبر و کامل به روز کنید:

1. اگر گواهی سرور پشتیبان با FQDN صحیح ندارید، گواهی مناسب را از یک CA (مرجع صدور گواهی) مناسب تهیه کنید.

2. تأیید کنید که یک زنجیره گواهی سرور باطن معتبر و کامل دارید .

3. هنگامی که زنجیره گواهی معتبر و کامل با FQDN صحیح سرور باطن را در برگه یا گواهی موجودیت که با نام میزبان مشخص شده در نقطه پایانی هدف یکسان است، دارید ، فروشگاه کلید backend را با زنجیره گواهی کامل به روز کنید.

سرور باطن صحیح

نقطه پایانی هدف را با نام میزبان سرور باطن صحیح به روز کنید:

1. اگر نام میزبان به اشتباه در نقطه پایانی هدف مشخص شده است، سپس نقطه پایانی هدف را به‌روزرسانی کنید تا نام میزبان صحیحی داشته باشد که با FQDN در گواهی سرور باطن مطابقت داشته باشد.

2. تغییرات را در پروکسی API ذخیره کنید.

   در مثالی که در بالا توضیح داده شد، اگر نام میزبان سرور باطن به اشتباه مشخص شده باشد، می‌توانید با استفاده از 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>