OpenSSL 3.0.7 TLS通信：ECC证书验证失败求助

以下是导致该问题的常见原因及分析：

• 客户端信任存储未包含ECC证书对应的CA根证书
  客户端验证服务器证书时，会检查证书链是否能追溯到本地信任的CA根证书。如果你的RSA证书和ECC证书由不同CA签发，或者客户端仅配置了RSA类型的CA根证书（部分CA会单独提供RSA和ECC根证），就会触发certificate verify failed错误。服务器端收到的tlsv1 alert unknown ca（alert 48）正是客户端反馈的信任链验证失败信号。
  需确保客户端通过SSL_CTX_load_verify_locations()加载了ECC证书对应的CA根证书文件或目录。

• 服务器端ECC证书链不完整
  服务器若仅加载了ECC服务器证书，未配置中间CA证书，会导致客户端无法构建完整的信任链。RSA证书可能已附带完整链，但ECC证书的中间证未被正确加载。
  应使用SSL_CTX_use_certificate_chain_file()加载包含完整链的ECC证书文件，而非单独的服务器证书。

• ECC证书与私钥不匹配
  若服务器端加载的ECC证书对应的私钥并非ECC类型（比如误配了RSA私钥），或证书与私钥的密钥参数不匹配，会导致服务器证书无法正常完成TLS握手的签名验证步骤，间接引发客户端的证书验证失败。
  可通过openssl x509 -noout -text -in ecc-cert.pem和openssl ec -noout -text -in ecc-key.pem命令核对证书和私钥的公钥参数是否一致。

• TLS套件配置未包含ECC相关选项
  即使调用了SSL_CTX_set1_groups_list()启用ECC曲线组，若未配置支持ECC的TLS套件，客户端与服务器可能无法协商出兼容的ECC加密套件，进而导致证书验证流程异常。
  需通过SSL_CTX_set_cipher_list()或SSL_CTX_set_ciphersuites()（TLS 1.3）指定包含ECC的套件，例如ECDHE-ECDSA-AES256-GCM-SHA384、TLS_AES_256_GCM_SHA384等。

• OpenSSL 3.0提供者配置缺失
  OpenSSL 3.0引入了提供者（Provider）机制，ECC算法依赖default提供者提供支持。若你的代码自定义了提供者加载逻辑，未加载default提供者，会导致ECC相关算法无法正常工作。
  需确保在初始化SSL上下文前调用OSSL_PROVIDER_load(NULL, "default")加载默认提供者。

内容的提问来源于stack exchange，提问作者Martin Janitor