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

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

ลักษณะปัญหา

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

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

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

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

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

การวินิจฉัย

  1. เข้าสู่ระบบ Edge UI และดูการกำหนดค่าโฮสต์เสมือน (ผู้ดูแลระบบ > โฮสต์เสมือน) ที่กำลังสร้างคำขอ 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 ของคุณ

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

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

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

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

    รูปที่ 2

    ใบรับรองที่มีชื่อแทน client-cert-markw ในตัวอย่างด้านบนแสดงให้เห็นว่าใบรับรองหมดอายุ

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

ความละเอียด

จัดหาใบรับรองใหม่และอัปโหลดใบรับรอง:

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

  3. แก้ไขการอ้างอิงของ Trustore ที่ใช้ในโฮสต์เสมือนที่ระบุให้ชี้ไปที่ 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 แสดงว่าเราเตอร์รับทราบข้อความ Hello ของไคลเอ็นต์จากแอปพลิเคชันไคลเอ็นต์
  3. เราเตอร์จะส่ง "Server Hello" ในแพ็กเก็ต #35 แล้วส่งใบรับรอง รวมทั้งขอให้แอปพลิเคชันไคลเอ็นต์ส่งใบรับรองในแพ็กเก็ต #38 ด้วย
  4. ในแพ็กเก็ต #38 ที่เราเตอร์ส่งแพ็กเก็ต "Certificate Request" ให้ดูที่ส่วน "ชื่อเฉพาะ" ซึ่งมีรายละเอียดเกี่ยวกับใบรับรองไคลเอ็นต์ เชน และผู้ออกใบรับรองที่เราเตอร์ (เซิร์ฟเวอร์) ยอมรับ
    5. รูปที่ 3

  5. แอปพลิเคชันไคลเอ็นต์จะส่งใบรับรองในแพ็กเก็ต # 41 ตรวจสอบส่วนการยืนยันใบรับรองในแพ็กเกต # 41 และดูว่าใบรับรองที่ส่งโดยแอปพลิเคชันไคลเอ็นต์ส่งมาให้

    รูปที่ 4
  6. ตรวจสอบว่าประเภทและผู้ออกใบรับรองและเชนของใบรับรองที่ส่งโดยแอปพลิเคชันไคลเอ็นต์ (แพ็กเก็ตที่ 41) ตรงกับใบรับรองที่ยอมรับและสายโซ่จากเราเตอร์ (แพ็กเก็ตที่ 38) หรือไม่ หากมีข้อมูลที่ไม่ตรงกัน แสดงว่านี่เป็นสาเหตุของข้อผิดพลาดนี้ ดังนั้น เราเตอร์ (เซิร์ฟเวอร์) จะส่งการแจ้งเตือนที่เข้ารหัส (แพ็กเก็ต #57) ตามด้วย FIN, ACK (แพ็กเก็ต 58) ไปยังแอปพลิเคชันไคลเอ็นต์ และในท้ายที่สุด การเชื่อมต่อจะสิ้นสุดลง
  7. ความไม่ตรงกันของใบรับรองกับเชนอาจเกิดจากสถานการณ์ที่อธิบายไว้ในส่วนต่อไปนี้

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

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

การวินิจฉัย

  1. ลงชื่อเข้าใช้ Edge UI และดูการกำหนดค่าโฮสต์เสมือน (ผู้ดูแลระบบ > โฮสต์เสมือน) ที่กำลังสร้างคำขอ API หรือใช้ 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 ของคุณ

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

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

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

    1. แสดงรายการใบรับรองสำหรับคีย์สโตร์หรือ API ของ Truststore

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

    2. รับรายละเอียดใบรับรองจากคีย์สโตร์หรือ API ของ Truststore

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

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

ความละเอียด

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

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

ข้อผิดพลาดนี้จะเกิดขึ้นหากใบรับรองรูทที่ลงชื่อโดย CA ของไคลเอ็นต์ขาดหายไปใน Truststore ของเราเตอร์ของ Edge

การวินิจฉัย

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

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

    รูปที่ 6

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

  6. รับใบรับรองที่จัดเก็บไว้ใน Truststore (ซึ่งกำหนดในขั้นตอนก่อนหน้า) โดยใช้ API ต่อไปนี้
    1. แสดงรายการใบรับรองสำหรับคีย์สโตร์หรือ API ของ Truststore API นี้จะแสดงใบรับรองทั้งหมดใน Truststore
    2. รับรายละเอียดใบรับรองจากคีย์สโตร์หรือ API ของ Truststore API นี้จะแสดงข้อมูลเกี่ยวกับใบรับรองที่เฉพาะเจาะจงใน Truststore

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

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

ความละเอียด

ตรวจสอบว่าใบรับรองของไคลเอ็นต์ที่ถูกต้อง รวมถึงใบรับรองรูทมีอยู่ใน Truststore ของเราเตอร์ Apigee Edge

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

  1. หากคุณเป็นผู้ใช้ 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. ตรวจสอบผู้ออกใบรับรอง เรื่อง และวันที่หมดอายุของใบรับรอง หากโค้ดใดข้อมูลหนึ่งไม่ตรงกับที่พบใน Truststore ใน Edge UI หรือโดยการใช้ 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. ชื่อโฮสต์เสมือนและคำจำกัดความโดยใช้รับ API โฮสต์เสมือน
    2. ชื่อแทนโฮสต์
    3. สังเกตข้อความแสดงข้อผิดพลาดให้เสร็จสมบูรณ์
    4. แพ็กเก็ต TCP/IP ที่บันทึกในแอปพลิเคชันไคลเอ็นต์หรือเราเตอร์
    5. เอาต์พุตของ แสดงรายการใบรับรองจาก keystore API API และรายละเอียดของใบรับรองแต่ละรายการที่ได้รับโดยใช้ Get cert details API
  3. รายละเอียดเกี่ยวกับส่วนต่างๆ ที่คุณได้ลองใช้ใน Playbook นี้และข้อมูลเชิงลึกอื่นๆ ที่จะช่วยเราติดตามการแก้ปัญหานี้ได้อย่างรวดเร็ว