หน้านี้ได้รับการแปลโดย Cloud Translation API

แฮนด์เชค SSL ไม่สำเร็จ - ใบรับรองไคลเอ็นต์ไม่ถูกต้อง

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

ลักษณะปัญหา

แอปพลิเคชันไคลเอ็นต์จะได้รับรหัสสถานะ HTTP 503 พร้อมด้วยข้อความ "บริการไม่พร้อมใช้งาน" เป็นการตอบกลับคำขอ API ในการติดตาม UI คุณจะสังเกตเห็นว่า error.cause เป็น Received fatal alert: bad_certificate ในโฟลว์คำขอเป้าหมายสำหรับคำขอ API ที่ล้มเหลว

หากมีสิทธิ์เข้าถึงบันทึกตัวประมวลผลข้อความ คุณจะเห็นข้อความแสดงข้อผิดพลาดเป็น Received fatal alert: bad_certificate สำหรับคำขอ API ที่ล้มเหลว ข้อผิดพลาดนี้เกิดขึ้นได้ในกระบวนการแฮนด์เชค SSL ระหว่างผู้ประมวลผลข้อมูลข้อความกับเซิร์ฟเวอร์แบ็กเอนด์ในการตั้งค่า TLS แบบ 2 ทาง

ข้อความแสดงข้อผิดพลาด

แอปพลิเคชันไคลเอ็นต์จะได้รับโค้ดตอบกลับต่อไปนี้

HTTP/1.1 503 Service Unavailable

นอกจากนี้ คุณอาจพบข้อความแสดงข้อผิดพลาดต่อไปนี้

{
 "fault": {
    "faultstring":"The Service is temporarily unavailable",
    "detail":{
        "errorcode":"messaging.adaptors.http.flow.ServiceUnavailable"
    }
 }
}

ผู้ใช้ Private Cloud จะเห็นข้อผิดพลาดต่อไปนี้สำหรับคำขอ API เฉพาะในบันทึกผู้ประมวลผลข้อความ /opt/apigee/var/log/edge-message-processor/system.log

