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 Private Cloud וב-Edge Public Cloud
הלקוח שלח אישור שגוי השגיאה הזו מתרחשת אם האישור שנשלח על ידי אפליקציית הלקוח לא תואם לאישור שמאוחסן במאגר האישורים של נתב Edge. משתמשים ב-Edge Private Cloud וב-Edge Public Cloud
חסר אישור בסיס של לקוח במאגר האישורים השגיאה הזו מתקבלת אם אישור הבסיס שחתום על ידי CA של הלקוח חסר במאגר האישורים המהימנים של הנתב של Edge. משתמשים ב-Edge Private Cloud וב-Edge Public Cloud
אישורי לקוח לא נטענו בנתב Edge השגיאה הזו מתקבלת אם אישורי הלקוח שהועלו למאגר האישורים לא נטענו בנתב. משתמשים ב-Edge Private Cloud

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

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

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

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

אבחון

  1. מתחברים לממשק המשתמש של Edge ומציגים את ההגדרה הספציפית של המארח הווירטואלי (Admin > Virtual Hosts) שעבורו מתבצעת בקשת ה-API, או משתמשים ב-Get virtual host API management 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>

  2. קובעים את ההפניה למאגר האישורים שמשמש את המארח הווירטואלי. בדוגמה שלמעלה, שם ההפניה של Truststore הוא myTruststoreRef.

  3. קובעים את Truststore שאליו מפנה ההפניה ל-Truststore.
    1. בממשק המשתמש של Edge, עוברים אל Admin > Environments > References ומחפשים את שם ההפניה של Truststore.

    2. שימו לב לשם בעמודה Reference (הפניה) עבור ההפניה הספציפית למאגר האישורים. זה יהיה השם של מאגר האישורים.

      ממשק המשתמש של Edge שבו מוצגת רשימה של הפניות
      איור 1

      בדוגמה שלמעלה, שימו לב של-myTruststoreRef יש הפניה אל myTruststore. לכן, השם של מאגר האישורים הוא myTruststore.

  4. בממשק המשתמש של Edge, עוברים אל Admin > Environments > TLS Keystores, מחפשים את Truststore שאותר בשלב 3.

  5. בוחרים את האישור מתוך מאגר האישורים הספציפי (שנקבע בשלב 3 למעלה), כמו שמוצג כאן:

    איור 2

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

  6. בודקים אם פג התוקף של האישור של הכינוי של האישור בחנות האישורים.
  7. אם התוקף של האישור לא פג, עוברים אל שלבי אבחון נפוצים לסיבות אחרות.

רזולוציה

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

  1. יוצרים מאגר אישורים חדש, למשל myNewTruststore.
  2. מעלים את האישור החדש למאגר האישורים החדש שנוצר.

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

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

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

  1. כדי לבדוק את הבעיה הזו, צריך ללכוד חבילות TCP/IP באמצעות הכלי tcpdump.
    1. אם אתם משתמשים ב-Private Cloud, אתם יכולים ללכוד את מנות ה-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.

  2. מנתחים את חבילות ה-TCP/IP שנאספו באמצעות הכלי Wireshark או כלי דומה שאתם מכירים.

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

  1. מנת הנתונים מספר 30 ב-tcpdump (בתמונה שלמטה) מראה שאפליקציית הלקוח (המקור) שלחה הודעת Client Hello לנתב (היעד).
  2. חבילה מספר 34 מראה שהנתב מאשר את הודעת Client Hello מאפליקציית הלקוח.
  3. הנתב שולח את ההודעה Server Hello בחבילה מספר 35, ואז שולח את האישור שלו ומבקש מאפליקציית הלקוח לשלוח את האישור שלה בחבילה מספר 38.
  4. במנות #38, שבהן הנתב שולח מנות Certificate Request, בודקים את הקטע Distinguished Names שבו מפורטים פרטים על אישור הלקוח, השרשרת שלו ורשויות האישורים שהנתב (השרת) מקבל.
    5. איור 3

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

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

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

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

