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

מעקב באמצעות API

הליך מס' 1: שימוש ב-API Monitoring

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

1. נכנסים לממשק המשתמש של Apigee Edge בתור משתמשים עם תפקיד מתאים.

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

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

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

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: שימוש בכלי המעקב

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

1. מפעילים את סשן המעקב ואז
   • להמתין עד שתתרחש השגיאה 503 Service Unavailable עם קוד השגיאה messaging.adaptors.http.flow.SslHandshakeFailed, או
   • אם הצלחת לשחזר את הבעיה, יש לבצע את הקריאה ל-API כדי לשחזר את הבעיה 503 Service Unavailable

2. יש לוודא שהאפשרות Show allflowInfos מופעלת:

   
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:

כותרות השגיאות	Value
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

   כותרות	Value
   X-Apigee-fault-code	messaging.adaptors.http.flow.SslHandshakeFailed
   X-Apigee-fault-source	target

יומנים של מעבד ההודעות

הליך מס' 4: שימוש ביומנים של מעבד ההודעות

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

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

      

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

      myCompanyTruststoreRef: myCompanyTruststore

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

   1. קבלת כל האישורים ל-Keystore או ל-Truststore ה-API הזה מציג רשימה של כל האישורים ב-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"
      

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

      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. קבלת פרטי Cert עבור האישור הספציפי מ-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. יש לוודא שיש התאמה בין אישור השרת שהתקבל בשלב 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
      

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

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

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

תיקון שרת הקצה העורפי

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

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

2. שומרים את השינויים בשרת ה-API של שרת ה-proxy.

   בדוגמה שלמעלה, אם שם המארח של שרת הקצה העורפי צוין באופן שגוי, אפשר לתקן אותו באמצעות ה-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>