2017-10-23 05:28:57,813 org:org-name env:env-name api:apiproxy-name rev:revision-number messageid:message_id NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context.handshakeFailed() : SSLClientChannel[C:IP address:port # Remote host:IP address:port #]@65461 useCount=1 bytesRead=0 bytesWritten=0 age=529ms lastIO=529ms handshake failed, message: Received fatal alert: bad_certificate

สาเหตุที่เป็นไปได้

สาเหตุที่เป็นไปได้ของปัญหานี้มีดังนี้

สาเหตุ	คำอธิบาย	วิธีการแก้ปัญหาสำหรับ
ไม่มีใบรับรองไคลเอ็นต์	คีย์สโตร์ที่ใช้ในปลายทางเป้าหมายของเซิร์ฟเวอร์เป้าหมายไม่มีใบรับรองไคลเอ็นต์	ผู้ใช้ Edge ส่วนตัวและผู้ใช้ระบบคลาวด์สาธารณะ
ผู้ออกใบรับรองไม่ตรงกัน	ผู้ออกใบรับรองของใบรับรอง Leaf (ใบรับรองแรกในสายใบรับรอง) ในคีย์สโตร์ของผู้ประมวลผลข้อความไม่ตรงกับผู้ออกใบรับรองที่เซิร์ฟเวอร์แบ็กเอนด์ยอมรับ	ผู้ใช้ Edge ส่วนตัวและผู้ใช้ระบบคลาวด์สาธารณะ

ขั้นตอนการวิเคราะห์ทั่วไป

เปิดใช้การติดตามใน Edge UI, เรียก API และทำให้เกิดปัญหาซ้ำ
ในผลลัพธ์การติดตาม UI ให้ไปยังแต่ละเฟสและตรวจสอบว่าข้อผิดพลาดเกิดขึ้นที่ใด ข้อผิดพลาดจะเกิดขึ้นในขั้นตอนคำขอเป้าหมาย
ตรวจสอบโฟลว์ที่แสดงข้อผิดพลาด โดยจะเห็นข้อผิดพลาดตามที่แสดงในตัวอย่างการติดตามด้านล่าง
อย่างที่เห็นในภาพหน้าจอด้านบน error.cause คือ "ได้รับการแจ้งเตือนร้ายแรง: bad_certificate"

หากคุณเป็นผู้ใช้ Private Cloud ให้ทำตามวิธีการด้านล่าง

คุณดูรหัสข้อความสำหรับคำขอ API ที่ล้มเหลวได้โดยกำหนดค่าของส่วนหัวข้อผิดพลาด "X-Apigee.Message-ID" ในระยะที่ระบุด้วย AX ในการติดตาม

ค้นหารหัสข้อความนี้ในบันทึกของตัวประมวลผลข้อความ /opt/apigee/var/log/edge-message-processor/system.log และดูว่าจะหาข้อมูลเพิ่มเติมเกี่ยวกับข้อผิดพลาดดังกล่าวได้หรือไม่

2017-10-23 05:28:57,813 org:org-name env:env-name api:apiproxy-name
rev:revision-number messageid:message_id NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context.handshakeFailed() :
SSLClientChannel[C:IP address:port # Remote host:IP address:port #]@65461 useCount=1
bytesRead=0 bytesWritten=0 age=529ms lastIO=529ms handshake failed, message: Received fatal alert: bad_certificate
2017-10-23 05:28:57,813 org:org-name env:env-name api:apiproxy-name
rev:revision-number messageid:message_id NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context.handshakeFailed() : SSLInfo:
KeyStore:java.security.KeyStore@52de60d9 KeyAlias:KeyAlias TrustStore:java.security.KeyStore@6ec45759
2017-10-23 05:28:57,814 org:org-name env:env-name api:apiproxy-name
rev:revision-number messageid:message_id NIOThread@0 ERROR ADAPTORS.HTTP.FLOW - RequestWriteListener.onException() :
RequestWriteListener.onException(HTTPRequest@6071a73d)
javax.net.ssl.SSLException: Received fatal alert: bad_certificate
at sun.security.ssl.Alerts.getSSLException(Alerts.java:208) ~[na:1.8.0_101]
at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1666) ~[na:1.8.0_101]
at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1634) ~[na:1.8.0_101]
at sun.security.ssl.SSLEngineImpl.recvAlert(SSLEngineImpl.java:1800) ~[na:1.8.0_101]
at com.apigee.nio.NIOSelector$SelectedIterator.findNext(NIOSelector.java:496) [nio-1.0.0.jar:na]
at com.apigee.nio.util.NonNullIterator.computeNext(NonNullIterator.java:21) [nio-1.0.0.jar:na]
at com.apigee.nio.util.AbstractIterator.hasNext(AbstractIterator.java:47) [nio-1.0.0.jar:na]
at com.apigee.nio.NIOSelector$2.findNext(NIOSelector.java:312) [nio-1.0.0.jar:na]
at com.apigee.nio.NIOSelector$2.findNext(NIOSelector.java:302) [nio-1.0.0.jar:na]
at com.apigee.nio.util.NonNullIterator.computeNext(NonNullIterator.java:21) [nio-1.0.0.jar:na]
at com.apigee.nio.util.AbstractIterator.hasNext(AbstractIterator.java:47) [nio-1.0.0.jar:na]
at com.apigee.nio.handlers.NIOThread.run(NIOThread.java:59) [nio-1.0.0.jar:na]

บันทึกตัวประมวลผลข้อความมีสแต็กเทรซสำหรับข้อผิดพลาด Received fatal alert: bad_certificate แต่ไม่มีข้อมูลเพิ่มเติมที่ระบุสาเหตุของปัญหานี้

หากต้องการตรวจสอบปัญหานี้เพิ่มเติม คุณจะต้องบันทึกแพ็กเก็ต TCP/IP โดยใช้เครื่องมือ tcpdump
1. หากคุณเป็นผู้ใช้ Private Cloud คุณจะบันทึกแพ็กเก็ต TCP/IP ในเซิร์ฟเวอร์แบ็กเอนด์หรือตัวประมวลผลข้อความได้ ขอแนะนำให้บันทึกเซิร์ฟเวอร์แบ็กเอนด์ในขณะที่ถอดรหัสแพ็กเก็ตในเซิร์ฟเวอร์แบ็กเอนด์
2. หากคุณเป็นผู้ใช้ระบบคลาวด์สาธารณะ ให้บันทึกแพ็กเก็ต TCP/IP ในเซิร์ฟเวอร์แบ็กเอนด์
3. เมื่อตัดสินใจเลือกตำแหน่งที่ต้องการรับแพ็กเก็ต TCP/IP ได้แล้ว ให้ใช้คำสั่ง tcpdump ด้านล่างเพื่อบันทึกแพ็กเก็ต TCP/IP
วิเคราะห์แพ็กเก็ต TCP/IP โดยใช้เครื่องมือ Wireshark หรือเครื่องมือที่คล้ายกันที่คุณคุ้นเคย

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

