หน้านี้ได้รับการแปลโดย 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 ระหว่าง Message Processor และเซิร์ฟเวอร์แบ็กเอนด์ด้วยการตั้งค่า 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 Private และระบบคลาวด์สาธารณะ
ผู้ออกใบรับรองไม่ตรงกัน	ผู้ออกใบรับรองของใบรับรอง Leaf (ใบรับรองแรกในสายใบรับรอง) ในคีย์สโตร์ของผู้ประมวลผลข้อมูลข้อความไม่ตรงกับผู้ออกใบรับรองที่เซิร์ฟเวอร์แบ็กเอนด์ยอมรับ	ผู้ใช้ Edge Private และระบบคลาวด์สาธารณะ

ขั้นตอนการวินิจฉัยทั่วไป

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

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

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

ค้นหารหัสข้อความนี้ในบันทึกของ Message Processor /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 ในเซิร์ฟเวอร์แบ็กเอนด์หรือ Message Processor ขอแนะนำให้บันทึกเซิร์ฟเวอร์แบ็กเอนด์เมื่อมีการถอดรหัสแพ็กเก็ตไว้แล้ว เซิร์ฟเวอร์แบ็กเอนด์
2. หากคุณเป็นผู้ใช้ระบบคลาวด์สาธารณะ ให้บันทึก TCP/IP แพ็กเก็ตบนเซิร์ฟเวอร์แบ็กเอนด์
3. เมื่อคุณตัดสินใจได้แล้วว่าต้องการจับแพ็กเก็ต TCP/IP ที่ไหน ให้ใช้ ต่ำกว่า tcpdump เพื่อบันทึกแพ็กเก็ต TCP/IP
วิเคราะห์แพ็กเก็ต TCP/IP โดยใช้เครื่องมือ Wireshark หรือเครื่องมือที่คล้ายกันซึ่งคุณคุ้นเคยอยู่แล้ว

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

ข้อความสำรอง

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

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

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

การวินิจฉัย

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

โปรดทำตามขั้นตอนต่อไปนี้เพื่อพิจารณาว่าเกิดจากสาเหตุหรือไม่

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

ความละเอียด

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

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

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

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

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

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

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