i3e 2030.5接口调用问题

Question

最近厂里要拓展市场，要研究i3e2030.5，全英文的接口文档一脸懵逼，第二个接口就遇到难题无法通过，不知道这里是否有了解这个协议的人，先把问题描述以下:
1 文档，主要是向服务器发送一个https请求，tls1.2协议，需要用到TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 密码套间，握手成功接口就算通过了。
COMM-003 - Basic Security [C,A,S]
Purpose
Verify ability to connect to server using HTTPS and IEEE 2030.5 permissible cypher suite.
The basic security test verifies that the Client can correctly communicate with an IEEE 2030.5
server using basic security requirements. For example, the HTTPS, TLS 1.2,
TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 cipher suite. TLS authentications are tested
based on requirements specified in the IEEE 2030.5 Application Protocol Specification.
Setup

1. Server and Client support the TLS based HTTP communication as specified in the
   Requirements, including the use of mandatory TLS_ECDHE_ECDSA_WITH
   _AES_128_CCM_8 cipher suite.
2. Server is configured to use either the default TLS port (443) or another port. Client is
   configured to use the supported TLS port and IP address from the Server.
3. Client can send and receive TLS based HTTPS messages as specified in the
   requirements, including the use of mandatory TLS_ECDHE_ECDSA_WITH
   _AES_128_CCM_8 cipher suite.
   Procedure
4. [T] Record the Client/Server communications.
5. [C] Using the known IP address, port number, and DeviceCapability URI, send a
   TLS based HTTP GET request to the Server.
6. [S] Successfully receive the TLS based HTTP GET request and respond with the
   DeviceCapability resource payload through the TLS port number.
   Pass/Fail Criteria
   • [C] The Client successfully established a TLS HTTP session by conforming to the
   requirements specified in RFC 5246, section 7.4. Verify by inspecting the TLS packets,
   including verification that TLS_ECDHE_ECDSA_WITH _AES_128_CCM_8 cipher suite
   was used. Successfully sent a TLS based HTTP GET request to the Server
   DeviceCapability resource using the known IP address, port number, and
   DeviceCapability URI.
   • [S] Server successfully established a TLS HTTP session by conforming to the
   requirements specified in RFC 5246, section 7.4. Verify by inspecting the TLS packets,
   including verification that TLS_ECDHE_ECDSA_WITH _AES_128_CCM_8 cipher suite
   was used. Successfully received the TLS based HTTP GET request and responded with
   the DeviceCapability resource payload as the HTTP GET response.

2 开启一个测试软件的服务端，是qualityLogic，设置如下

设置完以后开启一个测试，服务端就开始监听请求

3 用postman发起请求
设置如下

主要就是输入地址 设置tls版本 和 加入 密码套件 ，tls那里因为是排除就不做选择，套件选择文档中提到的TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8
发起请求后reponse提示以下握手错误：

Error: write EPROTO 67057928:error:10000410:SSL routines:OPENSSL_internal:SSLV3_ALERT_HANDSHAKE_FAILURE:../../../../src/third_party/boringssl/src/ssl/tls_record.cc:594:SSL alert number 40
67057928:error:1000009a:SSL routines:OPENSSL_internal:HANDSHAKE_FAILURE_ON_CLIENT_HELLO:../../../../src/third_party/boringssl/src/ssl/handshake.cc:644:

4 用wireshark抓包发现
Client Hello 中有18个套件，却没有文档中的 TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8

