Wildfly 10.x配置HSM启用TLSv1.2时抛出CKR_GENERAL_ERROR报错求解

API 探路者

2026-9-25

Wildfly 10.x对接HSM并配置TLSv1.2异常问题

我们有用户尝试配置Wildfly 10.x对接HSM，同时支持TLSv1.2。
Wildfly的配置XML schema与Tomcat不同，因此我们尝试调整Tomcat 10对接HSM的方案适配Wildfly的配置规则，初步调整后的配置如下：

<management>
  <security-realms>
    <security-realm name="ApplicationRealm">
      <ssl>
        <engine enabled-protocols="TLSv1.2" enabled-cipher-suites="TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA TLS_RSA_WITH_AES_128_CBC_SHA TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_128_CBC_SHA256 TLS_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_RSA_WITH_AES_256_CBC_SHA TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_AES_256_CBC_SHA256 TLS_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384"/>
      <keystore keystore-password="123456" alias="wildfly-demo" provider="SunPKCS11-CryptoServerR3"/>
      </ssl>
    </security-realm>
    <security-realm name="ManagementRealm">
      <authentication>
        <local default-user="$local" skip-group-loading="true"/>
        <properties path="mgmt-users.properties" relative-to="jboss.server.config.dir"/>
      </authentication>
      <authorization map-groups-to-roles="false">
        <properties path="mgmt-groups.properties" relative-to="jboss.server.config.dir"/>
      </authorization>
    </security-realm>
    <security-realm name="AuthenticationRealm">
      <authentication>
        <local default-user="$local" allowed-users="*" skip-group-loading="true"/>
        <properties path="application-users.properties" relative-to="jboss.server.config.dir"/>
      </authentication>
      <authorization>
        <properties path="application-roles.properties" relative-to="jboss.server.config.dir"/>
      </authorization>
    </security-realm>
  </security-realms>
  ....
</management>

启动standalone.bat后，从HSM的P11 provider日志可看到正常交互，日志片段如下：

22.11.2021 13:24:34.437 | [00021376:00013004] C_Initialize                     | T: leave C_Initialize()
22.11.2021 13:24:34.437 | [00021376:00013004] C_GetInfo                        | T: enter 
22.11.2021 13:24:34.446 | [00021376:00013004] C_GetSlotList                    | T: enter 
22.11.2021 13:24:34.447 | [00021376:00013004] C_GetSlotList                    | T: enter 
22.11.2021 13:24:34.448 | [00021376:00013004] C_GetSlotInfo                    | T: enter 
22.11.2021 13:24:34.546 | [00021376:00013004] C_GetTokenInfo                   | T: enter 
22.11.2021 13:24:34.571 | [00021376:00013004] C_OpenSession                    | T: enter 
22.11.2021 13:24:34.840 | [00021376:00013004] C_GetMechanismList               | T: enter 
22.11.2021 13:24:34.845 | [00021376:00013004] C_GetMechanismList               | T: enter

随后Java抛出异常，返回「CKR_GENERAL_ERROR」，异常栈如下：

13:44:53,064 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.server.controller.management.security_realm.ApplicationRealm.key-manager: org.jboss.msc.service.StartException in service jboss.server.controller.management.security_realm.ApplicationRealm.key-manager: Failed to start service
        at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904)
        at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
        at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
        at java.base/java.lang.Thread.run(Thread.java:830)
Caused by: java.security.ProviderException: Initialization failed
        at jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11.<init>(SunPKCS11.java:382)
        at jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11$1.run(SunPKCS11.java:113)
        at jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11$1.run(SunPKCS11.java:110)
        at java.base/java.security.AccessController.doPrivileged(AccessController.java:554)
        at jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11.configure(SunPKCS11.java:110)
        at java.base/sun.security.jca.ProviderConfig$3.run(ProviderConfig.java:251)
        at java.base/sun.security.jca.ProviderConfig$3.run(ProviderConfig.java:242)
        at java.base/java.security.AccessController.doPrivileged(AccessController.java:312)
        at java.base/sun.security.jca.ProviderConfig.doLoadProvider(ProviderConfig.java:242)
        at java.base/sun.security.jca.ProviderConfig.getProvider(ProviderConfig.java:222)
        at java.base/sun.security.jca.ProviderList.getProvider(ProviderList.java:266)
        at java.base/sun.security.jca.ProviderList.getService(ProviderList.java:379)
        at java.base/sun.security.jca.GetInstance.getInstance(GetInstance.java:157)
        at java.base/java.security.Security.getImpl(Security.java:700)
        at java.base/java.security.KeyStore.getInstance(KeyStore.java:868)
        at org.jboss.as.domain.management.security.ProviderKeyManagerService.start(ProviderKeyManagerService.java:57)
        at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
        at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
        ... 3 more
Caused by: sun.security.pkcs11.wrapper.PKCS11Exception: CKR_GENERAL_ERROR
        at jdk.crypto.cryptoki/sun.security.pkcs11.wrapper.PKCS11.C_Initialize(Native Method)
        at jdk.crypto.cryptoki/sun.security.pkcs11.wrapper.PKCS11$SynchronizedPKCS11.C_Initialize(PKCS11.java:1631)
        at jdk.crypto.cryptoki/sun.security.pkcs11.wrapper.PKCS11.getInstance(PKCS11.java:166)
        at jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11.<init>(SunPKCS11.java:336)
        ... 20 more

我们已二次核对配置与密钥ID一致，验证结果如下：

D:\Wildfly10\wildfly-10.1.0.Final>grep wildfly-demo "D:\Wildfly10\wildfly-10.1.0.Final\standalone\configuration\standalone.xml"
            <keystore keystore-password="123456" alias="wildfly-demo" provider="SunPKCS11-CryptoServerR3"/>

D:\Wildfly10\wildfly-10.1.0.Final>p11tool2 loginuser=123456 listobjects | grep wildfly-demo
  CKA_LABEL                      = wildfly-demo
                0x77696C64 666C792D 64656D6F          |wildfly-demo    |
                0x77696C64 666C792D 64656D6F          |wildfly-demo    |

D:\Wildfly10\wildfly-10.1.0.Final>grep wildfly_demo "D:\Wildfly10\wildfly-10.1.0.Final\standalone\configuration\standalone.xml"

D:\Wildfly10\wildfly-10.1.0.Final>p11tool2 loginuser=123456 listobjects | grep wildfly_demo

D:\Wildfly10\wildfly-10.1.0.Final>

目前HSM已开启全量日志模式，若HSM自身返回CKR_GENERAL_ERROR会记录对应映射的原始错误，因此我们判断报错是Wildfly在插槽中未找到其所需的特定内容，但我们对Wildfly的底层逻辑不熟悉，无法定位问题点。我们已在Java选项中开启ssl:handshake日志，但由于https着陆页无法启动，未触达握手阶段。

我们怀疑存在其他Wildfly配置错误，另外曾看到资料提及Wildfly可能需要本地证书存储（与BouncyCastle相关），会尝试将证书复制到本地存储，若该配置可解决问题，烦请提供对应的示例XML配置，感谢各位的指点。

内容的提问来源于stack exchange，提问作者rip...