400 คำขอไม่ถูกต้อง - ข้อผิดพลาดใบรับรอง SSL

คุณกำลังดูเอกสารประกอบของ Apigee Edge
ไปที่ เอกสารประกอบของ Apigee X info

ลักษณะปัญหา

แอปพลิเคชันไคลเอ็นต์ได้รับการตอบสนองHTTP 400 - คำขอไม่ถูกต้องพร้อมข้อความ "ข้อผิดพลาดเกี่ยวกับใบรับรอง SSL" โดยปกติแล้ว เราเตอร์ Edge จะส่งข้อผิดพลาดนี้ ในการตั้งค่า TLS แบบ 2 ทางที่เปิดใช้สำหรับการเชื่อมต่อขาเข้าไปยัง 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 และ Public Cloud
ไคลเอ็นต์ส่งใบรับรองไม่ถูกต้อง ระบบจะแสดงข้อผิดพลาดนี้หากใบรับรองที่แอปพลิเคชันไคลเอ็นต์ส่งไม่ตรงกับใบรับรองที่จัดเก็บไว้ใน Truststore ของเราเตอร์ Edge ผู้ใช้ Edge Private และ Public Cloud
ไม่มีใบรับรองรูทของไคลเอ็นต์ใน Truststore ระบบจะแสดงข้อผิดพลาดนี้หากไม่มีใบรับรองรูทที่ CA ของไคลเอ็นต์ลงนามไว้ใน Truststore ของเราเตอร์ Edge ผู้ใช้ Edge Private และ Public Cloud
ไม่ได้โหลดใบรับรองไคลเอ็นต์ในเราเตอร์ Edge ระบบจะแสดงข้อผิดพลาดนี้หากไม่ได้โหลดใบรับรองไคลเอ็นต์ที่อัปโหลดไปยัง Truststore ในเราเตอร์ ผู้ใช้ Edge Private Cloud

สาเหตุ: ใบรับรองไคลเอ็นต์หมดอายุ

ปัญหานี้มักเกิดขึ้นกับ TLS แบบ 2 ทาง เมื่อใบรับรองที่ไคลเอ็นต์ส่งหมดอายุ ใน TLS แบบ 2 ทาง ทั้งไคลเอ็นต์และเซิร์ฟเวอร์จะแลกเปลี่ยน ใบรับรองสาธารณะเพื่อทำการ Handshake โดยไคลเอ็นต์จะตรวจสอบใบรับรองเซิร์ฟเวอร์ และเซิร์ฟเวอร์จะตรวจสอบใบรับรองไคลเอ็นต์

ใน Edge ระบบจะใช้ TLS แบบ 2 ทางที่ โฮสต์เสมือน โดยจะเพิ่มใบรับรองเซิร์ฟเวอร์ลงใน Keystore และเพิ่มใบรับรองไคลเอ็นต์ลงใน Truststore

ระหว่างการทำ TLS Handshake หากพบว่าใบรับรองไคลเอ็นต์หมดอายุแล้ว เซิร์ฟเวอร์ จะส่ง 400 - คำขอไม่ถูกต้อง พร้อมข้อความ "ข้อผิดพลาดเกี่ยวกับใบรับรอง SSL"

