כשלים בלחיצת יד של 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. קובעים אם השגיאה התרחשה בצפון או חיבור דרום. לקבלת הנחיות נוספות קביעה, לראות לזהות מה מקור הבעיה.
  2. להריץ את tcpdump כדי לאסוף מידע נוסף:
    • אם אתם משתמשים בענן פרטי, אתם יכולים לאסוף את tcpdump בלקוח או בשרת הרלוונטיים. לקוח יכול להיות אפליקציית הלקוח (לנתונים נכנסים, או חיבורים צפונה) או את ההודעה מעבד (לחיבורים יוצאים או לכיוון דרום). שרת יכול להיות 'נתב Edge' (בשביל חיבורים נכנסים או שיוצאים צפונה) או לשרת העורפי (לחיבורים יוצאים או דרומה) בהתאם להחלטה שלכם בשלב 1.
    • אם את/ה משתמש/ת בענן ציבורי, יש לך אפשרות לאסוף את 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. החליטו אם השגיאה התרחשה חיבור הצפון או היוצא. לקבלת הנחיות נוספות לביצוע קביעה זו, בקר בכתובת קובעים מהו מקור הבעיה.
  2. להריץ את tcpdump כדי לאסוף מידע נוסף:
    • אם אתם משתמשים בענן פרטי, אתם יכולים לאסוף את tcpdump בלקוח או בשרת הרלוונטיים. לקוח יכול להיות אפליקציית הלקוח (לנתונים נכנסים, או חיבורים צפונה) או את ההודעה מעבד (לחיבורים יוצאים או לכיוון דרום). שרת יכול להיות 'נתב Edge' (בשביל חיבורים נכנסים או שיוצאים צפונה) או לשרת העורפי (לחיבורים יוצאים או דרומה) בהתאם להחלטה שלכם בשלב 1.
    • אם את/ה משתמש/ת בענן ציבורי, יש לך אפשרות לאסוף את 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 שבהמשך מראה שאפליקציית הלקוח (מקור) שלח "שלום לקוח" הודעה ל-Edge Router (יעד).

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

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

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

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

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


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

רזולוציה

עליכם לוודא שהלקוח משתמש באלגוריתמים של חבילת ההצפנה שנתמך על ידי השרת. כדי לפתור את הבעיה שתיארנו קודם בקטע 'אבחון', מורידים ומתקינים את חבילת Java Cryptography Extension (JCE) ולכלול אותה ב-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 והאישור במאגר המפתחות של הנתב להתאים לבחירה. לדוגמה, מתרחשת חוסר התאמה אם שם המארח שנעשה בו שימוש בכתובת האתר הוא myorg.domain.com בזמן שם המארח של האישור כולל את שם המארח ב-CN שלו בתור CN=something.domain.com.

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

      אם אתם משתמשים ב-Private Cloud, תוכלו להשתמש ב-Management API באופן הבא:
      curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs
       אם את/ה משתמש/ת בענן ציבורי, אפשר להשתמש ב-Management API באופן הבא:
      curl -v https://api.enterprise.apigee.com/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs
    2. קבלת פרטי האישור במאגר המפתחות באמצעות Edge management API.

      אם אתם משתמשים ב-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

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

      "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-orgyour-domain כשם חלופי לנושא, ולאחר מכן יש להעלות את הקובץ המלא למאגר המפתחות.

קובצי עזר

מאגרי מפתחות Truststores

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

אבחון

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

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

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

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


רזולוציה

  1. קבלת אישור (אם עדיין אין לך) שכולל אישור מלא ותקף שרשרת האישורים.
  2. מריצים את פקודת opensl הבאה כדי לאמת ששרשרת האישורים נכונה. הושלם: 
    openssl verify -CAfile root-cert -untrusted intermediate-cert main-cert
  3. מעלים את שרשרת האישורים המאומתת למאגר המפתחות.

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

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

