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

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

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

תיאור הבעיה

אפליקציית הלקוח מקבלת תגובה מסוג HTTP 400 – בקשה לא תקינה עם הודעה "השגיאה של אישור ה-SSL". בדרך כלל הודעת השגיאה הזאת נשלחת על ידי נתב Edge בהגדרת 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 בענן פרטי וציבורי
חסר אישור בסיס של לקוח ב-Truststore	השגיאה הזו תופיע אם אישור הבסיס החתום של ה-CA של הלקוח חסר ב-Truststore של הנתב של Edge.	משתמשי Edge בענן פרטי וציבורי
אישורי לקוח לא נטענים בנתב Edge	השגיאה הזו תופיע אם אישורי הלקוח שהועלו ל-Truststore לא נטענים בנתב.	משתמשי Edge בענן פרטי

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

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

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

במהלך לחיצת היד בפרוטוקול TLS אם מתגלה שאישור הלקוח פג, השרת ההודעה 400 – בקשה שגויה תוצג עם ההודעה "The SSL certificate error.

אבחון

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

בדרך כלל מארח וירטואלי לתקשורת TLS דו-כיוונית (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. שימו לב לשם שמופיע בעמודה Reference (הפניה) של קובץ העזר הספציפי של Truststore. זה יהיה השם שלך ב-Truststore.
  
  איור 1
  
  בדוגמה שלמעלה, שימו לב ש-myTruststoreRef כולל את אל myTruststore. לכן, השם של Truststore הוא myTruststore.
בקטע ניהול > סביבות > TLS Keystores בממשק המשתמש של Edge, עוברים אל TLS מאגרי מפתחות ומחפשים את ה-Truststore בשלב 3.
בוחרים את האישור ב-Truststore הספציפי (שמופיע בשלב 3 למעלה) כמו שמוצג כאן:

איור 2

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

רזולוציה

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

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

בדוגמה שלמעלה, מצביעים על ההפניה myTruststoreRef to myNewTruststore.

שלבים נפוצים לאבחון בעיות אחרות

כדי לחקור את הבעיה, צריך לתעד מנות TCP/IP באמצעות tcpdump.
1. אם אתם משתמשים בענן פרטי, תוכלו לתעד את חבילות ה-TCP/IP אפליקציית לקוח או נתב.
2. אם משתמשים בענן ציבורי, צריך לתעד את חבילות ה-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 (תמונה למטה) מראה שאפליקציית הלקוח (מקור) שלח/ה "Client Hello" הודעה לנתב (יעד).
חבילה מס' 34 מראה שהנתב מאשר את הודעת Client Hello מאפליקציית הלקוח.
הנתב שולח את הפקודה "Server Hello" בחבילה מס' 35, ואז שולחת את האישור שלה וגם מבקשת מאפליקציית הלקוח לשלוח את האישור שלה בחבילה מס' 38.
בחבילה מס' 38, שבה הנתב שולח את חבילת 'Certificate Request', בודקים את "שמות ייחודיים" שמספק פרטים על אישור הלקוח, השרשרת שלו ורשויות האישורים שמקובלות על הנתב (השרת).

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

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

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

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

אבחון

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

בדרך כלל מארח וירטואלי לתקשורת TLS דו-כיוונית (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, עוברים לקטע אדמין > מקורות מידע לגבי סביבה ומחפשים את שם הסימוכין של Truststore.
2. שימו לב לשם שמופיע בעמודה Reference (הפניה) של קובץ העזר הספציפי של Truststore. זה יהיה השם שלך ב-Truststore.
  
  איור 5
  
  בדוגמה שלמעלה, שימו לב שבכתובת myCompanyTruststoreRef יש את הפניה אל myCompanyTruststore. לכן, השם ב-Truststore הוא myCompanyTruststore.
משיגים את האישורים שמאוחסנים ב-Truststore (שמופיעים בשלב הקודם) באמצעות ממשקי ה-API הבאים:
1. הצגת רשימה של אישורים ל-Keystore או ל-Truststore API.
  
  ב-API הזה מפורטים כל האישורים ב-Truststore הספציפי.
2. קבלת פרטי אישור מ-API של מאגר מפתחות או Truststore.
  
  ה-API הזה מחזיר מידע על אישור ספציפי ב-Truststore הספציפי.
צריך לבדוק אם המנפיק והנושא של כל האישור והשרשרת שלו מאוחסנים myCompanyTruststore תואם לזה של האישור והרשת שלו, בתור שניתן לראות בחבילות ה-TCP/IP (פרטים בחבילה מס' 38) שלמעלה. אם יש אי התאמה, סימן שהאישורים שהועלו ל-Truststore לא נטענים ב-Edge Router. עוברים אל הסיבה: אישורי לקוח לא נטענו בנתב Edge.
אם לא נמצאה התאמה בשלב 5, פירוש הדבר הוא שאפליקציית הלקוח לא לשלוח את האישור הנכון ואת השרשרת שלו.

רזולוציה

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

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

השגיאה הזו תופיע אם אישור הבסיס החתום של ה-CA של הלקוח חסר ב-Truststore של הנתב של Edge.

אבחון

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

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

איור 6

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

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

רזולוציה

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

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

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

רזולוציה

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

apigee-service edge-router restart

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

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

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

אם אתם משתמשים בענן ציבורי, עליכם לספק את הפרטים הבאים:
1. שם הארגון
2. שם הסביבה
3. שם ה-API של ה-Proxy
4. שם המארח הווירטואלי
5. שם הכינוי של המארח
6. צריך להשלים את פקודת ה-curl כדי לשחזר את השגיאה
7. מנות TCP/IP שתועדו באפליקציית הלקוח
אם אתם משתמשים בענן פרטי, עליכם לספק את הפרטים הבאים:
1. שם המארח הווירטואלי וההגדרות שלו באמצעות קבלת API של מארח וירטואלי
2. שם הכינוי של המארח
3. זוהה הודעת שגיאה מלאה
4. מנות TCP/IP שתועדו באפליקציית הלקוח או בנתב.
5. הפלט של הצגת רשימת האישורים מ-Keystore API API וגם הפרטים של כל אישור שהושג באמצעות Get cert details API.
פרטים על הקטעים במדריך הזה שניסית ועל תובנות אחרות כדי שנוכל לפתור את הבעיה במהירות.