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

API Monitoring

תהליך מספר 1: שימוש ב-API Monitoring

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

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

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

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

5. משרטטים את קוד התקלה מול הזמן.

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

   ( הגדלת התמונה)

   

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

   ( הגדלת התמונה)

   

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

   ( הגדלת התמונה)

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

מעקב

תהליך מספר 2: שימוש בכלי המעקב

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

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

2. מוודאים שהאפשרות הצגת כל פרטי הזרימה מופעלת:

   
3. בוחרים אחת מהבקשות שנכשלו ובודקים את המעקב.
4. עוברים בין השלבים השונים של ה-trace ומאתרים את המקום שבו התרחשה הכשל.

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
   • 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. עוברים לשלב AX (נתוני Analytics שתועדו) בנתוני המעקב ולוחצים עליו.

8. גוללים למטה לקטע Phase Details Error Headers (כותרות שגיאה של פרטי השלב) ומזהים את הערכים של X-Apigee-fault-code (קוד שגיאה של Apigee),‏ X-Apigee-fault-source (מקור השגיאה של Apigee) ו-X-Apigee-Message-ID (מזהה ההודעה של Apigee), כמו שמוצג בהמשך:

   ( הגדלת התמונה)

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

      ( הגדלת התמונה)

      

   4. בדוגמה שלמעלה, שם מאגר האישורים הוא:

      ‫myCompanyTruststoreRef: myCompanyTruststore

3. מקבלים את האישורים שמאוחסנים במאגר האישורים (שנקבע בשלב הקודם) באמצעות ממשקי ה-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"
      

      משתמש ב-Private 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.

      פלט לדוגמה:

      האישורים ממאגר האישורים לדוגמה myCompanyTruststore הם:

      [
        "serverCert"
      ]

   2. קבלת פרטי אישור עבור אישור ספציפי ממאגר מפתחות או ממאגר אישורים מהימנים ממשק ה-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"
      

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

      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 זהה לאישור שאוחסן במאגר האישורים שהתקבל בשלב 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",

      האישור של עלה העץ שמאוחסן במאגר האישורים תואם לזה של שרת הקצה העורפי.

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

      אישור הביניים שמאוחסן במאגר האישורים זהה לזה של שרת הקצה העורפי.

   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. מכיוון שאישור הבסיס חסר במאגר האישורים, מעבד ההודעות יוצר את החריגה הבאה:

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