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

400 בקשה לא תקינה - שגיאת אישור SSL

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

תיאור הבעיה

אפליקציית הלקוח מקבלת את התגובה HTTP 400 – בקשה לא תקינה עם ההודעה "שגיאת אישור ה-SSL". השגיאה הזו נשלחת בדרך כלל על ידי נתב Edge Router בהגדרה דו-כיוונית של TLS שמופעלת בחיבור הנכנס ל-Apigee Edge.

הודעת שגיאה

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

HTTP/1.1 400 Bad Request

לאחריו מופיע דף שגיאת ה-HTML הבא:

<html>
  <head>
    <title>400 The SSL certificate error</title>
  </head>
  <body bgcolor="white">
    <center> <h1>400 Bad Request</h1>
    </center>
    <center>The SSL certificate error</center>
    <hr>
    <center>nginx</center>
  </body>
</html>

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

הסיבות האפשריות לכך הן:

הסיבה	תיאור	הוראות לפתרון בעיות הרלוונטיות
אישור לקוח שפג תוקפו	פג תוקפו של האישור שנשלח על ידי הלקוח.	משתמשי Edge פרטיים וציבוריים בענן
אישור שגוי שנשלח על ידי לקוח	הודעת השגיאה הזאת מוצגת אם האישור שנשלח על ידי אפליקציית הלקוח לא תואם לאישור המאוחסן ב-Truststore של הנתב של Edge.	משתמשי Edge פרטיים וציבוריים בענן
חסר אישור Root של הלקוח ב-Truststore	השגיאה הזו מוצגת אם אישור הבסיס החתום בידי רשות האישורים של הלקוח חסר ב-Truststore של הנתב של Edge.	משתמשי Edge פרטיים וציבוריים בענן
אישורי לקוח לא נטענים בנתב Edge	השגיאה הזו מוצגת אם אישורי הלקוח שהועלו ל-Truststore לא נטענים בנתב.	משתמשי ענן פרטי של Edge

הסיבה: אישור לקוח שפג תוקפו

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

ב-Edge, TLS דו-כיווני מיושם במארח וירטואלי, שבו אישור השרת מתווסף ל-Keystore ואישור הלקוח מתווסף ל-Truststores.

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

אבחון

מתחברים לממשק המשתמש של Edge ומציגים את ההגדרה הספציפית של המארח הווירטואלי (ניהול > מארחים וירטואליים) שעבורם מתבצעת בקשת ה-API, או משתמשים בממשק ה-API לניהול של GetVirtual Host API כדי לקבל את ההגדרה של המארח הווירטואלי הספציפי.

בדרך כלל מארח וירטואלי לתקשורת TLS דו-כיוונית נראה כך:
```
<VirtualHost name="myTLSVHost">
    <HostAliases>
        <HostAlias>api.myCompany.com</HostAlias>
    </HostAliases>
    <Port>443</Port>
    <SSLInfo>
        <Enabled>true</Enabled>
        <ClientAuthEnabled>true</ClientAuthEnabled>
        <KeyStore>ref://myKeystoreRef</KeyStore>
        <KeyAlias>myKeyAlias</KeyAlias>
        <TrustStore>ref://myTruststoreRef</TrustStore>
    </SSLInfo>
</VirtualHost>
```
קביעת ההפניה ל-Truststore המשמשת במארח הווירטואלי. בדוגמה שלמעלה, שם ההפניה ב-Truststore הוא myTruststoreRef.
קביעת ה-Truststore שאליו מפנה ההפניה של Truststore.
1. בממשק המשתמש של Edge, עוברים אל ניהול > סביבות > הפניות ומחפשים את שם ההפניה ל-Truststore.
2. שימו לב לשם בעמודה הפניה של ההפניה הספציפית ל-Truststore. זה יהיה השם שלך ב-Truststore.
  
  איור 1
  
  בדוגמה שלמעלה, יש לשים לב שההפניה ל-myTruststoreRef כוללת את myTruststore. לכן, השם של Truststore הוא myTruststore.
נכנסים לקטע ניהול > סביבות > TLS Keystores בממשק המשתמש של Edge, עוברים ל-TLS Keystores ומחפשים את Truststore בשלב 3.
בוחרים את האישור מתוך Truststore הספציפי (נקבע בשלב 3 למעלה) כמו שמוצג בהמשך:

איור 2

