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

نظارت بر API

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

برای تشخیص خطا با استفاده از مانیتورینگ API:

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

2. به سازمانی که می‌خواهید مشکل را در آن بررسی کنید، مراجعه کنید.

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

5. رسم کد خطا در مقابل زمان .

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

   ( تصویر را بزرگتر ببینید )

   

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

   ( تصویر را بزرگتر ببینید )

   

8. روی «مشاهده گزارش‌ها» کلیک کنید و ردیف مربوط به درخواست ناموفق را باز کنید.

   ( تصویر را بزرگتر ببینید )

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

ردیابی

روش شماره ۲: استفاده از ابزار ردیابی

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

1. جلسه ردیابی را فعال کنید و یا
   • منتظر خطای 503 Service Unavailable با کد خطا messaging.adaptors.http.flow.SslHandshakeFailed باشید، یا
   • اگر می‌توانید مشکل را دوباره ایجاد کنید، فراخوانی API را برای ایجاد مجدد مشکل انجام دهید 503 Service Unavailable

2. مطمئن شوید که گزینه‌ی Show all FlowInfos فعال است:

   
3. یکی از درخواست‌های ناموفق را انتخاب کنید و مسیر پیگیری را بررسی کنید.
4. مراحل مختلف ردیابی را طی کنید و محل وقوع خرابی را پیدا کنید.

5. معمولاً پس از شروع مرحله‌ی «جریان درخواست هدف» (Target Request Flow Started)، این خطا را مشاهده خواهید کرد، همانطور که در زیر نشان داده شده است:

   ( تصویر را بزرگتر ببینید )

   
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
   • کلاس خطا: 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 نتوانسته گواهی سرور backend را اعتبارسنجی کند.
7. در مسیر ردیابی، به مرحله AX (داده‌های تحلیلی ثبت‌شده) بروید و روی آن کلیک کنید.

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	messaging.adaptors.http.flow.SslHandshakeFailed
منبع گسل X-Apigee	target
شناسه پیام X-Apigee	MESSAGE_ID

انجینکس

روش شماره ۳: استفاده از گزارش‌های دسترسی NGINX

برای تشخیص خطا با استفاده از گزارش‌های دسترسی NGINX:

1. اگر شما یک کاربر ابر خصوصی هستید، می‌توانید از گزارش‌های دسترسی NGINX برای تعیین اطلاعات کلیدی در مورد 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 را تعیین کنید.

   نمونه خطای ۵۰۳ از لاگ دسترسی NGINX:

   ( تصویر را بزرگتر ببینید )

   

   ورودی نمونه بالا از لاگ دسترسی NGINX دارای مقادیر زیر برای X-Apigee-fault-code و X-Apigee-fault-source است:

   سربرگ‌ها	ارزش
   کد خطای X-Apigee	messaging.adaptors.http.flow.SslHandshakeFailed
   منبع گسل X-Apigee	target

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

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

1. شناسه پیام یکی از درخواست‌های ناموفق را با استفاده از API Monitoring، ابزار Trace یا 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 handshake بین پردازنده پیام و سرور backend با شکست مواجه شده است.

   این با یک استثنا با ردیابی دقیق پشته، همانطور که در زیر نشان داده شده است، دنبال خواهد شد:

   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>
     

   توجه داشته باشید که عدم موفقیت در handshake به دلایل زیر است:

   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 قادر به اعتبارسنجی گواهی سرور backend نبوده است.

فاز ۱

مرحله ۱: تعیین زنجیره گواهی سرور backend

برای تعیین زنجیره گواهی سرور 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

فاز ۲

مرحله ۲: مقایسه گواهی سرور backend و گواهی‌های ذخیره شده در حافظه اعتماد پردازشگر پیام

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

      ( تصویر را بزرگتر ببینید )

      

   4. در مثال بالا نام فروشگاه اعتماد عبارت است از:

      فروشگاه اعتماد شرکت من مرجع : myCompanyTruststore

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

   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"
      

      کاربر ابر خصوصی:

      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. دریافت جزئیات گواهی برای گواهی خاص از یک Keystore یا Truststore . این API اطلاعات مربوط به یک گواهی خاص را در 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"
      

      کاربر ابر خصوصی

      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. تأیید کنید که گواهی سرور واقعی که در مرحله ۱ به دست آمده و گواهی ذخیره شده در truststore که در مرحله ۳ به دست آمده است، مطابقت دارند. اگر مطابقت نداشته باشند، دلیل مشکل همین است.

   از مثال بالا، بیایید به تک تک گواهی‌ها نگاهی بیندازیم:

   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",

      گواهی برگ ذخیره شده در فروشگاه اعتماد با گواهی سرور پشتیبان مطابقت دارد.

   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

      گواهی ریشه به طور کامل در مخزن اعتماد پردازشگر پیام (Message Processor) وجود ندارد.

   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 صحیح

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

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

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

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

سرور پشتیبان صحیح

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

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

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

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