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

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

ลักษณะปัญหา

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

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

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

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

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

การวินิจฉัย

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

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

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

    ในตัวอย่างที่อธิบายข้างต้น ให้ชี้การอ้างอิง myTruststoreRef ไปยัง myNewTruststore

ขั้นตอนการวินิจฉัยทั่วไปสำหรับสาเหตุอื่นๆ

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

  2. วิเคราะห์แพ็กเก็ต TCP/IP ที่รวบรวมโดยใช้ เครื่องมือ Wireshark หรือเครื่องมือที่คล้ายกันซึ่งคุณคุ้นเคยอยู่แล้ว

นี่คือการวิเคราะห์ตัวอย่างข้อมูลแพ็กเก็ต TCP/IP โดยใช้เครื่องมือ Wireshark:

  1. แพ็กเก็ต #30 ใน tcpdump (ภาพด้านล่าง) แสดงให้เห็นว่าแอปพลิเคชันไคลเอ็นต์ (แหล่งที่มา) ส่ง "Client Hello" ไปยังเราเตอร์ (ปลายทาง)
  2. แพ็กเก็ต #34 จะแสดงว่าเราเตอร์รับทราบข้อความ Hello ของไคลเอ็นต์จากแอปพลิเคชันไคลเอ็นต์
  3. เราเตอร์จะส่ง "Server Hello" ในแพ็คเก็ต #35 แล้วส่งใบรับรองของกล่อง และ จะขอให้แอปพลิเคชันไคลเอ็นต์ส่งใบรับรองในแพ็กเก็ต #38
  4. ในแพ็กเก็ต #38 ที่เราเตอร์ส่งแพ็กเก็ต "คำขอใบรับรอง" ให้ตรวจสอบ "ชื่อเฉพาะ" ส่วนที่มีรายละเอียดเกี่ยวกับใบรับรองไคลเอ็นต์ ชุดใบรับรอง และผู้ออกใบรับรองที่เราเตอร์ (เซิร์ฟเวอร์) ยอมรับ
    5. วันที่
    รูปที่ 3

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

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

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

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

การวินิจฉัย

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

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

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

      ในตัวอย่างด้านบน โปรดทราบว่า myCompanyTruststoreRef มีฟิลด์ อ้างอิงถึง myCompanyTruststore ดังนั้นชื่อ Truststore คือ myCompanyTruststore

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

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

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

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

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

  5. ตรวจสอบว่าผู้ออกบัตรและเรื่องของใบรับรองแต่ละใบและสายของใบรับรองที่เก็บไว้ใน myCompanyTruststore จับคู่กับใบรับรองและชุดใบรับรองตาม ที่พบในแพ็กเก็ต TCP/IP (ดูแพ็กเก็ต #38) ด้านบน หากมีข้อมูลที่ไม่ตรงกัน ระบบจะระบุว่า ไม่ได้โหลดใบรับรองที่อัปโหลดไปยัง Truststore ใน Edge Router ย้ายไปที่สาเหตุ: ใบรับรองไคลเอ็นต์ไม่โหลดใน Edge Router
  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. แสดงรายการใบรับรองสำหรับ Keystore หรือ Truststore API API นี้จะแสดงข้อมูลทั้งหมด ใน Truststore
    2. รับรายละเอียดใบรับรองจากคีย์สโตร์หรือ Truststore API API นี้ส่งคืนข้อมูลเกี่ยวกับ ใบรับรองที่เฉพาะเจาะจงใน Truststore

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

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

ความละเอียด

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

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

  1. หากคุณเป็นผู้ใช้ Public Cloud โปรดติดต่อทีมสนับสนุนของ Apigee Edge
  2. หากคุณเป็นผู้ใช้ Private Cloud ให้ทำตามวิธีการด้านล่างบนเราเตอร์แต่ละตัว
    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 UI หรือการใช้ API การจัดการ สาเหตุของข้อผิดพลาด
    4. เป็นไปได้ว่าเราเตอร์ไม่ได้โหลดใบรับรองที่อัปโหลดซ้ำ

ความละเอียด

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

apigee-service edge-router restart

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

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

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

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