האישור עם הכינוי client-cert-markw בדוגמה שלמעלה מראה שפג תוקפו.
בודקים אם פג תוקפו של האישור של כינוי האישור ל-Truststore.
אם התוקף של האישור עדיין לא פג, עוברים אל שלבים לאבחון בעיות נפוצות שגורמות לבעיות אחרות.

רזולוציה

השג אישור חדש והעלה את האישור:

יוצרים Truststore חדש, לדוגמה myNewTruststore.
מעלים את האישור החדש ל-Truststore החדש שנוצר.
משנים את ההפניה לישות המהימנות שבה נעשה שימוש במארח הווירטואלי הספציפי כדי להפנות אל ה-Truststore החדש באמצעות השלבים שמפורטים בשינוי קובץ עזר.

בדוגמה שמתוארת למעלה, מכוונים את ההפניה אל myTruststoreRef אל myNewTruststore.

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

כדי לבדוק את הבעיה, צריך לתעד מנות TCP/IP באמצעות הכלי tcpdump.
1. אם אתם משתמשים בענן פרטי, תוכלו לתעד את חבילות ה-TCP/IP באפליקציית הלקוח או בנתב.
2. אם אתם משתמשים ב-Public Cloud, עליכם לתעד את חבילות ה-TCP/IP באפליקציית הלקוח.
3. לאחר שתחליטו היכן תרצו לתעד מנות TCP/IP, השתמשו בפקודה tcpdump הבאה כדי לתעד חבילות TCP/IP:
```
tcpdump -i any -s 0 host <IP address> -w <File name>
```
  הערה: אם אתם משתמשים במנות TCP/IP בנתב, עליכם להשתמש בכתובת ה-IP הציבורית של אפליקציית הלקוח בפקודה tcpdump.
  
  אם אתם לוקחים את חבילות ה-TCP/IP באפליקציית הלקוח, עליכם להשתמש בכתובת ה-IP הציבורית של שם המארח שבו נעשה שימוש במארח הווירטואלי בפקודה tcpdump.
  
  ב-tcpdump אפשר לקרוא מידע נוסף על הכלי הזה ועל וריאנטים אחרים של הפקודה הזו.
נתחו את חבילות ה-TCP/IP שנאספו באמצעות הכלי Wireshark או כלי דומה שאתם מכירים.

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

בחבילה מס' 30 ב-tcpdump (בתמונה שלמטה) מוצג שאפליקציית הלקוח (מקור) שלחה הודעת 'לקוח שלום' לנתב (יעד).
חבילה מס' 34 מראה שהנתב מאשר את הודעת הלקוח של אפליקציית הלקוח.
הנתב שולח את השרת Hello בחבילה מס' 35, ולאחר מכן שולח את האישור שלו. בנוסף, הוא מבקש מאפליקציית הלקוח לשלוח את האישור בחבילה מס' 38.
בחבילה מספר 38, שבה הנתב שולח את המנה "Certificate Request", בודקים את הקטע "Distinguished Names", שבו מופיעים פרטים על אישור הלקוח, השרשרת ורשויות האישורים הקבילות על ידי הנתב (השרת).

אפליקציית הלקוח שולחת את האישור שלה בחבילה מס' 41. נכנסים לקטע Certificate verification בחבילה מס' 41 ובודקים איזה אישור נשלח על ידי אפליקציית הלקוח.