אבחון

  1. קובעים אם השגיאה התרחשה בצפון או חיבור דרום. לקבלת הנחיות נוספות קביעה, לראות לזהות מה מקור הבעיה.
  2. להריץ את tcpdump כדי לאסוף מידע נוסף:
    • אם אתם משתמשים בענן פרטי, אתם יכולים לאסוף את tcpdump בלקוח או בשרת הרלוונטיים. לקוח יכול להיות אפליקציית הלקוח (לנתונים נכנסים, או חיבורים צפונה) או את ההודעה מעבד (לחיבורים יוצאים או לכיוון דרום). שרת יכול להיות 'נתב Edge' (בשביל חיבורים נכנסים או שיוצאים צפונה) או של שרת הקצה העורפי (לחיבורים יוצאים או דרומה) בהתאם להחלטה שלכם בשלב 1.
    • אם את/ה משתמש/ת בענן ציבורי, יש לך אפשרות לאסוף את 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. מעבד ההודעות (לקוח) שולח 'שלום לקוח' לשרת הקצה העורפי (שרת) בהודעה מס' 59.
    2. שרת הקצה העורפי שולח "Server Hello" למעבד ההודעות בהודעה #61.
    3. הם מאמתים באופן הדדי את האלגוריתמים של הפרוטוקול ושל חבילת ההצפנה שבהם נעשה שימוש.
    4. שרת הקצה העורפי שולח את הודעת האישור והשרת Hello Done מעבד ההודעות בהודעה מס' 68.
    5. מעבד ההודעות שולח את ההתראה החמורה "תיאור: אישור לא ידוע" בהודעה מס' 70.
    6. בדקתי שוב את הודעה מס' 70, ואין פרטים נוספים מלבד מהודעת התראה כפי שמוצג בהמשך:


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

    8. האישור של שרת הקצה העורפי והשרשרת המלאה שלו זמינים מתחת לקטע 'אישורים' כפי שמוצג באיור שלמעלה.
  7. אם נמצא שהאישור לא מוכר על ידי הנתב (צפון) או מעבד הודעות (דרום) כמו בדוגמה שלמעלה, ולאחר מכן פועלים לפי שלבים:
    1. מקבלים את האישור ואת השרשרת שלו שמאוחסנים במאגר האישורים הספציפי. (יש לעיין במידע לתצורת המארח הווירטואלי של הנתב ונקודת הקצה (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 של הנתב (צפון) או מעבד הודעות (דרום) תואם לאישור שמאוחסן מאגר המפתחות של אפליקציית הלקוח (צפון) או של שרת היעד (דרום), או שמתקבל מהפלט 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. לבדוק אם האישור מאוחסן במאגר המפתחות של הנתב (צפון) או מעבד הודעות (outhbound) תואם לאישור שמאוחסן במאגר הישויות האמינות של אפליקציית לקוח (צפון) או שרת יעד (יוצא), או זה שהתקבל מהפלט tcpdump. אם יש חוסר התאמה, זו הסיבה ל-SSL. כשל בלחיצת היד.
  9. אם יתברר שהאישור שנשלח על ידי שרת/לקוח פג תוקף, הלקוח/שרת דוחה את האישור ומופיעה הודעת ההתראה הבאה tcpdump:

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

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

רזולוציה

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

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

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

מופעל SNI שרת

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

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

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

  1. מריצים את הפקודה openssl ומנסים להתחבר לשם המארח הרלוונטי של השרת (Edge) נתב או שרת עורפי) בלי להעביר את שם השרת, כפי שמוצג בהמשך: 
    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. קובעים אם השגיאה התרחשה בצפון או חיבור דרום. לקבלת הנחיות נוספות קביעה, לראות לזהות מה מקור הבעיה.
  2. להריץ את tcpdump כדי לאסוף מידע נוסף:
    • אם אתם משתמשים בענן פרטי, אתם יכולים לאסוף את tcpdump בלקוח או בשרת הרלוונטיים. לקוח יכול להיות אפליקציית הלקוח (לנתונים נכנסים, או חיבורים צפונה) או את ההודעה מעבד (לחיבורים יוצאים או לכיוון דרום). שרת יכול להיות 'נתב Edge' (בשביל חיבורים נכנסים או שיוצאים צפונה) או של שרת הקצה העורפי (לחיבורים יוצאים או דרומה) בהתאם להחלטה שלכם בשלב 1.
    • אם את/ה משתמש/ת בענן ציבורי, יש לך אפשרות לאסוף את 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 התרחש בין הודעת הקצה מעבד ושרת קצה עורפי (חיבור יוצא).
    2. בהודעה מס' 4 בפלט של tcpdump שבהמשך ניתן לראות שמעבד ההודעות (מקור) שלח "שלום לקוח" לשרת הקצה העורפי (יעד).

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

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

    7. השגיאה הזו יכולה לקרות בגלל אחת מהסיבות הבאות:
      • מעבד ההודעות לא משתמש באלגוריתמים של חבילת ההצפנה שנתמכים על-ידי שרת עורפי.
      • שרת הקצה העורפי מופעל ב-SNI, אבל אפליקציית הלקוח לא שולחת את שם השרת.
    8. כדאי לקרוא בפירוט על הודעה מס' 3 (Client Hello) בפלט של tcpdump. שימו לב התוסף: 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.