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

אתם צופים במסמכי התיעוד של Apigee Edge.
כדאי לעיין במסמכי התיעוד של Apigee X. מידע

תיאור הבעיה

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

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

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

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

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

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

אבחון

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

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

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

     

   • אם בוחרים בהודעה 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 אם האלגוריתם של סט אלגוריתמים להצפנה (cipher suite) שבו נעשה שימוש על ידי הלקוח לא נתמך על ידי השרת בחיבור הנכנס (צפונה) או בחיבור היוצא (דרומה) ב-Apigee Edge. אפשר גם לקרוא על הסבר על חיבורים צפונה ודרומה.

אבחון

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

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

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

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

     

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

     

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

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

       

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

     

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

רזולוציה

צריך לוודא שהלקוח משתמש בסט אלגוריתמים להצפנה (cipher suite) שנתמכים על ידי השרת. כדי לפתור את הבעיה שמתוארת בקטע הקודם Diagnosis (אבחון), צריך להוריד ולהתקין את חבילת Java Cryptography Extension (JCE) ולכלול אותה בהתקנת Java כדי לתמוך באלגוריתמים של סט אלגוריתמים להצפנה (cipher suite) ברמה גבוהה.

אישור שגוי

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

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

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

הודעות שגיאה

יכול להיות שיוצגו הודעות שגיאה שונות בהתאם לסיבה לכישלון של לחיצת היד של 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

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

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

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

אבחון

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. קבלת שם האישור במאגר המפתחות:
      
      אם אתם משתמשים בענן פרטי, משתמשים ב-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. אפשר לקבל את פרטי האישור במאגר המפתחות באמצעות Edge management API.
      
      אם אתם משתמשים בענן פרטי:
      

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

      אם אתם משתמשי ענן ציבורי:
      

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

      דוגמה ל-cert::

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

רזולוציה

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

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

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

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

קובצי עזר

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

שרשרת אישורים לא מלאה או שגויה

אבחון

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

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

      אם אתם משתמשי ענן ציבורי:
      

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

   2. כדי לקבל את פרטי האישור במאגר המפתחות:
      
      אם אתם משתמשי Private Cloud:
      

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

      אם אתם משתמשי ענן ציבורי:
      

      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. בודקים אם השגיאה התרחשה בחיבור צפונה או דרומה. הנחיות נוספות לקביעת מקור הבעיה מופיעות במאמר קביעת מקור הבעיה.
2. מריצים את כלי השירות tcpdump כדי לאסוף מידע נוסף:
   • אם אתם משתמשי Private Cloud, אתם יכולים לאסוף את הנתונים tcpdump בשרת או בלקוח הרלוונטיים. לקוח יכול להיות אפליקציית הלקוח (עבור חיבורים נכנסים או חיבורים צפונה) או מעבד ההודעות (עבור חיבורים יוצאים או חיבורים דרומה). השרת יכול להיות נתב קצה (לחיבורים נכנסים או צפונה) או שרת קצה עורפי (לחיבורים יוצאים או דרומה) בהתאם להחלטה שלכם משלב 1.
   • אם אתם משתמשים ב-Public Cloud, אתם יכולים לאסוף את הנתונים tcpdump רק באפליקציית הלקוח (עבור חיבורים נכנסים או צפוניים) או בשרת העורפי (עבור חיבורים יוצאים או דרומיים), כי אין לכם גישה לנתב הקצה או למעבד ההודעות.

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

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

   דוגמה tcpdump שבה מוצגת השגיאה Certificate Unknown (אישור לא ידוע)

   
   

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

      
      

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

      

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

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

      2. כדי לקבל את פרטי האישור במאגר האישורים:

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

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

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

      2. מקבלים את פרטי האישור במאגר המפתחות:
         

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

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

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

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

רזולוציה

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

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

‫SNI Enabled Server

השגיאה 'לחיצת יד של TLS/SSL נכשלה' יכולה להתרחש כשהלקוח מתקשר עם שרת שמופעל בו Server Name Indication‏ (SNI), אבל ה-SNI לא מופעל בלקוח. הבעיה יכולה לקרות בחיבור צפונה או דרומה ב-Edge.

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

זיהוי של שרת עם SNI מופעל

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

   openssl s_client -connect hostname:port

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

   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 ומנסים להתחבר לשם המארח הרלוונטי של השרת (נתב Edge או שרת backend) על ידי העברת שם השרת כמו שמוצג בהמשך:

   openssl s_client -connect hostname:port -servername hostname

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

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

אבחון

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

   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. בחירה בהודעה Client Hello (בקשת התחברות של לקוח) מראה שמעבד ההודעות משתמש בפרוטוקול TLSv1.2.

      

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

        

   7. השגיאה הזו עשויה להתרחש בגלל אחת מהסיבות הבאות:
      • מעבד ההודעות לא משתמש באלגוריתמים של סט אלגוריתמים להצפנה (cipher suite) שנתמכים על ידי שרת הקצה העורפי.
      • שרת הקצה העורפי מופעל באמצעות 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 Handshake ולפתור את הבעיה, או אם אתם צריכים עזרה נוספת, אתם יכולים לפנות אל התמיכה של Apigee Edge. נשמח לקבל פרטים מלאים על הבעיה, כולל הפלט של tcpdump.