503 השירות לא זמין - לחיצת יד ב-SSL נכשלה

מעקב API

הליך מס' 1: שימוש במעקב API

כדי לאבחן את השגיאה באמצעות API Monitoring:

1. נכנסים ל-Apigee Edge UI כמשתמש עם התפקיד המתאים.

2. עוברים לארגון שבו רוצים לחקור את הבעיה.

   
3. מנווטים אל ניתוח > מעקב API > לחקור את הדף.
4. בוחרים את מסגרת הזמן הספציפית שבה הבחנתם בשגיאות.

5. הציגו את קוד התקלה ביחס ל-Time.

6. צריך לבחור תא עם קוד השגיאה messaging.adaptors.http.flow.SslHandshakeFailed כפי שמוצג למטה:

   ( הצגת תמונה גדולה יותר)

   

7. מידע על קוד התקלה messaging.adaptors.http.flow.SslHandshakeFailed מוצג בתור מוצגת למטה:

   ( הצגת תמונה גדולה יותר)

   

8. לוחצים על צפייה ביומנים ומרחיבים את השורה של הבקשה שנכשלה.

   ( הצגת תמונה גדולה יותר)

   
9. בחלון יומנים שימו לב לפרטים הבאים:
   • מזהה ההודעה של הבקשה
   • קוד סטטוס: 503
   • מקור התקלה: target
   • קוד התקלה: messaging.adaptors.http.flow.SslHandshakeFailed

Trace

הליך מס' 2: שימוש בכלי המעקב

כדי לאבחן את השגיאה באמצעות כלי המעקב:

1. להפעיל את סשן המעקב ואז
   • צריך להמתין לשגיאה 503 Service Unavailable עם קוד השגיאה messaging.adaptors.http.flow.SslHandshakeFailed יתרחשה, או
   • אם הצלחתם לשחזר את הבעיה, יש לבצע את הקריאה ל-API כדי לשחזר את הבעיה 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 (נתוני Analytics מתועדים) במעקב ולוחצים עליו.

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. אם אתם משתמשים של ענן פרטי, אתם יכולים להשתמש ביומני הגישה ל-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, כלי המעקב, או יומני גישה ל-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, בוחרים באפשרות Environments > (סביבה) > קובצי עזר. חשוב לזכור את השם העמודה הפניה לקובץ העזר הספציפי של ה-Truststore. זה יהיה השם של ה-Truststore.

      ( הצגת תמונה גדולה יותר)

      

   4. בדוגמה שלמעלה שם ה-Truststore הוא:

      myCompanyTruststoreRef: myCompanyTruststore

3. קבלת האישורים שמאוחסנים ב-Truststore (כפי שנקבע בשלב הקודם) באמצעות ממשקי ה-API הבאים:

   1. קבלת כל האישורים של מאגר מפתחות או מאגר אמון. ב-API הזה מפורטים כל אישורים במאגר האמון הספציפי.

      משתמש ב-Public 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"
      

      משתמש בענן פרטי:

      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.

      משתמש ב-Public 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"
      

      משתמש בענן פרטי

      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
      

      ממאגר ה-Trust של מעבד ההודעות (הלקוח):

      "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
      

      ממאגר ה-Trust של מעבד ההודעות (הלקוח):

      "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
      

      האישור הבסיסי (root) חסר לחלוטין ב-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 הנכון, להשיג את האישור המתאים מרשות אישורים מתאימה.

2. מוודאים שיש לכם שרשרת האישורים של שרת הקצה העורפי תקינה ומלא.

3. כשיש לך שרשרת אישורים תקינה ומלאה עם ה-FQDN הנכון של שרת עורפי באישור הישות או העלה הזהה לשם המארח שצוין בנקודת הקצה (endpoint) של היעד, מעדכנים את מאגר המפתחות של הקצה העורפי עם להשלים את שרשרת האישורים.

שרת עורפי נכון

מעדכנים את נקודת הקצה כיעד בשם המארח הנכון של שרת הקצה העורפי:

1. אם שם המארח צוין באופן שגוי בנקודת הקצה של היעד, יש לעדכן את שנקודת הקצה כיעד תהיה בעלת שם המארח הנכון שתואם ל-FQDN אישור השרת.

2. שומרים את השינויים שבוצעו בשרת ה-proxy של ה-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>