0

I have an application running under Tomcat 9, using JDK 1.8.0_111 as the runtime, on Windows 7 x64, that's trying to use a NitroKey HSM through the SunPKCS11 CSP and the OpenSC driver.

This works fine from the command line, including from a shell running under the same account as the Tomcat service uses.

Under Tomcat, however, the SunPKCS11 constructor throws a ProviderException with the message "Initialization failed". So far I've debugged this down to C_GetSlotInfo returning CKR_GENERAL_ERROR; that becomes a PKCS11Exception (with no further detail) and that gets wrapped in the ProviderException.

The slot number is correct - the NitroKey only has a single slot, so the number is 0. Besides the application itself, I have no problems using the HSM with keytool, OpenSSL, etc through PKCS#11. (Or through CAPI, for that matter.) It only fails under Tomcat.

Any ideas? Some other people have posted queries about this sort of failure if the HSM (or smart card) has been removed and re-inserted - see for example remove and insert smartcard using sunpkcs#11 and tomcat - but that's not the case here. The token hasn't been removed and remains accessible to everything else. But those questions imply that there's no inherent restriction on using SunPKCS11 and OpenSC under Tomcat.

I'm going to grab the JDK sources and debug further into C_GetSlotInfo, and try some other experiments such as spawning keytool with the appropriate options to see if it can talk to the card. But if anyone has any other suggestions I'd be glad to hear them.

In case anyone wants details: I'm invoking the SunPKCS11 constructor with a single argument, the path to the configuration file. It's reading the file successfully (I get a different exception if the file path is bogus or the file is unreadable). The file is very simple:

# PKCS#11 configuration file for Java to use NitroKey in slot 0 on Windows
name = NitroKey
library = c:/Windows/System32/opensc-pkcs11.dll
slotListIndex = 0

At the point of failure, SunPKCS11 hasn't seen any other details yet, such as the key container name or HSM PIN. Those would come later if the constructor didn't throw the exception.

Community
  • 1
  • 1
Michael Wojcik
  • 158
  • 3

1 Answers1

0

Some users including me encountered similar problem on Microsoft IIS application server. Changing user account to LocalSystem or LocalService usually helped to resolve the problem.

Community
  • 1
  • 1
jariq
  • 11,681
  • 3
  • 33
  • 52
  • Thanks. I was going to try running Tomcat under different accounts (right now it's using a normal-privilege account for security purposes), but forgot. Appreciate the reminder. I'll do some experimenting and report back. – Michael Wojcik May 03 '17 at 15:46
  • Well, that's what I get for posting questions after a long day. Running as Local System with Interact with Desktop enabled (so running on the primary session / WinStation / Desktop rather than the Service Desktop), Tomcat can indeed access the HSM. This needs more investigation, since I really don't want my signing server running as Local System on the interactive desktop, but it's a workaround. Thanks! – Michael Wojcik May 03 '17 at 15:50
  • Further experimentation shows it doesn't need Interact with Desktop, so it's not a desktop issue. OK, probably something to do with either 1) logon type or 2) token privileges. I can likely narrow it down from there, and get it running in a reduced-privilege account. (Or I may just have my application use JNI to disable unneeded privs in the thread token, which would mitigate somewhat.) Thanks again. – Michael Wojcik May 03 '17 at 15:53
  • @MichaelWojcik my experience shows that this behavior is token or rather PKCS#11 library dependent. Some PKCS#11 libraries (including one provided by OpenSC project) require LocalSystem or LocalService in order to work, others don't. But I have never traced the root cause of the issue. Please let me know if you find out anything. – jariq May 03 '17 at 17:12