אבחון

  1. נכנסים לממשק המשתמש של Edge וצופים בהגדרה הספציפית של המארח הווירטואלי (Admin > Virtual Hosts) שעבורו מתבצעת בקשת ה-API, או משתמשים ב-Get virtual host API management 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>
  2. קובעים את ההפניה למאגר האישורים שמשמש את המארח הווירטואלי.

    בדוגמה שלמעלה, שם ההפניה למאגר האישורים הוא myCompanyTruststoreRef.

  3. קובעים את חנות האישורים שאליה מפנה ההפניה לחנות האישורים.
    1. בממשק המשתמש של Edge, עוברים אל Admin > Environments References ומחפשים את שם ההפניה של Truststore.

    2. שימו לב לשם בעמודה Reference (הפניה) עבור ההפניה הספציפית למאגר האישורים. זה יהיה השם של מאגר האישורים.

      ממשק משתמש של Edge שמוצג בו הפניה למאגר האישורים.
      איור 5

      בדוגמה שלמעלה, שימו לב ש-myCompanyTruststoreRef כולל את ההפניה אל myCompanyTruststore. לכן, השם של מאגר האישורים הוא myCompanyTruststore.

  4. מקבלים את האישורים שמאוחסנים ב-Truststore (שנקבע בשלב הקודם) באמצעות ממשקי ה-API הבאים:

    1. רשימת אישורים עבור API של חנות מפתחות או חנות אישורים

      ממשק ה-API הזה מציג רשימה של כל האישורים במאגר האישורים הספציפי.

    2. איך מקבלים פרטים על אישורים מ-API של חנות מפתחות או חנות אישורים מהימנים

      ממשק ה-API הזה מחזיר מידע על אישור ספציפי במאגר אישורים ספציפי.

  5. בודקים אם המנפיק והנושא של כל אישור ושרשרת האישורים שלו שמאוחסנים ב-myCompanyTruststore זהים לאלה של האישור ושרשרת האישורים שלו שמופיעים בחבילות TCP/IP (ראו חבילה מספר 38) שלמעלה. אם יש אי התאמה, זה מצביע על כך שהאישורים שהועלו למאגר הישויות האמינות לא נטענים בנתב Edge. עוברים אל הסיבה: אישורי לקוח לא נטענו בנתב Edge.
  6. אם לא נמצאה אי התאמה בשלב 5, זה מצביע על כך שאפליקציית הלקוח לא שלחה את האישור הנכון ואת השרשרת שלו.

רזולוציה

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

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

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

אבחון

  1. נכנסים לממשק המשתמש של Edge וצופים בהגדרות הספציפיות של המארח הווירטואלי שאליו מופנית בקשת ה-API (Admin > Virtual Hosts > virtual_host), או משתמשים ב- Get 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>
  2. קובעים את ההפניה למאגר האישורים שמשמש את המארח הווירטואלי. בדוגמה הקודמת, שם ההפניה למאגר האישורים הוא myCompanyTruststoreRef.
  3. קובעים את מאגר האישורים בפועל שמוגדר בהפניה למאגר האישורים.
  4. בממשק המשתמש של Edge, עוברים אל Admin > Environments > References ומחפשים את שם ההפניה של מאגר האישורים.

  5. שם מאגר האישורים של ההפניה הספציפית למאגר האישורים מופיע בעמודה Reference.

    איור 6

    בדוגמה הזו, שימו לב ש-myCompanyTruststoreRef כולל את myCompanyTruststore בעמודה Reference. לכן, שם חנות האישורים הוא myCompanyTruststore.

  6. מקבלים את האישורים שמאוחסנים במאגר האישורים (שנקבע בשלב הקודם) באמצעות ממשקי ה-API הבאים:
    1. רשימת אישורים עבור API של חנות מפתחות או חנות אישורים מהימנים. ממשק ה-API הזה מפרט את כל האישורים במאגר האישורים המהימנים.
    2. קבלת פרטי אישור מ-API של חנות מפתחות או חנות אישורים מהימנים ממשק ה-API הזה מחזיר מידע על אישור ספציפי במאגר האישורים.

  7. בודקים אם האישור כולל שרשרת מלאה, כולל אישור הבסיס שנשלח על ידי הלקוח הספציפי כפי שמופיע בחבילות TCP/IP (ראו איור 4). מאגר האישורים (truststore) צריך לכלול את אישור הבסיס, את אישור העלה של הלקוח או את אישור העלה ואת האישור הביניים. אם אישור הבסיס התקין של הלקוח חסר במאגר האישורים, זו הסיבה לשגיאה.

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

רזולוציה

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

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

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

רזולוציה

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

apigee-service edge-router restart

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

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

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

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