דף זה תורגם על ידי Cloud Translation API.

כשלים בלחיצת יד של SSL - אישור לקוח פגום

מוצג המסמך של Apigee Edge.
עוברים אל מסמכי תיעוד של Apigee X. מידע

תיאור הבעיה

אפליקציית הלקוח מקבלת קוד סטטוס HTTP של 503 עם את ההודעה "שירות לא זמין" בתגובה לבקשת API. במעקב בממשק המשתמש, תראו שהשגיאה error.cause הוא Received fatal alert: bad_certificate בתהליך היעד של הבקשה לגבי בקשת ה-API שנכשלה.

אם יש לכם גישה ליומני מעבד ההודעות, הודעת השגיאה תופיע בתור Received fatal alert: bad_certificate לגבי בקשת ה-API שנכשלה. השגיאה הזו מופיעה במהלך לחיצת היד של SSL בין מעבד ההודעות לשרת הקצה העורפי בהגדרת TLS דו-כיוונית.

הודעת שגיאה

אפליקציית הלקוח מקבלת את קוד התגובה הבא:

HTTP/1.1 503 Service Unavailable

בנוסף, יכול להיות שתופיע הודעת השגיאה הבאה:

{
 "fault": {
    "faultstring":"The Service is temporarily unavailable",
    "detail":{
        "errorcode":"messaging.adaptors.http.flow.ServiceUnavailable"
    }
 }
}

משתמשים בענן פרטי יראו את השגיאה הבאה בבקשת ה-API הספציפית ביומני מעבד ההודעות /opt/apigee/var/log/edge-message-processor/system.log:

2017-10-23 05:28:57,813 org:org-name env:env-name api:apiproxy-name rev:revision-number messageid:message_id NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context.handshakeFailed() : SSLClientChannel[C:IP address:port # Remote host:IP address:port #]@65461 useCount=1 bytesRead=0 bytesWritten=0 age=529ms lastIO=529ms handshake failed, message: Received fatal alert: bad_certificate

סיבות אפשריות

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

הסיבה	תיאור	הוראות לפתרון בעיות שרלוונטיות
אין אישור לקוח	ל-Keystore שבו נעשה שימוש בנקודת הקצה (endpoint) של היעד של שרת היעד אין אישור לקוח.	משתמשי Edge בענן פרטי וציבורי
חוסר התאמה לרשות האישורים	רשות האישורים של אישור העלה (האישור הראשון בשרשרת האישורים) ב-Keystore של מעבד ההודעות לא תואם לאף אחת מרשויות האישורים שאושרו על ידי שרת הקצה העורפי.	משתמשי Edge בענן פרטי וציבורי

שלבים לאבחון נפוץ

מפעילים את המעקב בממשק המשתמש של Edge, מבצעים את הקריאה ל-API ומשחזרים את הבעיה.
בתוצאות המעקב בממשק המשתמש, מנווטים בכל שלב וקובעים איפה אירעה שגיאה. השגיאה הייתה מתרחשת בתהליך הבקשה ליעד.
בוחנים את התהליך שמציג את השגיאה. תוכלו לראות את השגיאה, כמו שהיא במעקב לדוגמה שבהמשך:
כמו שאפשר לראות בצילום המסך למעלה, הערך error.cause הוא "התקבלה התראה חמורה: Batal_certificate".

אם אתם משתמשים ב-Private Cloud, פעלו לפי ההוראות הבאות:

כדי למצוא את מזהה ההודעה של בקשת ה-API שנכשלה, אתם יכולים לקבוע את הערך של בערך של כותרת השגיאה "X-Apigee.Message-ID" בשלב שמצוין על ידי AX במעקב.

חיפוש מזהה ההודעה הזה ביומן מעבד ההודעות /opt/apigee/var/log/edge-message-processor/system.log וקובעים אם מצאתם מידע נוסף על השגיאה:

2017-10-23 05:28:57,813 org:org-name env:env-name api:apiproxy-name
rev:revision-number messageid:message_id NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context.handshakeFailed() :
SSLClientChannel[C:IP address:port # Remote host:IP address:port #]@65461 useCount=1
bytesRead=0 bytesWritten=0 age=529ms lastIO=529ms handshake failed, message: Received fatal alert: bad_certificate
2017-10-23 05:28:57,813 org:org-name env:env-name api:apiproxy-name
rev:revision-number messageid:message_id NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context.handshakeFailed() : SSLInfo:
KeyStore:java.security.KeyStore@52de60d9 KeyAlias:KeyAlias TrustStore:java.security.KeyStore@6ec45759
2017-10-23 05:28:57,814 org:org-name env:env-name api:apiproxy-name
rev:revision-number messageid:message_id NIOThread@0 ERROR ADAPTORS.HTTP.FLOW - RequestWriteListener.onException() :
RequestWriteListener.onException(HTTPRequest@6071a73d)
javax.net.ssl.SSLException: Received fatal alert: bad_certificate
at sun.security.ssl.Alerts.getSSLException(Alerts.java:208) ~[na:1.8.0_101]
at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1666) ~[na:1.8.0_101]
at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1634) ~[na:1.8.0_101]
at sun.security.ssl.SSLEngineImpl.recvAlert(SSLEngineImpl.java:1800) ~[na:1.8.0_101]
at com.apigee.nio.NIOSelector$SelectedIterator.findNext(NIOSelector.java:496) [nio-1.0.0.jar:na]
at com.apigee.nio.util.NonNullIterator.computeNext(NonNullIterator.java:21) [nio-1.0.0.jar:na]
at com.apigee.nio.util.AbstractIterator.hasNext(AbstractIterator.java:47) [nio-1.0.0.jar:na]
at com.apigee.nio.NIOSelector$2.findNext(NIOSelector.java:312) [nio-1.0.0.jar:na]
at com.apigee.nio.NIOSelector$2.findNext(NIOSelector.java:302) [nio-1.0.0.jar:na]
at com.apigee.nio.util.NonNullIterator.computeNext(NonNullIterator.java:21) [nio-1.0.0.jar:na]
at com.apigee.nio.util.AbstractIterator.hasNext(AbstractIterator.java:47) [nio-1.0.0.jar:na]
at com.apigee.nio.handlers.NIOThread.run(NIOThread.java:59) [nio-1.0.0.jar:na]