Frame 4: 571 bytes on wire (4568 bits), 571 bytes captured (4568 bits) on interface \Device\NPF_{3758D140-2713-4C3D-A966-023CC179ECCA}, id 0
Ethernet II, Src: IntelCor_7d:a2:8a (f8:9e:94:7d:a2:8a), Dst: WuhanGre_ef:00:a0 (7c:c9:26:ef:00:a0)
Internet Protocol Version 4, Src: 192.168.71.97, Dst: 115.236.121.93
Transmission Control Protocol, Src Port: 61320, Dst Port: 443, Seq: 1, Ack: 1, Len: 517
Transport Layer Security
    TLSv1.2 Record Layer: Handshake Protocol: Client Hello
        Content Type: Handshake (22)
        Version: TLS 1.0 (0x0301)
        Length: 512
        Handshake Protocol: Client Hello
            Handshake Type: Client Hello (1)
            Length: 508
            Version: TLS 1.2 (0x0303)
            Random: 2f9bc23b7e413806bc095178a8cffc00f3362eadfa418ee4e4aa0d1b4c0b4ba1
            Session ID Length: 32
            Session ID: f21127858d395008d03133322d6cf9d51dcf390d3863377ecfa2c532b5b59f1b
            Cipher Suites Length: 36
            **Cipher Suites (18 suites)
                Cipher Suite: TLS_CHACHA20_POLY1305_SHA256 (0x1303)
                Cipher Suite: TLS_AES_128_GCM_SHA256 (0x1301)
                Cipher Suite: TLS_AES_256_GCM_SHA384 (0x1302)
                Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
                Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)
                Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
                Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c)
                Cipher Suite: TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca9)
                Cipher Suite: TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca8)
                Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)
                Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
                Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)
                Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
                Cipher Suite: TLS_RSA_WITH_AES_128_GCM_SHA256 (0x009c)
                Cipher Suite: TLS_RSA_WITH_AES_256_GCM_SHA384 (0x009d)
                Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
                Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
                Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)**
            Compression Methods Length: 1
            Compression Methods (1 method)
            Extensions Length: 399
            Extension: server_name (len=20)
            Extension: extended_master_secret (len=0)
            Extension: renegotiation_info (len=1)
            Extension: supported_groups (len=8)
            Extension: ec_point_formats (len=2)
            Extension: session_ticket (len=192)
            Extension: signature_algorithms (len=20)
            Extension: key_share (len=38)
            Extension: psk_key_exchange_modes (len=2)
            Extension: supported_versions (len=5)
            Extension: padding (len=67)
            [JA3 Fullstring: 771,4867-4865-4866-49199-49195-49200-49196-52393-52392-49161-49171-49162-49172-156-157-47-53-10,0-23-65281-10-11-35-13-51-45-43-21,29-23-24,0]
            [JA3: 7d52c9129b8b07502d1471697c2982dd]

Server Hello 中关于套件的是

不知道是不是密码套件的原因导致也不清楚，只是觉得很奇怪，发起请求只设置了一个套件，抓包有18个且都和文档中的套件不匹配

网上有个帖子说postman对套件的格式有要求 “postman对语法是有规范的，下划线“_”不行，不能有“with”，不能有“TLS”，AES和128之间不能有“-” ”，但按照他的格式修改套件后也没用，还报无法匹配到套件的错误
另外从外商那里还拿到了一个证书文件 pem格式的，但尝试导入也无果，目前最大的可能是套件问题，不知道哪位有过类似的经验的请教一下

Answer 1

你的问题非常典型，涉及IEEE 2030.5协议测试、TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8密码套件的HTTPS握手，以及Postman工具无法指定要求的密码套件。下面我会给你详细梳理原因、解决思路，并给出建议：

---

1. 问题核心总结

• 测试软件：QualityLogic作为服务端，要求TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8密码套件。
• 客户端：你用Postman作为客户端，指定了套件，但Wireshark抓包发现ClientHello里没有这个套件，只出现了默认的其它套件，导致握手失败（SSLV3_ALERT_HANDSHAKE_FAILURE）。
• 证书：外商给了pem证书，导入没用。
• Postman密码套件格式不匹配，修改语法也无效。

---

2. 关键点解释

(1) TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8是什么？

• 这是一种非常安全且不常见的TLS密码套件，很多客户端库默认不支持，需要底层OpenSSL/BoringSSL编译时开启。
• 它属于TLS 1.2，且需要ECC证书（ECDSA），不是RSA证书。

(2) Postman的限制

