看起来你在调试asyncua的证书加密认证时碰到了挺棘手的问题——服务端报解密失败，客户端直接超时，我帮你梳理几个高概率的排查方向：

1. 客户端set_security参数配置错误（核心嫌疑） #

你客户端代码里的这行配置明显有问题：

await client.set_security(
    ...
    server_certificate=str(ca_cert),  # 这里传了CA证书，而非服务端证书！
)

server_certificate参数的作用是让客户端用服务端的公钥加密通信数据，你现在传的是CA的证书，导致客户端用CA的公钥加密，而服务端只能用自己的私钥解密，完全不匹配，这直接就是Decryption failed的元凶！

修正方案：
把这里改成服务端证书的实际路径，或者如果依赖信任库自动验证，可以留空（客户端会自动获取服务端证书并通过CA验证）：

await client.set_security(
    policy=SecurityPolicyBasic256Sha256,
    certificate=str(cert),
    private_key=str(private_key),
    # 替换成你的服务端证书实际路径
    server_certificate=str(Path(cert_base / "certificate/server/asyncua_opcua_server_cert_subjectAltName.pem")),
)

2. 应用URI与证书的绑定一致性 #

你代码里设置了：

• 服务端：server_app_uri = "asyncua:python:DNAMIC:server"
• 客户端：client.application_uri = "asyncua:python:DNAMIC:client"

要确保你用CA签名的证书里，Subject Alternative Name（SAN）字段包含了对应的应用URI。可以用openssl命令检查证书：

openssl x509 -in 你的证书文件.pem -text -noout | grep -A 5 "Subject Alternative Name"

如果没有对应的应用URI条目，需要重新生成CSR并让CA签名，或者在生成证书时添加该扩展。

3. 信任库与证书验证逻辑的细节 #

你两端都开启了USE_TRUST_STORE = True，要注意：

• 服务端的信任目录下必须存放CA的根证书，这样才能验证客户端证书是CA合法签发的
• 客户端的信任目录下也必须存放CA的根证书，用于验证服务端证书的合法性
• 检查证书的扩展密钥用法（EKU）：服务端证书需要包含Server Auth，客户端证书需要包含Client Auth，同样用openssl命令检查：

openssl x509 -in 你的证书文件.pem -text -noout | grep -A 3 "Extended Key Usage"

4. 简化测试逐步排查 #

可以先做最小化验证，排除干扰：

1. 把两端的USE_TRUST_STORE改成False，关闭信任链验证，只测试加密通信
2. 给证书、密钥路径添加存在性检查，确保文件可读：

assert cert.exists(), f"客户端证书未找到：{cert}"
assert private_key.exists(), f"客户端私钥未找到：{private_key}"

3. 验证通过后再逐步开启信任库，添加CA验证逻辑

额外小提示 #

你服务端代码里开启了信任库，但没配置CertificateUserManager——这个不是加密失败的直接原因，但如果后续需要基于证书做权限控制，记得补上：

# 服务端添加证书用户管理器
server.user_manager = CertificateUserManager()

备注：内容来源于stack exchange，提问作者Autolab