ביומן מעבד ההודעות היה דוח קריסות לגבי השגיאה Received fatal alert: bad_certificate, אבל לא יש מידע נוסף שמציין את הסיבה לבעיה.

כדי לחקור את הבעיה לעומק, צריך לתעד מנות TCP/IP באמצעות tcpdump.
1. אם אתם משתמשים בענן פרטי, תוכלו לתעד מנות TCP/IP בשרת הקצה העורפי או במעבד ההודעות. עדיף לתעד אותם בשרת העורפי בזמן שהמנות מפוענחות את השרת העורפי.
2. אם אתם משתמשים בענן ציבורי, עליכם לתעד את ה-TCP/IP מנות בשרת העורפי.
3. אחרי שמחליטים איפה לתעד את חבילות ה-TCP/IP, משתמשים מתחת ל-tcpdump הפקודה כדי לתעד חבילות TCP/IP.
לנתח את חבילות ה-TCP/IP באמצעות הכלי Wireshark או כלי דומה שאתם מכירים.

כך מנתחים נתונים לדוגמה של חבילות TCP/IP באמצעות הכלי Wireshark:

טקסט_אלטרנטיבי

הודעה מס' 4 ב-tcpdump שלמעלה מראה שמעבד ההודעות (מקור) נשלחה הודעת "Client Hello" לשרת העורפי (יעד).
הודעה מס' 5 מראה ששרת הקצה העורפי מאשר את הודעת Client Hello ממעבד ההודעות.
שרת הקצה העורפי שולח את הפקודה "Server Hello" יחד עם האישור שלה, ואז מבקש מהלקוח לשלוח את האישור שלו בהודעה מס' 7.
מעבד ההודעות משלים את האימות של האישור ומאשר הודעת ServerHello בהודעה מס' 8 של שרת הקצה העורפי.
מעבד ההודעות שולח את האישור שלו לשרת הקצה העורפי בהודעה מס' 9.
שרת הקצה העורפי מאשר שהוא קיבל את אישור בהודעה מס' 11.
עם זאת, היא שולחת באופן מיידי התראה חמורה: אישור פגום אל מעבד הודעות (הודעה 12). מציין שהאישור שנשלח על ידי מעבד ההודעות לא היה תקין ולכן אימות האישור נכשל את השרת העורפי. כתוצאה מכך, לחיצת היד של SSL נכשלה והחיבור נכשל ייסגר.
עכשיו נסתכל על הודעה מס' 9 כדי לבדוק את תוכן האישור שנשלח על ידי מעבד ההודעות:
כפי שניתן לראות, שרת הקצה העורפי לא קיבל אישור מהלקוח (אורך האישור: 0). לכן, שרת הקצה העורפי שולח את ההתראה חמורה: אישור פגום.
בדרך כלל זה קורה כאשר הלקוח, כלומר מעבד ההודעות (תהליך מבוסס Java):
1. אין לו אישור לקוח ב-KeyStore, או;
2. אין לו אפשרות לשלוח אישור לקוח. זה יכול לקרות אם לא ניתן למצוא את אישור שמונפק על ידי אחת מרשויות האישורים הקבילות של שרת הקצה העורפי. כלומר, אם רשות האישורים של אישור העלה הירוק של הלקוח (כלומר, האישור הראשון בשרשרת) לא תואם לאף אחד משרתי הקצה העורפי רשויות אישורים קבילות, מעבד ההודעות לא ישלח את האישור.

