netty-tcnative加载非默认openssl引擎cloudhsm失败与版本不匹配问题咨询

版本匹配问题说明 #

你当前使用的linux-x86_64-fedora分类器的netty-tcnative依赖默认静态编译内置了1.0.1e-fips版本的openssl，日志中上报的版本是内置openssl的版本，和系统本地安装的1.0.2k-fips没有关联。二者版本不匹配是你加载cloudhsm引擎失败的核心原因，适配系统1.0.2k版本编译的cloudhsm引擎无法在netty内置的旧版openssl上运行。

加载cloudhsm引擎的解决方案 #

按操作优先级执行以下步骤即可解决问题：

• 替换netty-tcnative依赖为动态链接版本，该版本会直接调用系统安装的openssl库，和本地版本完全对齐，依赖配置修改为：

<dependency>
    <groupId>io.netty</groupId>
    <artifactId>netty-tcnative</artifactId>
    <classifier>linux-x86_64</classifier>
    <version>2.0.38.Final</version>
</dependency>

• 配置动态库加载路径，启动Java进程前将openssl引擎目录和cloudhsm的库目录加入LD_LIBRARY_PATH，示例命令：

export LD_LIBRARY_PATH=/usr/lib64/openssl/engines:/opt/cloudhsm/lib:$LD_LIBRARY_PATH

• 调整启动参数，除保留-Dio.netty.handler.ssl.openssl.engine=cloudhsm外，新增参数-Dio.netty.handler.ssl.openssl.engineLoadFailureFatal=true便于排查加载错误，可额外添加-Djavax.net.debug=ssl,engine打印更详细的调试日志。
• 若调整后仍加载失败，确认cloudhsm引擎的动态库是适配系统openssl 1.0.2k-fips版本编译的，跨版本编译的引擎无法正常加载。

内容的提问来源于stack exchange，提问作者Paul Whelan