• Postman不支持自定义ClientHello密码套件顺序和内容，它用的是Electron和Node.js的TLS实现（BoringSSL）。
• Postman的“TLS configuration”界面，实际只是排除部分套件，不能指定只用某一个套件。
• 即使你“设置”了密码套件，抓包也只能看到它发出的一组默认套件，无法强制使用只一个指定套件（Postman文档也明确说明）。
• 语法格式问题只是部分原因，根本原因是Postman底层库不支持“强制只用一个套件”。

(3) 证书问题

• 你拿到pem证书，如果是服务器证书，可以直接导入Postman信任；但客户端证书和私钥如果不对，也无法完成握手。
• 但你的主要问题不是证书，而是套件。

---

3. 解决建议与可行方案

结论：用Postman无法完成IEEE 2030.5规定的密码套件握手。
建议如下：

方案1：用支持自定义密码套件的工具

（A）OpenSSL命令行客户端（推荐）

OpenSSL支持直接指定密码套件，并可用于测试TLS握手。

假设你服务器地址是server.com:443，命令如下：

openssl s_client -connect server.com:443 \
  -tls1_2 \
  -cipher 'ECDHE-ECDSA-AES128-CCM8' \
  -CAfile your_ca.pem

• -cipher参数可严格指定密码套件。
• -tls1_2强制TLS 1.2。
• -CAfile指定根证书。
• 你可以抓包看ClientHello，只发出这个套件。

如果你的openssl版本不支持此套件，需升级或重新编译。

（B）用curl命令行

curl同样可指定密码套件，但要看openssl支持：

curl --ciphers 'ECDHE-ECDSA-AES128-CCM8' --tlsv1.2 https://server.com/DeviceCapability --cacert your_ca.pem

（不同平台curl可能不支持此密码套件）

（C）用Python requests+pyOpenSSL

或者用Python脚本+requests库+pyOpenSSL，可以通过定制SSL上下文实现，但相对复杂。

（D）自己用C/C++或Java写个小客户端

用OpenSSL或Java的SSLSocket，代码里指定密码套件。

---

方案2：Postman替代工具

• Postman等桌面工具无法细粒度控制密码套件，建议换成命令行工具（openssl/curl）或代码自己实现。
• 甚至很多浏览器也无法指定单一密码套件。

---

方案3：确认服务器配置

• QualityLogic服务器必须支持ECDSA证书（不是RSA），否则握手会因证书类型错而失败。
• 服务器端必须开启该密码套件。
• 如果你用的外商pem是服务器证书，只需在客户端信任即可；如果是客户端证书，需带私钥。

---

4. 总结流程

1. 用openssl/curl测试，指定密码套件，看握手是否成功。
2. 抓包确认ClientHello里只有你指定的套件。
3. 交换证书，保证服务器端和客户端都支持ECDSA证书。
4. 如果还不行，把抓包文件和完整错误日志发给供应商技术支持/质量认证机构（QualityLogic）。

---

5. 参考代码

openssl s_client -connect 192.168.x.x:443 \
  -tls1_2 \
  -cipher 'ECDHE-ECDSA-AES128-CCM8'

如果你需要自动化GET请求，可以用如下命令：

openssl s_client -connect 192.168.x.x:443 -tls1_2 -cipher 'ECDHE-ECDSA-AES128-CCM8' <<EOF
GET /DeviceCapability HTTP/1.1
Host: 192.168.x.x

EOF

---

6. 额外建议

• 你厂里如果做的是能源/电力相关（IEEE 2030.5常用于电动汽车充电桩、智能电网），建议让研发用openssl/curl/代码实现这个流程，别折腾Postman了。
• 可以让外商或设备商给个推荐的测试脚本或工具，他们经常遇到这种互通性问题。
• 如果还要走认证，抓包（wireshark）+openssl日志是最有力的证据。

---

有任何具体openssl/curl命令不会写、证书导入问题、服务器配置不明等，可以补充详细信息，我可以给你具体命令和代码！