כשלים בלחיצת יד של TLS/SSL

כרגע מוצג התיעוד של Apigee Edge.
כניסה למסמכי התיעוד של Apigee X. מידע

תיאור הבעיה

כשל בלחיצת יד של TLS/SSL מתרחש כשהלקוח והשרת לא יכולים ליצור תקשורת באמצעות פרוטוקול TLS/SSL. כשהשגיאה הזו מתרחשת ב-Apigee Edge, אפליקציית הלקוח מקבלת סטטוס HTTP 503 עם ההודעה Service Unavailable. השגיאה הזו מופיעה אחרי כל קריאה ל-API שבה מתרחשת כשל בלחיצת יד של TLS/SSL.

הודעות שגיאה

HTTP/1.1 503 Service Unavailable

הודעת השגיאה הזו מוצגת גם כשמתרחש כשל בלחיצת יד של TLS/SSL:

Received fatal alert: handshake_failure

גורמים אפשריים

TLS (Transport Layer Security, שקודמו הוא SSL) הוא טכנולוגיית האבטחה הסטנדרטית ליצירת קישור מוצפן בין שרת אינטרנט ללקוח אינטרנט, כמו דפדפן או אפליקציה. לחיצת יד היא תהליך שמאפשר ללקוח ולשרת של TLS/SSL ליצור קבוצה של מפתחות סודיים שאיתם הם יכולים לתקשר. במהלך התהליך, הלקוח והשרת:

1. מאשרים את גרסת הפרוטוקול שבה רוצים להשתמש.
2. בוחרים את אלגוריתם הקריפטוגרפי שבו רוצים להשתמש.
3. אימות אחד של השני באמצעות שליחה ואימות של אישורים דיגיטליים.

אם לחיצת היד של TLS/SSL מצליחה, לקוח ה-TLS/SSL והשרת מעבירים זה לזה את הנתונים באופן מאובטח. אחרת, אם מתרחשת כשל בלחיצת יד של TLS/SSL, החיבור מסתיים והלקוח מקבל את הודעת השגיאה 503 Service Unavailable.

סיבות אפשריות לכשלים בלחיצת יד של TLS/SSL הן:

הסיבה	‫תיאור	מי יכול לבצע את השלבים לפתרון בעיות
אי-התאמה בפרוטוקול	השרת אינו תומך בפרוטוקול שבו הלקוח משתמש.	משתמשים בענן פרטי וציבורי
חוסר התאמה בחבילת ההצפנה	השרת אינו תומך בחבילת ההצפנה שבה משתמש הלקוח.	משתמשים בענן פרטי וציבורי
אישור שגוי	שם המארח בכתובת ה-URL שבו הלקוח משתמש לא תואם לשם המארח באישור שמאוחסן בקצה השרת.	משתמשים בענן פרטי וציבורי
	שרשרת אישורים חלקית או לא חוקית מאוחסנת בצד הלקוח או השרת.	משתמשים בענן פרטי וציבורי
	אישור שגוי או שתוקפו פג נשלח על ידי הלקוח לשרת או מהשרת ללקוח.	משתמשים בענן פרטי וציבורי
שרת התומך ב-SNI	שרת הקצה העורפי מופעל באמצעות Server Name Indication (SNI). עם זאת, הלקוח לא יכול לתקשר עם שרתי ה-SNI.	למשתמשי ענן פרטי בלבד

חוסר התאמה בין פרוטוקול

כשל בלחיצת יד של TLS/SSL מתרחש אם הפרוטוקול שבו משתמש הלקוח אינו נתמך על ידי השרת בחיבור הנכנס (המאופף) או היוצא (מיוצא). ראו גם הסבר על חיבורים לכיוון צפון ודרום.

אבחון

1. בודקים אם השגיאה אירעה בחיבור northbound או southbound. לקבלת הנחיות נוספות תוכלו לעיין במאמר קביעת מקור הבעיה.
2. מפעילים את הכלי tcpdump כדי לאסוף מידע נוסף:
   • אם אתם משתמשים בענן פרטי, תוכלו לאסוף את הנתונים של tcpdump בלקוח או בשרת הרלוונטיים. הלקוח יכול להיות אפליקציית הלקוח (לחיבורים נכנסים או פונים צפונה) או מעבד ההודעות (לחיבורים יוצאים או לכיוון דרום). השרת יכול להיות נתב Edge (לחיבורים נכנסים או צפוניים) או שרת הקצה העורפי (לחיבורים יוצאים או לכיוון דרום) על סמך ההחלטה בשלב 1.
   • למשתמשים ב-Public Cloud יש אפשרות לאסוף את הנתונים של tcpdump רק באפליקציית הלקוח (לחיבורים נכנסים או צפוניים) או בשרת לקצה העורפי (לחיבורים יוצאים או לכיוון דרום), כי אין גישה ל-Edge Router או למעבד ההודעות.

   tcpdump -i any -s 0 host IP address -w File name
   

   למידע נוסף על השימוש בפקודה tcpdump, אפשר לעיין בנתוני tcpdump.