การวินิจฉัย

  1. เข้าสู่ระบบ UI ของ Edge และดูการกำหนดค่าโฮสต์เสมือนที่เฉพาะเจาะจง (ผู้ดูแลระบบ > โฮสต์เสมือน) ที่มีการส่งคำขอ API หรือใช้ Get virtual host API การจัดการ API เพื่อรับคำจำกัดความของโฮสต์เสมือนที่เฉพาะเจาะจง

    โดยปกติแล้ว โฮสต์เสมือนสำหรับการสื่อสาร TLS แบบ 2 ทางจะมีลักษณะดังนี้

    <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 ที่ใช้ในโฮสต์เสมือน ในตัวอย่างข้างต้น ชื่อการอ้างอิง Truststore คือ myTruststoreRef.

  3. กำหนด Truststore ที่การอ้างอิง Truststore ชี้ไป
    1. ใน UI ของ Edge ให้ไปที่ผู้ดูแลระบบ > สภาพแวดล้อม > การอ้างอิง แล้วค้นหาชื่อการอ้างอิง Truststore

    2. จดชื่อในคอลัมน์การอ้างอิง สำหรับการอ้างอิง Truststore ที่เฉพาะเจาะจง ซึ่งจะเป็นชื่อ Truststore

      UI ของ Edge แสดงรายการ การอ้างอิง
      รูปที่ 1

      ในตัวอย่างข้างต้น ให้สังเกตว่า myTruststoreRef มีการอ้างอิง ไปยัง myTruststore ดังนั้นชื่อ Truststore คือ myTruststore

  4. ใน ผู้ดูแลระบบ > สภาพแวดล้อม > TLS Keystore ใน UI ของ Edge ให้ไปที่ TLS Keystore แล้วมองหา Truststore ที่พบในขั้นตอนที่ 3

  5. เลือกใบรับรองใน Truststore ที่เฉพาะเจาะจง (กำหนดไว้ในขั้นตอนที่ 3 ด้านบน) ดังที่แสดงด้านล่าง

    รูปที่ 2

    ใบรับรองที่มีนามแฝง client-cert-markw ในตัวอย่างข้างต้นแสดงว่าหมดอายุแล้ว

  6. ตรวจสอบว่าใบรับรองหมดอายุสำหรับนามแฝงใบรับรองของ Truststore หรือไม่
  7. หากใบรับรองยังไม่หมดอายุ ให้ไปที่ ขั้นตอนการวินิจฉัยทั่วไปสำหรับสาเหตุอื่นๆ

ความละเอียด