alt_text

ข้อความ #4 ใน tcpdump ข้างต้นแสดงให้เห็นว่าผู้ประมวลผลข้อความ (ต้นทาง) ส่งข้อความ "Client Hello" ไปยังเซิร์ฟเวอร์แบ็กเอนด์ (ปลายทาง)
ข้อความ #5 แสดงว่าเซิร์ฟเวอร์แบ็กเอนด์รับทราบข้อความ Hello ของไคลเอ็นต์จากตัวประมวลผลข้อความแล้ว
เซิร์ฟเวอร์แบ็กเอนด์จะส่งข้อความ "Server Hello" พร้อมกับใบรับรอง จากนั้นขอให้ไคลเอ็นต์ส่งใบรับรองในข้อความ #7
ตัวประมวลผลข้อความดำเนินการยืนยันใบรับรองจนเสร็จสมบูรณ์และรับทราบข้อความ Server Hello ของเซิร์ฟเวอร์แบ็กเอนด์ใน Message #8
ผู้ประมวลผลข้อความจะส่งใบรับรองของตนไปยังเซิร์ฟเวอร์แบ็กเอนด์ในข้อความ #9
เซิร์ฟเวอร์แบ็กเอนด์รับทราบการได้รับใบรับรองของผู้ประมวลผลข้อความในข้อความ #11
แต่จะส่งการแจ้งเตือนร้ายแรง: ใบรับรองไม่ถูกต้องไปยัง ผู้ประมวลผลข้อความ (ข้อความ #12) ทันที ซึ่งแสดงว่าใบรับรองที่ส่งโดย ผู้ประมวลผลข้อความมีปัญหา ทำให้การยืนยันใบรับรองล้มเหลว ในเซิร์ฟเวอร์แบ็กเอนด์ ด้วยเหตุนี้ แฮนด์เชค SSL จึงล้มเหลวและ การเชื่อมต่อจะถูกปิด
ต่อไปให้ดูที่ข้อความ #9 เพื่อตรวจสอบเนื้อหาของใบรับรองที่ส่งโดยผู้ประมวลผลข้อความ:
คุณจะเห็นว่าเซิร์ฟเวอร์แบ็กเอนด์ไม่ได้รับใบรับรองจากไคลเอ็นต์ (ความยาวใบรับรอง: 0) ดังนั้น เซิร์ฟเวอร์แบ็กเอนด์จะส่งการแจ้งเตือนร้ายแรง: ใบรับรองไม่ถูกต้อง
โดยปกติแล้วจะเกิดขึ้นเมื่อไคลเอ็นต์ ซึ่งก็คือ Message Processor (กระบวนการที่ใช้ Java) มีลักษณะดังต่อไปนี้
1. ไม่มีใบรับรองไคลเอ็นต์ในคีย์สโตร์ หรือ
2. ไม่สามารถส่งใบรับรองไคลเอ็นต์ กรณีนี้อาจเกิดขึ้นหากไม่พบใบรับรองที่ออกโดยผู้ออกใบรับรองที่ยอมรับได้ของเซิร์ฟเวอร์แบ็กเอนด์ หมายความว่า หากผู้ออกใบรับรองของใบรับรอง Leaf ของไคลเอ็นต์ (นั่นคือ ใบรับรองแรกในสาย) ไม่ตรงกับผู้ออกใบรับรองที่เซิร์ฟเวอร์แบ็กเอนด์ยอมรับ ผู้ประมวลผลข้อความจะไม่ส่งใบรับรอง

ลองดูสาเหตุแต่ละข้อแยกกัน ดังนี้

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

การวินิจฉัย

หากไม่มีใบรับรองในคีย์สโตร์ที่ระบุในส่วนข้อมูล SSL ของปลายทางเป้าหมายหรือเซิร์ฟเวอร์เป้าหมายที่ใช้ในปลายทางเป้าหมาย สาเหตุของข้อผิดพลาดนี้

ทำตามขั้นตอนด้านล่างเพื่อดูว่าเป็นสาเหตุหรือไม่

กำหนดคีย์สโตร์ที่ใช้ในปลายทางเป้าหมายหรือเซิร์ฟเวอร์เป้าหมายสำหรับพร็อกซี API ที่เจาะจงโดยทำตามขั้นตอนด้านล่าง
1. รับชื่ออ้างอิงคีย์สโตร์จากองค์ประกอบ Keystore ในส่วน SSLInfo ในปลายทางเป้าหมายหรือเซิร์ฟเวอร์เป้าหมาย
  ลองดูตัวอย่างส่วน SSLInfo ในการกำหนดค่าปลายทางเป้าหมาย:
```
<SSLInfo>
  <Enabled>true</Enabled>
  <ClientAuthEnabled>true</ClientAuthEnabled>
  <KeyStore>ref://myKeystoreRef</KeyStore>
  <KeyAlias>myKey</KeyAlias>
  <TrustStore>ref://myTrustStoreRef</TrustStore>
</SSLInfo>
```
2. ในตัวอย่างข้างต้น ชื่ออ้างอิงคีย์สโตร์คือ "myKeystoreRef"
3. ไปที่ Edge UI แล้วเลือกพร็อกซี API -> การกำหนดค่าสภาพแวดล้อม
  เลือกแท็บข้อมูลอ้างอิงและค้นหาชื่อข้อมูลอ้างอิงคีย์สโตร์ จดชื่อในคอลัมน์ข้อมูลอ้างอิงสำหรับข้อมูลอ้างอิงคีย์สโตร์ที่เฉพาะเจาะจง นี่จะเป็นชื่อคีย์สโตร์ของคุณ
4. ในตัวอย่างข้างต้น คุณจะสังเกตเห็นว่า myKeystoreRef มีการอ้างอิงไปยัง "myKeystore" ดังนั้นชื่อคีย์สโตร์จะเป็น myKeystore
ตรวจสอบว่าคีย์สโตร์นี้มีใบรับรองโดยใช้ Edge UI หรือแสดงรายการใบรับรองสำหรับ Keystore API หรือไม่
หากคีย์สโตร์มีใบรับรอง ให้ย้ายไปที่ Cause: Certificate Authority ไม่ตรงกัน
หากคีย์สโตร์ไม่มีใบรับรอง นั่นเป็นสาเหตุที่ผู้ประมวลผลข้อความไม่ส่งใบรับรองไคลเอ็นต์

ความละเอียด

ตรวจสอบว่าได้อัปโหลดเชนใบรับรองไคลเอ็นต์ที่ถูกต้องและสมบูรณ์ไปยังคีย์สโตร์ที่เฉพาะเจาะจงในตัวประมวลผลข้อความแล้ว

สาเหตุ: ผู้ออกใบรับรองไม่ตรงกัน

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

โปรดทําตามขั้นตอนด้านล่างเพื่อยืนยันว่าเป็นกรณีนี้หรือไม่

แสดงใบรับรองสำหรับ Keystore API
ดูรายละเอียดของใบรับรองแต่ละรายการที่ได้ในขั้นตอนที่ 1 ด้านบนโดยใช้รับใบรับรองสำหรับ Keystore API

จดบันทึกผู้ออกใบรับรอง Leaf (ใบรับรองใบแรกในเชนใบรับรอง) ที่จัดเก็บไว้ในคีย์สโตร์

ใบรับรอง Leaf ตัวอย่าง

{
  "certInfo" : [ {
    "basicConstraints" : "CA:FALSE",
    "expiryDate" : 1578889324000,
    "isValid" : "Yes",
    "issuer" : "CN=MyCompany Test SHA2 CA G2, DC=testcore, DC=test, DC=dir, DC=mycompany, DC=com",
    "publicKey" : "RSA Public Key, 2048 bits",
    "serialNumber" : "65:00:00:00:d2:3e:12:d8:56:fa:e2:a9:69:00:06:00:00:00:d2",
    "sigAlgName" : "SHA256withRSA",
    "subject" : "CN=nonprod-api.mycompany.com, OU=ITS, O=MyCompany, L=MELBOURNE, ST=VIC, C=AU",
    "subjectAlternativeNames" : [ ],
    "validFrom" : 1484281324000,
    "version" : 3
  } ],
  "certName" : "nonprod-api.mycompany.com.key.pem-cert"
}

ในตัวอย่างข้างต้น ผู้ออกใบรับรอง/ผู้ออกใบรับรองคือ "CN=MyCompany Test SHA2 CA G2, DC=testcore, DC=test, DC=dir, DC=mycompany, DC=com"

กำหนดรายชื่อผู้ออกหรือผู้ออกใบรับรองที่เซิร์ฟเวอร์แบ็กเอนด์ยอมรับโดยใช้เทคนิคข้อใดข้อหนึ่งต่อไปนี้
เทคนิคที่ 1: ใช้คำสั่ง openssl ด้านล่าง
```
openssl s_client -host <backend server host name> -port <Backend port#> -cert <Client Certificate> -key <Client Private Key>
```
โปรดดูส่วนที่มีชื่อว่า "ชื่อ CA ของใบรับรองไคลเอ็นต์ที่ยอมรับได้" ในเอาต์พุตของคำสั่งนี้ดังที่แสดงด้านล่าง
```
Acceptable client certificate CA names
/C=AU/ST=VIC/L=MELBOURNE/O=MyCompany/OU=ITS/CN=nonprod-api.mycompany.com
/C=AU/ST=VIC/L=MELBOURNE/O=MyCompany/OU=ITS/CN=nonprod-api.mycompany.com
```
เทคนิคที่ 2: ตรวจสอบแพ็กเก็ต Certificate Request ในแพ็กเก็ต TCP/IP ซึ่งเซิร์ฟเวอร์แบ็กเอนด์ขอให้ไคลเอ็นต์ส่งใบรับรอง

ในตัวอย่างแพ็กเก็ต TCP/IP ที่แสดงด้านบน แพ็กเก็ต Certificate Request คือข้อความที่ 7 โปรดดูส่วน "ชื่อเฉพาะ" ซึ่งมีผู้ออกใบรับรองที่ยอมรับได้ของเซิร์ฟเวอร์แบ็กเอนด์

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

ในตัวอย่างข้างต้น คุณสังเกตเห็นว่าผู้ออกใบรับรอง Leaf ของไคลเอ็นต์ในคีย์สโตร์ของผู้ประมวลผลข้อความไม่ตรงกับผู้ออกใบรับรองที่ยอมรับของเซิร์ฟเวอร์แบ็กเอนด์ ดังนั้น ตัวประมวลผลข้อความจะไม่ส่งใบรับรองไคลเอ็นต์ไปยังเซิร์ฟเวอร์แบ็กเอนด์ ซึ่งจะทำให้แฮนด์เชค SSL ล้มเหลวและเซิร์ฟเวอร์แบ็กเอนด์ส่งข้อความ "Fatal alert: bad_certificate"

ความละเอียด

ตรวจสอบว่าใบรับรองที่มีผู้ออกใบรับรอง/ผู้ออกใบรับรองที่ตรงกับผู้ออกใบรับรอง/ผู้ออกใบรับรองของ Leaf Certificate ของไคลเอ็นต์ (ใบรับรองแรกในเชน) ได้รับการจัดเก็บไว้ใน Truststore ของเซิร์ฟเวอร์แบ็กเอนด์
ในตัวอย่างที่อธิบายไว้ใน Playbook นี้ ระบบได้เพิ่มใบรับรองที่มีผู้ออกใบรับรอง "issuer" : "CN=MyCompany Test SHA2 CA G2, DC=testcore, DC=test, DC=dir, DC=mycompany, DC=com" ลงใน Truststore ของเซิร์ฟเวอร์แบ็กเอนด์เพื่อแก้ไขปัญหา

หากยังคงพบปัญหาอยู่ ให้ไปที่ต้องรวบรวมข้อมูลการวินิจฉัย

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

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

หากคุณเป็นผู้ใช้ Public Cloud ให้ระบุข้อมูลต่อไปนี้
1. ชื่อองค์กร
2. ชื่อสภาพแวดล้อม
3. ชื่อพร็อกซี API
4. ใช้คำสั่ง curl เพื่อจำลองข้อผิดพลาด
5. ไฟล์การติดตามที่แสดงข้อผิดพลาด
6. แพ็กเก็ต TCP/IP ที่บันทึกในเซิร์ฟเวอร์แบ็กเอนด์
หากคุณเป็นผู้ใช้ Private Cloud ให้ระบุข้อมูลต่อไปนี้
1. สังเกตข้อความแสดงข้อผิดพลาดให้เสร็จสมบูรณ์
2. กลุ่มพร็อกซี API
3. ไฟล์การติดตามที่แสดงข้อผิดพลาด
4. บันทึกตัวประมวลผลข้อความ /opt/apigee/var/log/edge-message-processor/logs/system.log
5. แพ็กเก็ต TCP/IP ที่บันทึกในเซิร์ฟเวอร์แบ็กเอนด์หรือผู้ประมวลผลข้อมูลข้อความ
6. เอาต์พุตของรับใบรับรองสำหรับ keystore API
รายละเอียดเกี่ยวกับส่วนต่างๆ ที่คุณได้ลองใช้ใน Playbook นี้และข้อมูลเชิงลึกอื่นๆ ที่จะช่วยให้เราจัดการกับปัญหานี้ได้อย่างรวดเร็ว