נבחן כל אחת מהסיבות האלה בנפרד, לפי הפירוט הבא.

הסיבה: אין אישור לקוח

אבחון

אם לא מופיע אישור ב-Keystore כפי שצוין בקטע 'פרטי SSL'. של נקודת הקצה (endpoint) של היעד או של שרת היעד שבו נעשה שימוש בנקודת הקצה (endpoint) של היעד. זו הסיבה לשגיאה.

כדי לבדוק אם זו הסיבה, יש לפעול לפי השלבים הבאים:

קביעת ה-Keystore שבו ייעשה שימוש בנקודת הקצה (endpoint) או בשרת היעד עבור שרת ה-proxy ל-API ספציפי, באמצעות השלבים הבאים:
1. קבלת שם העזר של Keystore מהאלמנט Keystore בקטע SSLInfo בנקודת הקצה היעד או בשרת היעד.
  בואו נבחן קטע לדוגמה של SSLInfo בהגדרת יעד של נקודת קצה (Target Endpoint):
```
<SSLInfo>
  <Enabled>true</Enabled>
  <ClientAuthEnabled>true</ClientAuthEnabled>
  <KeyStore>ref://myKeystoreRef</KeyStore>
  <KeyAlias>myKey</KeyAlias>
  <TrustStore>ref://myTrustStoreRef</TrustStore>
</SSLInfo>
```
2. בדוגמה שלמעלה, שם ההפניה ל-Keystore הוא myKeystoreRef.
3. עוברים לממשק המשתמש של Edge ובוחרים באפשרות API proxy -> הגדרות הסביבה.
  בוחרים בכרטיסייה References (קובצי עזר) ומחפשים את שם קובץ העזר של Keystore. רושמים בצד את השם בעמודה Reference (הפניה) של ההפניה הספציפית ל-Keystore. זה יהיה השם שלך ב-Keystore.
4. בדוגמה שלמעלה, אפשר לראות ש-myKeystoreRef כולל את ל-myKeystore. לכן, השם של Keystore הוא myKeystore.
בודקים אם ה-Keystore הזה מכיל את האישור באמצעות ממשק המשתמש של Edge או הצגת רשימה של אישורים ל-keystore API.
אם ה-Keystore מכיל אישורים, עוברים אל הסיבה: חוסר התאמה לרשות האישורים.
אם ה-Keystore לא מכיל אישור, זו הסיבה. אישור הלקוח לא נשלח על ידי מעבד ההודעות.

רזולוציה

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

הסיבה: חוסר התאמה לרשות האישורים

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

כדי לבדוק אם זה המצב, פועלים לפי השלבים הבאים:

הצגת רשימה של אישורים ל-keystore API.
מקבלים את הפרטים של כל אישור שקיבלתם בשלב 1 למעלה באמצעות קבלת אישור ל-Keystore API.

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

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

{
  "certInfo" : [ {
    "basicConstraints" : "CA:FALSE",
    "expiryDate" : 1578889324000,
    "isValid" : "Yes",
    "issuer" : "CN=MyCompany Test SHA2 CA G2, DC=testcore, DC=test, DC=dir, DC=mycompany, DC=com",
    "publicKey" : "RSA Public Key, 2048 bits",
    "serialNumber" : "65:00:00:00:d2:3e:12:d8:56:fa:e2:a9:69:00:06:00:00:00:d2",
    "sigAlgName" : "SHA256withRSA",
    "subject" : "CN=nonprod-api.mycompany.com, OU=ITS, O=MyCompany, L=MELBOURNE, ST=VIC, C=AU",
    "subjectAlternativeNames" : [ ],
    "validFrom" : 1484281324000,
    "version" : 3
  } ],
  "certName" : "nonprod-api.mycompany.com.key.pem-cert"
}

