We have a user trying to configure Wildfly 10.x to use an HSM, and support TLSv1.2.
The configuration XML schema is different from Tomcat's, so we are having to figure out how to restructure this answer Tomcat 10 Using HSM to fit into Wildfly's schema. Kind-of working first assumption:
<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>
When we start standalone.bat, looking at the HSM's log from its P11 provider, we get activity in the HSM logs (extract):
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
And then Java throws an exception and reports "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
based on the comment below, I have double checked and validated that the above agrees with the configuration and key 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>
The HSM provider is in "log everything" mode, and if it were returning CKR_GENERAL_ERROR then it would show what error it was mapping to that (the HSM can return 100s of different errors, but these have to be mapped to the 30 or so P11 errors). I think it really means that it is looking for something specific on the slot and not finding that, but we don't know enough about what Wildfly is looking for, so we don't know where to look.
We've also enabled ssl:handshake in the Java options, but it never gets to that since the landing page isn't coming up under https.
It may be that Wildfly is misconfigured elsewhere, and our lack of background in the product gets in the way. Please feel free to redirect our target to a different part of the configuration file/schema.
Thank you for any hints...
I remember reading someplace on the web that implied there may need to be a local certificate store, and that Wildfly would attempt to copy the certificate into that local store (was related to BouncyCastle). If that would help, some example xml to show what that config would approximate would be helpful.