איור 4
צריך לוודא שהנושא והמנפיק של האישור והשרשרת שלו, שנשלחה על ידי אפליקציית הלקוח (חבילה מס' 41), תואמים לאישור שאושר ולשרשרת שלו מהנתב (חבילה מס' 38). אם יש אי התאמה, זו הסיבה לשגיאה. לכן, הנתב (שרת) שולח את ההתראה המוצפנת (חבילה מס' 57) ואחריה FIN, ACK (חבילה 58) לאפליקציית הלקוח, ובסופו של דבר החיבור מתבטל.
התרחישים המתוארים בסעיפים הבאים עלולים לגרום לחוסר ההתאמה בין האישור לבין השרשרת שלו.

הסיבה: אישור שגוי שנשלח על ידי הלקוח

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

אבחון

נכנסים לממשק המשתמש של Edge ומציגים את ההגדרה הספציפית של המארח הווירטואלי (ניהול > מארחים וירטואליים) שעבורם מתבצעת בקשת ה-API, או משתמשים בממשק ה-API לניהול GetVirtual Host API כדי לקבל את ההגדרה של המארח הווירטואלי הספציפי.

בדרך כלל מארח וירטואלי לתקשורת TLS דו-כיוונית נראה כך:

    <VirtualHost name="myTLSVHost">
        <HostAliases>
            <HostAlias>api.myCompany.com</HostAlias>
        </HostAliases>
        <Port>443</Port>
        <SSLInfo>
            <Enabled>true</Enabled>
            <ClientAuthEnabled>true</ClientAuthEnabled>
            <KeyStore>ref://myKeystoreRef</KeyStore>
            <KeyAlias>myKeyAlias</KeyAlias>
                <TrustStore>ref://myCompanyTruststoreRef</TrustStore>
        </SSLInfo>
    </VirtualHost>

קביעת ההפניה ל-Truststore המשמשת במארח הווירטואלי.
בדוגמה שלמעלה, שם ההפניה ב-Truststore הוא myCompanyTruststoreRef.
קביעת ה-Truststore שאליו מפנה ההפניה של Truststore.
1. בממשק המשתמש של Edge, צריך לעבור אל Admin > Environments References ולחפש את שם ההפניה ל-Truststore.
2. שימו לב לשם בעמודה הפניה של ההפניה הספציפית ל-Truststore. זה יהיה השם שלך ב-Truststore.
  
  איור 5
  
  בדוגמה שלמעלה, יש לשים לב שההפניה ל-myCompanyTruststoreRef מפנה אל myCompanyTruststore. לכן, השם של Truststore הוא myCompanyTruststore.
מקבלים את האישורים ב-Truststore (שנקבעו בשלב הקודם) באמצעות ממשקי ה-API הבאים:
1. הצגת רשימת האישורים ל-Keystore או ל-Truststore API
  
  ה-API הזה מפרט את כל האישורים ב-Truststore הספציפי.
2. קבלת פרטי אישור מ-Keystore API או מ-Truststore API.
  
  ה-API הזה מחזיר מידע על אישור ספציפי ב-Truststore הספציפי.
עליך לבדוק אם המנפיק והנושא של כל אישור ושל הרשת שלו ששמורים ב-myCompanyTruststore תואמים לאלה של האישור והשרשרת שלו, כפי שאפשר לראות בחבילות ה-TCP/IP (חבילה מס' 38) שלמעלה. אם יש אי התאמה, פירוש הדבר שהאישורים שהועלו ל-Truststore לא נטענים ב-Edge Router. עוברים אל הסיבה: אישורי הלקוח לא נטענים בנתב Edge.
אם לא נמצאה התאמה בשלב 5, סימן שאפליקציית הלקוח לא שלחה את האישור הנכון ואת השרשרת שלו.

רזולוציה

צריך לוודא שהאישור הנכון והשרשרת שלו נשלחים על ידי אפליקציית הלקוח ל-Edge.

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

השגיאה הזו מוצגת אם אישור הבסיס החתום בידי רשות האישורים של הלקוח חסר ב-Truststore של הנתב של Edge.

אבחון

נכנסים לממשק המשתמש של Edge ומציגים את ההגדרה הספציפית של המארח הווירטואלי שעבורו נשלחת בקשת ה-API (אדמין > מארחים וירטואליים > virtual_host) או להשתמש ב קבלת ממשק API למארח וירטואלי כדי לקבל את ההגדרה של המארח הווירטואלי הספציפי.

בדרך כלל מארח וירטואלי לתקשורת TLS דו-כיוונית נראה כך:
```
    <VirtualHost name="myTLSVHost">
        <HostAliases>
            <HostAlias>api.myCompany.com</HostAlias>
        </HostAliases>
        <Port>443</Port>
        <SSLInfo>
            <Enabled>true</Enabled>
            <ClientAuthEnabled>true</ClientAuthEnabled>
            <KeyStore>ref://myKeystoreRef</KeyStore>
            <KeyAlias>myKeyAlias</KeyAlias>
            <TrustStore>ref://myCompanyTruststoreRef</TrustStore>
        </SSLInfo>
    </VirtualHost>
```
קביעת ההפניה ל-Truststore שנעשה בה שימוש במארח הווירטואלי. בדוגמה הקודמת, שם ההפניה של ה-Truststore הוא myCompanyTruststoreRef.
קביעת ה-Truststore בפועל שמשמש את ההפניה של ה-Truststore.
בממשק המשתמש של Edge, עוברים אל ניהול > סביבות > הפניות ומחפשים את שם ההפניה של ה-Truststore.
שם ה-Truststore של ההפניה הספציפית ל-Truststore מופיע בעמודה Reference.

איור 6

בדוגמה הזו, שימו לב ש-myCompanyTruststoreRef כולל את myCompanyTruststore בעמודה Reference. לכן, השם של מאגר הנאמנות הוא myCompanyTruststore.
משיגים את האישורים שמאוחסנים ב-Truststore (כפי שנקבעו בשלב הקודם) באמצעות ממשקי ה-API הבאים:
1. הצגת רשימת האישורים ל-Keystore או ל-Truststore API ה-API הזה מציג רשימה של כל האישורים ב-Truststore.
2. קבלת פרטי האישור מ-Keystore או מ-Truststore API. ה-API הזה מחזיר מידע על אישור ספציפי ב-Truststore.
בדוק אם האישור כולל שרשרת מלאה, כולל אישור הבסיס שנשלח על ידי הלקוח הספציפי, כפי שמופיע בחבילות ה-TCP/IP (ראה איור 4). ה-Truststore חייב לכלול את אישור הבסיס וגם את אישור העלה, העלה הירוק ואישור הביניים של הלקוח. אם האישור החוקי של הלקוח חסר ב-Truststore, זו הסיבה לשגיאה.

עם זאת, אם שרשרת האישורים המלאה של הלקוח, כולל אישור הבסיס, קיימת ב-Truststore, המשמעות היא שהאישורים שהועלו ל-Truststore כנראה לא ייטענו ב-Edge Router. במקרה כזה, קראו את המאמר הסיבה: אישורי לקוח לא נטענים בנתב Edge.

רזולוציה

חשוב לוודא שהאישור של הלקוח הנכון, כולל אישור הבסיס, זמין ב-Truststore של נתב Apigee Edge.

הסיבה: אישורי הלקוח לא נטענים ב-Edge Router

אם אתם משתמשים ב-Public Cloud, תוכלו לפנות לתמיכה של Apigee Edge.
אם אתם משתמשים בענן פרטי, עליכם לפעול לפי ההוראות הבאות לגבי כל נתב:
1. בודקים אם הקובץ /opt/nginx/conf.d/OrgName_envName_vhostName-client.pem קיים עבור המארח הווירטואלי הספציפי. אם הקובץ לא קיים, כדאי לעבור לקטע פתרון שבהמשך.
2. אם הקובץ קיים, משתמשים בפקודה openssl שלמטה כדי לקבל את הפרטים של האישורים שזמינים ב-Edge Router:
```
openssl -in <OrgName_envName_vhostName-client.pem> -text -noout
```
3. יש לבדוק את מנפיק האישור, את הנושא שלו ואת תאריך התפוגה שלו. אם אחת מהאפשרויות האלה לא תואמת למה שתועד ב-Truststore בממשק המשתמש של Edge או באמצעות ממשקי ה-API לניהול, זו הסיבה לשגיאה.
4. ייתכן שהנתב לא טען מחדש את האישורים שהועלו.

רזולוציה

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

apigee-service edge-router restart

מפעילים מחדש את ממשקי ה-API ובודקים את התוצאות. אם הבעיה נמשכת, נכנסים אל איסוף מידע על אבחון.

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

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

אם אתם משתמשים ב-Public Cloud, עליכם לספק את הפרטים הבאים:
1. שם הארגון
2. שם הסביבה
3. שם שרת proxy ל-API
4. שם המארח הווירטואלי
5. שם כינוי המארח
6. השלמה של פקודת curl לשחזור השגיאה
7. מנות TCP/IP שנלכדו באפליקציית הלקוח
אם אתם משתמשים בענן פרטי, עליכם לספק את הפרטים הבאים:
1. שם מארח וירטואלי וההגדרה שלו באמצעות קבלת ממשק API למארח וירטואלי
2. שם כינוי המארח
3. זוהתה הודעת השגיאה המלאה
4. מנות TCP/IP שנקלטו באפליקציית הלקוח או בנתב.
5. פלט של ה-API List the credentials from the keystore API וגם הפרטים של כל אישור שהתקבל באמצעות Get cert details API.
פרטים על הקטעים ב-Playbook הזה שניסיתם ותובנות אחרות שיעזרו לנו לפתור את הבעיה במהירות.