בדוגמה שלמעלה, רשות האישורים/המנפיק היא "CN=MyCompany Test SHA2 CA G2, DC=testcore, DC=test, DC=dir, DC=mycompany, DC=com"

אפשר לקבוע את רשימת המנפיקים או רשויות האישורים של שרת הקצה העורפי באמצעות אחת מהשיטות הבאות:
שיטה מס' 1: משתמשים בפקודה opensl הבאה:
```
openssl s_client -host <backend server host name> -port <Backend port#> -cert <Client Certificate> -key <Client Private Key>
```
יש לעיין בסעיף "שמות קבילים של אישורי לקוח". בפלט של הפקודה הבאה:
```
Acceptable client certificate CA names
/C=AU/ST=VIC/L=MELBOURNE/O=MyCompany/OU=ITS/CN=nonprod-api.mycompany.com
/C=AU/ST=VIC/L=MELBOURNE/O=MyCompany/OU=ITS/CN=nonprod-api.mycompany.com
```
שיטה שנייה: בדיקת החבילה Certificate Request חבילות TCP/IP, שבהן שרת הקצה העורפי מבקש מהלקוח לשלוח את האישור שלו:

בחבילות ה-TCP/IP לדוגמה שמוצגות למעלה, Certificate Request חבילה היא הודעה מס' 7. עיין בקטע "שמות ייחודיים". שמכיל את 'רשויות האישורים המקובלות' של שרת הקצה העורפי.

הערה: רשימת "רשויות האישורים המקובלות" של שרת הקצה העורפי מאוכלס על ידי הוספת המנפיקים של כל האישורים שמאוחסנים ב-Truststore של שרת הקצה העורפי.
מוודאים שרשות האישורים שהשיגה בשלב 3 תואמת לרשימה מהמנפיקים או מרשויות האישורים המותרים של שרת הקצה העורפי שהתקבלו בשלב 4. אם יש התאמה, מעבד ההודעות לא ישלח את אישור הלקוח לשרת העורפי.

בדוגמה שלמעלה ניתן לראות שמנפיק אישור העלה הירוק של הלקוח ב-Keystore של מעבד ההודעות לא תואם לאף אחד רשויות אישורים קבילות. לכן, מעבד ההודעות לא שליחת אישור הלקוח לשרת הקצה העורפי. הדבר גורם ללחיצת היד של SSL להיכשל ושרת הקצה העורפי שולח "Fatal alert: bad_certificate" הודעה.

רזולוציה

מוודאים שהאישור מרשות המנפיק או מרשות האישורים (Certificate Authority) תואם לו. המנפיק/רשות האישורים של אישור העלה של הלקוח (אישור ראשון) בשרשרת) מאוחסנים ב-Truststore של שרת הקצה העורפי.
בדוגמה שמתוארת בחוברת ההדרכה הזו, האישור עם המנפיק "issuer" : "CN=MyCompany Test SHA2 CA G2, DC=testcore, DC=test, DC=dir, DC=mycompany, DC=com" נוסף ל-Truststore של שרת הקצה העורפי כדי לפתור את הבעיה.

אם הבעיה עדיין נמשכת, עוברים אל פרטי האבחון שחובה לאסוף.

יש לאסוף פרטי אבחון

אם הבעיה נמשכת גם לאחר ביצוע ההוראות שלמעלה, עליך לאסוף את פרטי האבחון הבאים. פונים אליהם ומשתפים אותם עם תמיכה ב-Apigee Edge:

אם אתם משתמשים בענן ציבורי, עליכם לספק את הפרטים הבאים:
1. שם הארגון
2. שם הסביבה
3. שם ה-API של ה-Proxy
4. צריך להשלים את פקודת ה-curl כדי לשחזר את השגיאה
5. קובץ מעקב שמציג את השגיאה
6. מנות TCP/IP שתועדו בשרת הקצה העורפי
אם אתם משתמשים בענן פרטי, עליכם לספק את הפרטים הבאים:
1. זוהה הודעת שגיאה מלאה
2. חבילת API Proxy
3. קובץ מעקב שמציג את השגיאה
4. יומני מעבד ההודעות /opt/apigee/var/log/edge-message-processor/logs/system.log
5. מנות TCP/IP שהוקלטו בשרת הקצה העורפי או במעבד ההודעות.
6. הפלט של Get cert for keystore API.
פרטים על הקטעים במדריך הזה שניסית ועל כל חלק אחר תובנות שיעזרו לנו לפתור את הבעיה הזו במהירות.