จัดหาใบรับรองใหม่และอัปโหลดใบรับรองโดยทำดังนี้

  1. สร้าง Truststore ใหม่ เช่น myNewTruststore.
  2. อัปโหลดใบรับรองใหม่ไปยัง Truststore ที่สร้างขึ้นใหม่

  3. แก้ไขการอ้างอิง Truststore ที่ใช้ในโฮสต์เสมือนที่เฉพาะเจาะจงให้ชี้ไปยัง Truststore ใหม่โดยใช้ขั้นตอนที่ระบุไว้ใน หัวข้อการแก้ไขการอ้างอิง

    ในตัวอย่างที่อธิบายไว้ข้างต้น ให้ชี้การอ้างอิง 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. ตรวจสอบว่า Subject และ Issuer ของใบรับรองและกลุ่มใบรับรองที่แอปพลิเคชันไคลเอ็นต์ส่ง (แพ็กเก็ต #41) ตรงกับใบรับรองและกลุ่มใบรับรองที่ยอมรับจากเราเตอร์ (แพ็กเก็ต #38) หรือไม่ หากไม่ตรงกัน แสดงว่านั่นคือสาเหตุของข้อผิดพลาดนี้ ดังนั้น เราเตอร์ (เซิร์ฟเวอร์) จะส่งการแจ้งเตือนที่เข้ารหัส (แพ็กเก็ต #57) ตามด้วย FIN, ACK (แพ็กเก็ต #58) ไปยัง แอปพลิเคชันไคลเอ็นต์ และในที่สุดการเชื่อมต่อก็จะสิ้นสุดลง
  7. การไม่ตรงกันของใบรับรองและกลุ่มใบรับรองอาจเกิดจากสถานการณ์ที่อธิบายไว้ใน ส่วนต่อไปนี้

สาเหตุ: ไคลเอ็นต์ส่งใบรับรองไม่ถูกต้อง

กรณีนี้มักเกิดขึ้นหาก Subject/Issuer ของใบรับรองและ/หรือกลุ่มใบรับรองที่แอปพลิเคชันไคลเอ็นต์ส่งไม่ตรงกับใบรับรองและ/หรือกลุ่มใบรับรองที่จัดเก็บไว้ใน Truststore ของเราเตอร์ (เซิร์ฟเวอร์)

การวินิจฉัย

  1. ลงชื่อเข้าใช้ UI ของ Edge และดูการกำหนดค่าโฮสต์เสมือนที่เฉพาะเจาะจง (ผู้ดูแลระบบ > โฮสต์เสมือน) ที่มีการส่งคำขอ API หรือใช้ Get virtual host API การจัดการ API เพื่อรับคำจำกัดความของโฮสต์เสมือนที่เฉพาะเจาะจง

    โดยปกติแล้ว โฮสต์เสมือนสำหรับการสื่อสาร TLS แบบ 2 ทางจะมีลักษณะดังนี้

        <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. กำหนดการอ้างอิง Truststore ที่ใช้ในโฮสต์เสมือน

    ในตัวอย่างข้างต้น ชื่อการอ้างอิง Truststore คือ myCompanyTruststoreRef

  3. กำหนด Truststore ที่การอ้างอิง Truststore ชี้ไป
    1. ใน UI ของ Edge ให้ไปที่ผู้ดูแลระบบ > การอ้างอิงสภาพแวดล้อม แล้วค้นหาชื่อการอ้างอิง Truststore

    2. จดชื่อในคอลัมน์การอ้างอิง สำหรับการอ้างอิง Truststore ที่เฉพาะเจาะจง ซึ่งจะเป็นชื่อ Truststore

      UI ของ Edge แสดง การอ้างอิง Truststore
      รูปที่ 5

      ในตัวอย่างข้างต้น ให้สังเกตว่า myCompanyTruststoreRef มีการ อ้างอิงไปยัง myCompanyTruststore ดังนั้นชื่อ Truststore คือ myCompanyTruststore

  4. รับใบรับรองที่จัดเก็บไว้ใน Truststore (กำหนดไว้ในขั้นตอนก่อนหน้า) โดยใช้ API ต่อไปนี้

    1. List certificates for a keystore or truststore API.

      API นี้จะแสดงใบรับรองทั้งหมดใน Truststore ที่เฉพาะเจาะจง

    2. Get cert details from a keystore or truststore API.

      API นี้จะแสดงข้อมูลเกี่ยวกับใบรับรองที่เฉพาะเจาะจงใน Truststore ที่เฉพาะเจาะจง

  5. ตรวจสอบว่า Issuer และ Subject ของใบรับรองแต่ละรายการและกลุ่มใบรับรองที่จัดเก็บไว้ใน myCompanyTruststore ตรงกับใบรับรองและกลุ่มใบรับรองที่เห็นในแพ็กเก็ต TCP/IP (ดูแพ็กเก็ต #38) ด้านบนหรือไม่ หากไม่ตรงกัน แสดงว่าไม่ได้โหลดใบรับรองที่อัปโหลดไปยัง Truststore ในเราเตอร์ Edge ให้ไปที่ สาเหตุ: ไม่ได้โหลดใบรับรองไคลเอ็นต์ในเราเตอร์ Edge
  6. หากไม่พบการไม่ตรงกันในขั้นตอนที่ 5 แสดงว่าแอปพลิเคชันไคลเอ็นต์ไม่ได้ส่งใบรับรองและกลุ่มใบรับรองที่ถูกต้อง

ความละเอียด

ตรวจสอบว่าแอปพลิเคชันไคลเอ็นต์ส่งใบรับรองและกลุ่มใบรับรองที่ถูกต้องไปยัง Edge

สาเหตุ: ไม่มีใบรับรองรูทของไคลเอ็นต์ใน Truststore

ระบบจะแสดงข้อผิดพลาดนี้หากไม่มีใบรับรองรูทที่ CA ของไคลเอ็นต์ลงนามไว้ใน Truststore ของเราเตอร์ Edge

การวินิจฉัย

  1. ลงชื่อเข้าใช้ UI ของ Edge และดูการกำหนดค่าโฮสต์เสมือนที่เฉพาะเจาะจงที่ส่งคำขอ API (ผู้ดูแลระบบ > โฮสต์เสมือน > virtual_host), หรือใช้ Get virtual host API เพื่อรับคำจำกัดความของโฮสต์เสมือนที่เฉพาะเจาะจง

    โดยปกติแล้ว โฮสต์เสมือนสำหรับการสื่อสาร TLS แบบ 2 ทางจะมีลักษณะดังนี้

        <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. กำหนดการอ้างอิง Truststore ที่ใช้ในโฮสต์เสมือน ในตัวอย่างก่อนหน้า ชื่อการอ้างอิง Truststore คือ myCompanyTruststoreRef
  3. กำหนด Truststore จริงที่การอ้างอิง Truststore ใช้
  4. ใน UI ของ Edge ให้ไปที่ผู้ดูแลระบบ > สภาพแวดล้อม > การอ้างอิง แล้วค้นหา ชื่อการอ้างอิง Truststore

  5. ชื่อ Truststore สำหรับการอ้างอิง Truststore ที่เฉพาะเจาะจงจะอยู่ในคอลัมน์ การอ้างอิง

    รูปที่ 6

    ในตัวอย่างนี้ ให้สังเกตว่า myCompanyTruststoreRef มี myCompanyTruststore ในคอลัมน์การอ้างอิง ดังนั้นชื่อ Truststore คือ myCompanyTruststore

  6. รับใบรับรองที่จัดเก็บไว้ใน Truststore (กำหนดไว้ในขั้นตอนก่อนหน้า) โดยใช้ API ต่อไปนี้:
    1. List certificates for a keystore or truststore API API นี้จะแสดงใบรับรองทั้งหมดใน Truststore
    2. Get cert details from a keystore or truststore API. API นี้จะแสดงข้อมูลเกี่ยวกับ ใบรับรองที่เฉพาะเจาะจงใน Truststore

  7. ตรวจสอบว่าใบรับรองมีกลุ่มใบรับรองที่สมบูรณ์ รวมถึงใบรับรองรูท ที่ไคลเอ็นต์ที่เฉพาะเจาะจงส่ง ดังที่เห็นในแพ็กเก็ต TCP/IP (ดูรูปที่ 4) Truststore ต้องมีใบรับรองรูท รวมถึงใบรับรอง Leaf ของไคลเอ็นต์ หรือใบรับรอง Leaf และ ใบรับรองกลาง หากไม่มีใบรับรองรูทที่ถูกต้องของไคลเอ็นต์ใน Truststore แสดงว่านั่นคือสาเหตุของข้อผิดพลาด

    อย่างไรก็ตาม หากกลุ่มใบรับรองที่สมบูรณ์ของไคลเอ็นต์ รวมถึงใบรับรองรูท อยู่ใน Truststore แสดงว่าอาจไม่ได้โหลดใบรับรองที่อัปโหลดไปยัง Truststore ในเราเตอร์ Edge ในกรณีนี้ ให้ดู สาเหตุ: ไม่ได้โหลดใบรับรองไคลเอ็นต์ในเราเตอร์ Edge.

ความละเอียด

ตรวจสอบว่าใบรับรองของไคลเอ็นต์ที่ถูกต้อง รวมถึงใบรับรองรูทอยู่ใน Truststore ของเราเตอร์ 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. ตรวจสอบผู้ออกใบรับรอง Subject และวันที่หมดอายุของใบรับรอง หากข้อมูลใดข้อมูลหนึ่งไม่ตรงกับข้อมูลที่เห็นใน Truststore ใน UI ของ Edge หรือใช้ Management API แสดงว่านั่นคือสาเหตุของข้อผิดพลาด
    4. เราเตอร์อาจไม่ได้โหลดใบรับรองที่อัปโหลดซ้ำ

ความละเอียด

รีสตาร์ทเราเตอร์เพื่อให้แน่ใจว่าได้โหลดใบรับรองล่าสุดแล้วโดยทำตามขั้นตอนด้านล่าง

apigee-service edge-router restart

เรียกใช้ API อีกครั้งและตรวจสอบผลลัพธ์ หากยังพบปัญหาอยู่ ให้ไปที่ รวบรวมข้อมูลการวินิจฉัย.

รวบรวมข้อมูลการวินิจฉัย

หากยังพบปัญหาอยู่แม้จะทำตามวิธีการข้างต้นแล้ว โปรดรวบรวมข้อมูลการวินิจฉัยต่อไปนี้ ติดต่อและแชร์ข้อมูลที่รวบรวมกับ ทีมสนับสนุนของ Apigee Edge โดยทำดังนี้

  1. หากคุณเป็นผู้ใช้ Public Cloud โปรดระบุข้อมูลต่อไปนี้
    1. ชื่อองค์กร
    2. ชื่อสภาพแวดล้อม
    3. ชื่อพร็อกซี 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. รายละเอียดเกี่ยวกับส่วนต่างๆ ในเพลย์บุ๊กนี้ที่คุณได้ลองทำแล้ว รวมถึงข้อมูลเชิงลึกอื่นๆ ที่จะ ช่วยให้เราแก้ปัญหานี้ได้อย่างรวดเร็ว