3. אפשר לנתח את הנתונים של tcpdump באמצעות הכלי Wireshark או כלי דומה.
4. הנה ניתוח לדוגמה של tcpdump באמצעות Wireshark:
   • בדוגמה הזו, אירע כשל בלחיצת היד של TLS/SSL בין מעבד ההודעות לבין השרת העורפי (החיבור היוצא או הדרום).
   • הודעה מס' 4 בפלט tcpdump שלמטה מראה שמעבד ההודעות (מקור) שלח את הודעת "הלקוח שלום" לשרת הקצה העורפי (יעד).
     

     

   • אם בוחרים בהודעה Client Hello, סימן שמעבד ההודעות משתמש בפרוטוקול TLSv1.2, כפי שמוצג כאן:

     

   • הודעה מס' 5 מציינת ששרת הקצה העורפי מאשר את הודעת Client Hello ממעבד ההודעות.
   • שרת הקצה העורפי שולח באופן מיידי התראה חמורה : סגירת ההודעה למעבד ההודעות (הודעה מס' 6). המשמעות היא שלחיצת היד של TLS/SSL נכשלה והחיבור ייסגר.

   • בהמשך להודעה 6, ניתן לראות שהסיבה לכשל בלחיצת היד של TLS/SSL היא ששרת הקצה העורפי תומך רק בפרוטוקול TLSv1.0, כפי שמתואר כאן:

     

   • מאחר שיש חוסר התאמה בין הפרוטוקול המשמש את מעבד ההודעות לבין השרת העורפי, השרת העורפי שלח את ההודעה: הודעת התראה חמורה: סגור התראה.

רזולוציה

מעבד ההודעות פועל באמצעות Java 8 ומשתמש בפרוטוקול TLSv1.2 כברירת מחדל. אם שרת הקצה העורפי לא תומך בפרוטוקול TLSv1.2, אפשר לבצע את אחת מהפעולות הבאות כדי לפתור את הבעיה:

1. צריך לשדרג את שרת הקצה העורפי כדי שיתמוך בפרוטוקול TLSv1.2. זהו פתרון מומלץ כי הפרוטוקול TLSv1.2 מאובטח יותר.
2. אם מסיבה כלשהי לא ניתן לשדרג את שרת הקצה העורפי באופן מיידי, אפשר לאלץ את מעבד ההודעות להשתמש בפרוטוקול TLSv1.0 כדי לתקשר עם שרת הקצה העורפי. לשם כך יש לבצע את השלבים הבאים:
   1. אם לא ציינת שרת יעד בהגדרה של TargetEndpoint של שרת ה-proxy, צריך להגדיר את הרכיב Protocol ל-TLSv1.0 כפי שמוצג כאן:

      <TargetEndpoint name="default">
       …
       <HTTPTargetConnection>
         <SSLInfo>
             <Enabled>true</Enabled>
             <Protocols>
                 <Protocol>TLSv1.0</Protocol>
             </Protocols>
         </SSLInfo>
         <URL>https://myservice.com</URL>
       </HTTPTargetConnection>
       …
      </TargetEndpoint>
      

   2. אם הגדרתם שרת יעד לשרת ה-proxy, עליכם להשתמש ב-API הזה לניהול כדי להגדיר את הפרוטוקול ל-TLSv1.0 בהגדרה הספציפית של שרת היעד.

חוסר התאמה בין אלגוריתמים להצפנה

כשל בלחיצת יד של TLS/SSL, אם אלגוריתם חבילת ההצפנה שבו הלקוח משתמש לא נתמך על ידי השרת בחיבור הנכנס (המאופף) או היוצא (מדרום) ב-Apigee Edge. כדאי לעיין גם ב הסבר על חיבורים לכיוון צפון ודרום.

אבחון

1. בודקים אם השגיאה אירעה בחיבור northbound או southbound. למידע נוסף על קבלת החלטה זו, ראו קביעת מקור הבעיה.
2. מפעילים את הכלי tcpdump כדי לאסוף מידע נוסף:
   • אם אתם משתמשים בענן פרטי, תוכלו לאסוף את הנתונים של tcpdump בלקוח או בשרת הרלוונטיים. הלקוח יכול להיות אפליקציית הלקוח (לחיבורים נכנסים או פונים צפונה) או מעבד ההודעות (לחיבורים יוצאים או לכיוון דרום). השרת יכול להיות נתב Edge (לחיבורים נכנסים או צפוניים) או שרת הקצה העורפי (לחיבורים יוצאים או לכיוון דרום) על סמך ההחלטה בשלב 1.
   • למשתמשים ב-Public Cloud יש אפשרות לאסוף את הנתונים של tcpdump רק באפליקציית הלקוח (לחיבורים נכנסים או צפוניים) או בשרת לקצה העורפי (לחיבורים יוצאים או לכיוון דרום), כי אין גישה ל-Edge Router או למעבד ההודעות.

   tcpdump -i any -s 0 host IP address -w File name
   

   למידע נוסף על השימוש בפקודה tcpdump, אפשר לעיין בנתוני tcpdump.
3. צריך לנתח את הנתונים של tcpdump באמצעות הכלי Wireshark או כל כלי אחר שאתם מכירים.
4. הנה ניתוח לדוגמה של הפלט tcpdump באמצעות Wireshark:
   • בדוגמה הזו, אירע כשל בלחיצת היד של TLS/SSL בין אפליקציית הלקוח לבין נתב Edge (חיבור צפוני). הפלט tcpdump נאסף בנתב של Edge.

   • הודעה מס' 4 בפלט tcpdump שבהמשך מראה שאפליקציית הלקוח (מקור) שלחה את ההודעה Client Hello (לקוח שלום) ל-Edge Router (יעד).

     

   • בחירה בהודעה של Client Hello מציינת שאפליקציית הלקוח משתמשת בפרוטוקול TLSv1.2.

     

   • בהודעה מס' 5 רואים ש-Edge Router מאשר את ההודעה "Client Hello" מאפליקציית הלקוח.
   • נתב Edge שולח באופן מיידי התראה חמורה : לחיצת יד נכשלה לאפליקציית הלקוח (הודעה מס' 6). המשמעות היא שלחיצת היד של TLS/SSL נכשלה והחיבור ייסגר.
   • בהמשך להודעה מס' 6, מוצגים הפרטים הבאים:
     • נתב Edge תומך בפרוטוקול TLSv1.2. המשמעות היא שהפרוטוקול תואם בין אפליקציית הלקוח לבין נתב Edge.

     • עם זאת, נתב Edge עדיין שולח לאפליקציית הלקוח את ההודעה התראה חמורה: אירע של לחיצת יד, כפי שמוצג בצילום המסך הבא:

       

   • השגיאה עשויה להיות בגלל אחת מהבעיות הבאות:
     • אפליקציית הלקוח לא משתמשת באלגוריתמים של חבילת ההצפנה שנתמכים על ידי נתב Edge.
     • נתב Edge תומך ב-SNI, אבל אפליקציית הלקוח לא שולחת את שם השרת.
   • הודעה מס' 4 בפלט של tcpdump כוללת את האלגוריתמים של חבילת ההצפנה שנתמכים על ידי אפליקציית הלקוח, כפי שמוצג כאן:

     

   • בקובץ /opt/nginx/conf.d/0-default.conf מופיעות רשימת האלגוריתמים של חבילת ההצפנה שנתמכים על ידי נתב Edge. בדוגמה הזו, נתב Edge תומך רק באלגוריתמים של חבילת הצפנה עם הצפנה גבוהה.
   • אפליקציית הלקוח לא משתמשת באף אחד מהאלגוריתמים של חבילת ההצפנה בהצפנה גבוהה. חוסר ההתאמה הזה הוא שגורם לכשל בלחיצת היד של TLS/SSL.
   • מאחר שה-Edge Router תומך ב-SNI, צריך לגלול למטה להודעה מס' 4 בפלט tcpdump ולוודא שאפליקציית הלקוח שולחת את שם השרת כראוי, כפי שמתואר באיור הבא:
     
     
     
   • אם השם הזה תקין, אפשר להסיק שכשל לחיצת היד של TLS/SSL אירע כי האלגוריתמים של חבילת ההצפנה שעליה נעשה שימוש באפליקציית הלקוח לא נתמכים על ידי נתב Edge.

רזולוציה

צריך לוודא שהלקוח משתמש באלגוריתמים של חבילת ההצפנה, שנתמכים על ידי השרת. כדי לפתור את הבעיה שתוארה בקטע הקודם 'אבחון', צריך להוריד ולהתקין את החבילה תוסף קריפטוגרפיה (JCE) של Java ולכלול אותה בהתקנת ה-Java, כדי לתמוך באלגוריתמים של חבילת הצפנה גבוהה.

אישור שגוי

כשל בלחיצת יד של TLS/SSL מתרחש אם יש אישורים שגויים ב-Keystore/truststore, בחיבור נכנס (לצפון) או בחיבור יוצא (מיוצא) ב-Apigee Edge. ראו גם הסבר על חיבורים לכיוון צפון ודרום.

אם הבעיה היא לצפון, ייתכן שיוצגו הודעות שגיאה שונות בהתאם לסיבה.

בקטעים הבאים מפורטות הודעות שגיאה לדוגמה, והשלבים לאבחון הבעיה ולפתרון שלה.

הודעות שגיאה

ייתכן שיוצגו הודעות שגיאה שונות בהתאם לגורם לכשל בלחיצת היד של TLS/SSL. לפניכם דוגמה להודעת שגיאה שאתם עשויים לראות כשאתם קוראים לשרת proxy ל-API:

* SSL certificate problem: Invalid certificate chain
* Closing connection 0
curl: (60) SSL certificate problem: Invalid certificate chain
More details here: http://curl.haxx.se/docs/sslcerts.html

גורמים אפשריים

הסיבות האופייניות לבעיה הזו הן:

הסיבה	‫תיאור	מי יכול לבצע את השלבים לפתרון בעיות
חוסר התאמה בשם המארח	שם המארח בכתובת ה-URL לא תואם לאישור במאגר המפתחות של הנתב. לדוגמה, אי-התאמה מתרחשת אם שם המארח בכתובת ה-URL הוא myorg.domain.com, בעוד שב-CN של האישור מופיע שם המארח בתור CN=something.domain.com.	משתמשי Edge פרטיים וציבוריים בענן
שרשרת אישורים חלקית או שגויה	שרשרת האישורים לא שלמה או שגויה.	משתמשי Edge פרטיים וציבוריים של Edge בלבד
אישור שתוקפו פג או לא ידוע שנשלח על ידי השרת או הלקוח	אישור שתוקפו פג או לא ידוע יישלח על ידי השרת או הלקוח בחיבור הצפוני או בחיבור לכיוון דרום.	משתמשי Edge Private Cloud ו-Edge Public Cloud

חוסר התאמה בשם המארח

אבחון

1. שימו לב לשם המארח שנעשה בו שימוש בכתובת ה-URL שהוחזרה על ידי הקריאה הבאה ל-Edge Management API:

   curl -v https://myorg.domain.com/v1/getinfo

   לדוגמה:

   curl -v https://api.enterprise.apigee.com/v1/getinfo

2. מקבלים את ה-CN שנמצא בשימוש באישור ששמור במאגר המפתחות הספציפי. אפשר להשתמש בממשקי ה-API הבאים לניהול Edge כדי לקבל את פרטי האישור:
   1. קבלת שם האישור ב-Keystore:
      
      אם אתם משתמשים ב-Private Cloud, השתמשו ב-Management API באופן הבא:
      

      curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs

      אם אתם משתמשים ב-Public Cloud, השתמשו ב-Management API באופן הבא:
      

      curl -v https://api.enterprise.apigee.com/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs
      

   2. אפשר לקבל את פרטי האישור ב-Keystore באמצעות ממשק ה-API לניהול Edge.
      
      אם אתם משתמשים בענן פרטי:
      

      curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs/cert-name
      

      אם אתם משתמשים ב-Public Cloud:
      

      curl -v https://api.enterprise.apigee.com/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs/cert-name
      

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

      "certInfo": [
          {
            "basicConstraints": "CA:FALSE",
            "expiryDate": 1456258950000,
            "isValid": "No",
            "issuer": "SERIALNUMBER=07969287, CN=Go Daddy Secure Certification Authority, OU=http://certificates.godaddy.com/repository, O=\"GoDaddy.com, Inc.\", L=Scottsdale, ST=Arizona, C=US",
            "publicKey": "RSA Public Key, 2048 bits",
            "serialNumber": "07:bc:a7:39:03:f1:56",
            "sigAlgName": "SHA1withRSA",
            "subject": "CN=something.domain.com, OU=Domain Control Validated, O=something.domain.com",
            "validFrom": 1358287055000,
            "version": 3
          },
      

      ה-CN של שם הנושא באישור הראשי הוא something.domain.com.

      מכיוון ששם המארח המשמש בכתובת ה-URL של בקשת ה-API (פרטים נוספים בשלב 1 למעלה) ושם הנושא באישור לא תואמים, מוצג כשל בלחיצת היד של TLS/SSL.

רזולוציה

אפשר לפתור את הבעיה הזו באחת משתי הדרכים הבאות:

• יש להשיג אישור (אם עדיין אין לך) של הנושא CN יש אישור כללי לחיפוש, ואז להעלות למאגר המפתחות את רשת האישורים המלאה החדשה. לדוגמה:

  "subject": "CN=*.domain.com, OU=Domain Control Validated, O=*.domain.com",

• יש להשיג אישור (אם עוד אין לכם אישור) עם CN קיים, אבל להשתמש ב-your-org.your-domain כשם חלופי לנושא, ואז להעלות את רשת האישורים המלאה למאגר המפתחות.

קובצי עזר

Keystores ו-Truststores

שרשרת אישורים חלקית או שגויה

אבחון

1. מקבלים את ה-CN שנמצא בשימוש באישור ששמור במאגר המפתחות הספציפי. אפשר להשתמש בממשקי ה-API הבאים לניהול Edge כדי לקבל את פרטי האישור:
   1. קבלת שם האישור ב-Keystore:
      
      אם אתם משתמשים ב-Private Cloud:
      

      curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs
      

      אם אתם משתמשים ב-Public Cloud:
      

      curl -v https://api.enterprise.apigee.com/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs
      

   2. פרטי האישור ב-Keystore:
      
      אם אתם משתמשים ב-Private Cloud:
      

      curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs/cert-name
      

      אם אתם משתמשים ב-Public Cloud:
      

      curl -v https://api.enterprise.apigee.com/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs/cert-name
      

   3. מאמתים את האישור ואת השרשרת, ומוודאים שהוא עומד בהנחיות שמפורטות במאמר איך פועלות שרשראות אישורים כדי לוודא שזו שרשרת אישורים תקינה ומלאה. אם רשת האישורים שמאוחסנת במאגר המפתחות אינה מלאה או לא תקינה, יופיע כשלון לחיצת היד של TLS/SSL.
   4. המסמך הגרפי הבא מציג אישור לדוגמה עם שרשרת אישורים לא חוקית, שבה אישור הביניים ואישור הבסיס לא תואמים:

   דוגמה לאישור ביניים ולאישור בסיס שבו המנפיק והנושא לא תואמים

   
   

רזולוציה

1. יש להשיג אישור (אם עדיין אין לך) אישור שכולל שרשרת אישורים מלאה ותקפה.
2. מריצים את פקודת ה-openssl הבאה כדי לוודא ששרשרת האישורים תקינה ומלאה:

   openssl verify -CAfile root-cert -untrusted intermediate-cert main-cert

3. מעלים את שרשרת האישורים המאומתת למאגר המפתחות.

אישור שפג תוקפו או לא ידוע שנשלח על ידי השרת או הלקוח

אם אישור שגוי או שפג תוקפו נשלח על ידי השרת או הלקוח בקצה הצפוני או בחיבור לדרום, בצד השני (שרת/לקוח) הבקשה תידחה, וכתוצאה מכך תתקבל שגיאת לחיצת יד בפרוטוקול TLS/SSL.

אבחון

1. בודקים אם השגיאה אירעה בחיבור northbound או southbound. לקבלת הנחיות נוספות תוכלו לעיין במאמר קביעת מקור הבעיה.
2. מפעילים את הכלי tcpdump כדי לאסוף מידע נוסף:
   • אם אתם משתמשים בענן פרטי, תוכלו לאסוף את הנתונים של tcpdump בלקוח או בשרת הרלוונטיים. הלקוח יכול להיות אפליקציית הלקוח (לחיבורים נכנסים או פונים צפונה) או מעבד ההודעות (לחיבורים יוצאים או לכיוון דרום). השרת יכול להיות נתב Edge (לחיבורים נכנסים או צפוניים) או שרת הקצה העורפי (לחיבורים יוצאים או לכיוון דרום) על סמך ההחלטה בשלב 1.
   • למשתמשים ב-Public Cloud יש אפשרות לאסוף את הנתונים של tcpdump רק באפליקציית הלקוח (לחיבורים נכנסים או צפוניים) או בשרת לקצה העורפי (לחיבורים יוצאים או לכיוון דרום), כי אין גישה ל-Edge Router או למעבד ההודעות.

   tcpdump -i any -s 0 host IP address -w File name
   

   למידע נוסף על השימוש בפקודה tcpdump, אפשר לעיין בנתוני tcpdump.
3. אפשר לנתח את הנתונים של tcpdump באמצעות Wireshark או כלי דומה.
4. מהפלט של tcpdump, קובעים את המארח (לקוח או שרת) שדוחה את האישור בשלב האימות.
5. אפשר לאחזר את האישור שנשלח מהקצה השני מהפלט של tcpdump, בתנאי שהנתונים לא מוצפנים. בעזרת האפשרות הזו אפשר להשוות בין האישור הזה לאישור שזמין ב-Truststore.
6. בודקים את הדוגמה tcpdump לגבי תקשורת ה-SSL בין מעבד ההודעות לבין השרת העורפי.

   דוגמה tcpdump להצגת אישור לא ידוע של שגיאה

   
   

   1. מעבד ההודעות (לקוח) שולח את 'Client Hello' לשרת הקצה העורפי (שרת) בהודעה מס' 59.
   2. שרת הקצה העורפי שולח את הפקודה 'Server Hello' למעבד ההודעות בהודעה מס' 61.
   3. הם מאמתים באופן הדדי את האלגוריתמים של חבילת ההצפנה והפרוטוקול שנעשה בהם שימוש.
   4. השרת העורפי שולח את ההודעה Certificate (אישור) ו-Server Hello Done למעבד ההודעות בהודעה מס' 68.
   5. מעבד ההודעות שולח את ההתראה הקטלנית "תיאור: אישור לא ידוע" בהודעה מס' 70.
   6. בהמשך להודעה 70, אין פרטים נוספים מלבד ההודעה הבאה:

      
      

   7. צריך לקרוא את הודעה מס' 68 כדי לקבל את הפרטים על האישור שנשלח על ידי השרת לקצה העורפי, כפי שמוצג באיור הבא:

      

   8. האישור של השרת העורפי והשרשרת המלאה שלו זמינים מתחת לקטע 'אישורים', כפי שמתואר באיור שלמעלה.
7. אם הנתב (צפון) או מעבד ההודעות (southbound) מתברר שהאישור לא ידוע, יש לבצע את השלבים הבאים:
   1. מקבלים את האישור ואת הרשת שלו שמאוחסנים ב-Truststore הספציפי. (יש לעיין בהגדרות של המארח הווירטואלי של הנתב ובהגדרת נקודת הקצה (endpoint) של מעבד ההודעות). אפשר להשתמש בממשקי ה-API הבאים כדי לקבל את הפרטים על האישור:
      1. משיגים את שם האישור ב-Truststore:

         curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/truststore-name/certs

      2. קבלת פרטי האישור ב-Truststore:

         curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/truststore-name/certs/cert-name

   2. צריך לבדוק אם האישור ששמור ב-Truststore של הנתב (northbound) או של מעבד ההודעות (southbound) תואם לאישור שמאוחסן במאגר המפתחות של אפליקציית הלקוח (northbound) או של שרת היעד (southbound), או לאישור שמתקבל מהפלט של tcpdump. אם יש אי התאמה, זו הסיבה לכשל בלחיצת היד של TLS/SSL.
8. אם אפליקציית הלקוח (northbound) או שרת היעד (יוצאים) מתברר שהאישור אינו ידוע, יש לבצע את השלבים הבאים:
   1. משיגים את כל שרשרת האישורים שנעשה בה שימוש באישור שמאוחסן במאגר המפתחות הספציפי. (יש לעיין בהגדרות של המארח הווירטואלי של הנתב ובהגדרת נקודת הקצה (endpoint) של היעד עבור מעבד ההודעות). אפשר להשתמש בממשקי ה-API הבאים כדי לקבל את הפרטים על האישור:
      1. מורידים את שם האישור ממאגר המפתחות:

         curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs

      2. הפרטים של האישור נשמרים ב-Keystore:
         

         curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs/cert-name
         

   2. צריך לבדוק אם האישור ששמור במאגר המפתחות של הנתב (צפון) או של מעבד ההודעות (southbound) תואם לאישור ששמור ב-Truststore של אפליקציית הלקוח (northbound) או של שרת היעד (southbound), או לאישור שמתקבל מהפלט tcpdump. אם יש אי-התאמה, זו הסיבה לכשל בלחיצת היד של SSL.
9. אם נקבע שתוקף האישור שנשלח על ידי שרת או לקוח פג, הלקוח/השרת המקבל דוחים את האישור ומופיעה הודעת ההתראה הבאה ב-tcpdump:

   התראה (רמה: חמורה, תיאור: פג תוקף האישור)

10. יש לוודא שתוקף האישור שבמאגר המפתחות של המארח המתאים פג.

רזולוציה

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

בטבלה הבאה מופיע סיכום של השלבים לפתרון הבעיה, בהתאם לגורם שלה.

הסיבה	‫תיאור	פתרון
אישור שפג תוקפו	NorthBound פג התוקף של האישור שמאוחסן במאגר המפתחות של הנתב. פג תוקפו של האישור שמאוחסן במאגר המפתחות של אפליקציית הלקוח (SSL דו-כיווני).	צריך להעלות אישור חדש ואת השרשרת המלאה שלו אל מאגר המפתחות במארח המתאים.
	SouthBound פג תוקפו של האישור שמאוחסן במאגר המפתחות של שרת היעד. פג התוקף של האישור שמאוחסן במאגר המפתחות של מעבד ההודעות (SSL דו-כיווני).	צריך להעלות אישור חדש ואת השרשרת המלאה שלו אל מאגר המפתחות במארח המתאים.
אישור לא ידוע	NorthBound האישור שמאוחסן ב-Truststore של אפליקציית הלקוח לא תואם לאישור של הנתב. האישור שמאוחסן ב-Truststore של הנתב לא תואם לאישור של אפליקציית הלקוח (SSL דו-כיווני).	עליך להעלות את האישור התקף ל-Truststore במארח המתאים.
	SouthBound האישור שמאוחסן ב-Truststore של שרת היעד לא תואם לאישור של מעבד ההודעות. האישור שמאוחסן ב-Truststore של מעבד ההודעות לא תואם לאישור של שרת היעד (SSL דו-כיווני).	עליך להעלות את האישור התקף ל-Truststore במארח המתאים.

שרת שמופעל בו SNI

כשל בלחיצת היד של TLS/SSL יכול להתרחש כאשר הלקוח מתקשר עם שרת שמופעל בו SNI, אבל הלקוח לא תומך ב-SNI. הדבר יכול להתרחש בחיבור לכיוון צפון או בחיבור הדרומי ב-Edge.

תחילה עליך לזהות את שם המארח ואת מספר היציאה של השרת שבו נעשה שימוש, ולבדוק אם SNI מופעל או לא.

זיהוי שרת התומך ב-SNI

1. מריצים את הפקודה openssl ומנסים להתחבר לשם המארח הרלוונטי של השרת (Edge Router או שרת קצה עורפי) בלי להעביר את שם השרת, כפי שמוצג למטה:

   openssl s_client -connect hostname:port
   

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

   CONNECTED(00000003)
   9362:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:/BuildRoot/Library/Caches/com.apple.xbs/Sources/OpenSSL098/OpenSSL098-64.50.6/src/ssl/s23_clnt.c:593
   

2. מריצים את הפקודה openssl ומנסים להתחבר לשם המארח הרלוונטי של השרת (נתב קצה או שרת קצה עורפי) על ידי העברת שם השרת כפי שמוצג כאן:

   openssl s_client -connect hostname:port -servername hostname
   

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

לאחר שזיהית שהשרת תומך ב-SNI, אפשר לבצע את השלבים הבאים כדי לבדוק אם הכשל בלחיצת היד של TLS/SSL נגרם על ידי הלקוח שאינו יכול לתקשר עם שרת ה-SNI.

אבחון

1. בודקים אם השגיאה אירעה בחיבור northbound או southbound. לקבלת הנחיות נוספות תוכלו לעיין במאמר קביעת מקור הבעיה.
2. מפעילים את הכלי tcpdump כדי לאסוף מידע נוסף:
   • אם אתם משתמשים בענן פרטי, תוכלו לאסוף את הנתונים של tcpdump בלקוח או בשרת הרלוונטיים. הלקוח יכול להיות אפליקציית הלקוח (לחיבורים נכנסים או פונים צפונה) או מעבד ההודעות (לחיבורים יוצאים או לכיוון דרום). השרת יכול להיות נתב Edge (לחיבורים נכנסים או צפוניים) או שרת הקצה העורפי (לחיבורים יוצאים או לכיוון דרום) על סמך ההחלטה בשלב 1.
   • למשתמשים ב-Public Cloud יש אפשרות לאסוף את הנתונים של tcpdump רק באפליקציית הלקוח (לחיבורים נכנסים או צפוניים) או בשרת לקצה העורפי (לחיבורים יוצאים או לכיוון דרום), כי אין גישה ל-Edge Router או למעבד ההודעות.

   tcpdump -i any -s 0 host IP address -w File name
   

   למידע נוסף על השימוש בפקודה tcpdump, אפשר לעיין בנתוני tcpdump.
3. צריך לנתח את הפלט של tcpdump באמצעות Wireshark או כלי דומה.
4. הנה ניתוח לדוגמה של tcpdump באמצעות Wireshark:
   1. בדוגמה הזו, אירע כשל בלחיצת היד של TLS/SSL בין מעבד ההודעות של Edge לשרת הקצה העורפי (חיבור יוצא).
   2. בהודעה מס' 4 בפלט tcpdump שבהמשך אפשר לראות שמעבד ההודעות (מקור) שלח את ההודעה Client Hello לשרת הקצה העורפי (יעד).

      

   3. בחירה בהודעה 'שלום הלקוח' מציינת שמעבד ההודעות משתמש בפרוטוקול TLSv1.2.

      

   4. בהודעה מס' 4 רואים ששרת הקצה העורפי מאשר את ההודעה Client Hello (שלום ללקוח) ממעבד ההודעות.
   5. שרת הקצה העורפי שולח באופן מיידי התראה חמורה : כשל בלחיצת יד למעבד ההודעות (הודעה מס' 5). המשמעות היא שלחיצת היד של TLS/SSL נכשלה והחיבור ייסגר.
   6. בהודעה מס' 6 אפשר לראות את הפרטים הבאים
      • שרת הקצה העורפי תומך בפרוטוקול TLSv1.2. המשמעות היא שהפרוטוקול תאם בין מעבד ההודעות לבין השרת העורפי.
      • עם זאת, השרת העורפי עדיין שולח למעבד ההודעות את ההודעה התראה חמורה: אי-לחיצת יד, כפי שמוצג באיור הבא:

        

   7. השגיאה עשויה להתרחש בגלל אחת מהסיבות הבאות:
      • מעבד ההודעות לא משתמש באלגוריתמים של חבילת ההצפנה, שנתמכים על ידי שרת הקצה העורפי.
      • שרת הקצה העורפי מופעל באמצעות SNI, אבל אפליקציית הלקוח לא שולחת את שם השרת.
   8. סקירה מפורטת יותר של הודעה מס' 3 (Client Hello) בפלט tcpdump. שימו לב שהפרמטר Extension: server_name חסר, כפי שמוצג בהמשך:

      

   9. זהו אישור שמעבד ההודעות לא שלח את server_name לשרת הקצה העורפי שתומך ב-SNI.
   10. זו הסיבה לכשל בלחיצת היד של TLS/SSL, והסיבה לכך שהשרת העורפי שולח את ההודעה התראה חמורה: כשל בלחיצת יד למעבד ההודעות.
5. צריך לוודא שהשדה jsse.enableSNIExtension property ב-system.properties מוגדר כ-False במעבד ההודעות כדי לוודא שמעבד ההודעות לא מופעל לתקשר עם שרת שתומך ב-SNI.

רזולוציה

צריך לבצע את הפעולות הבאות כדי לאפשר למעבדי ההודעות לתקשר עם שרתים שתומכים ב-SNI:

1. יוצרים את הקובץ/opt/apigee/customer/application/message-processor.properties (אם הוא עדיין לא קיים).
2. מוסיפים את השורה הבאה לקובץ הזה: conf_system_jsse.enableSNIExtension=true
3. כוונו את הבעלים של הקובץ הזה ל-apigee:apigee:

   chown apigee:apigee /opt/apigee/customer/application/message-processor.properties

4. מפעילים מחדש את מעבד ההודעות.

   /opt/apigee/apigee-service/bin/apigee-service message-processor restart

5. אם יש לכם יותר ממעבד הודעות אחד, יש לחזור על השלבים 1 עד מס' 4 בכל מעבדי ההודעות.

אם אתם לא מצליחים לקבוע מה הסיבה לכשל בלחיצת יד של TLS/SSL ולפתור את הבעיה, או אם אתם צריכים עזרה נוספת, תוכלו לפנות לתמיכה של Apigee Edge. צריך לשתף את הפרטים המלאים על הבעיה יחד עם הפלט של tcpdump.