000016776 - RSA Key Manager stops recognizing LunaSA HSM if the HSM becomes unavailable temporarily until restarted

Document created by RSA Customer Support Employee on Jun 5, 2017
Version 1Show Document
  • View in full screen mode

Article Content

Article Number000016776
Applies ToRSA Product Set: Key Manager (RKM)
RSA Product/Service Type: Server
RSA Version/Condition: 2.1.3.2
Platform: SafeNet LunaSA HSM 4.1
IssueRSA Key Manager (RKM) stops recognizing LunaSA HSM if the HSM becomes unavailable temporarily (due to a restart or network connectivity issues) until RKM is restarted.
The only solution seems to be manually restarting RKM to re-establish a session with LunaSA HSM.  LunaSA HSM configured to AutoActivate does not make a difference, though the HSM comes up with its Partition in active status and ready to service requests.
Until RKM is restarted (after LunaSA has become available after an outage/restart), the following exception is thrown:
16 Jul 2008 15:26:06,960 1216236366804 july7app (2) ERROR TP-Processor3 - function 'C_Decrypt' returns 0x8000001a
com.chrysalisits.crypto.LunaCryptokiException: function 'C_Decrypt' returns 0x8000001a
 at com.chrysalisits.crypto.LunaCryptokiException.ThrowNew(LunaCryptokiException.java:57)
 at com.chrysalisits.crypto.LunaAPI.Cipher(Native Method)
 at com.chrysalisits.cryptox.LunaCipher.engineDoFinal(LunaCipher.java:391)
 at com.chrysalisits.cryptox.LunaCipher.engineDoFinal(LunaCipher.java:305)
 at javax.crypto.Cipher.doFinal(DashoA12275)
 at edge.javax.crypto.DefaultCipher.doFinal(DefaultCipher.java:92)
 at com.rsa.keymanager.core.crypto.encrypt.DefaultCoreEncryptionEngine.run(DefaultCoreEncryptionEngine.java:71)
 at com.rsa.keymanager.core.crypto.encrypt.DefaultCoreEncryptionEngine.decrypt(DefaultCoreEncryptionEngine.java:45)
 at com.rsa.keymanager.core.crypto.encrypt.DefaultEncryptionEngine.decrypt(DefaultEncryptionEngine.java:17)
 at com.rsa.keymanager.core.crypto.encoded.DefaultEncodingEngine.decrypt(DefaultEncodingEngine.java:31)
 at com.rsa.keymanager.core.database.sql.hydrate.DefaultSecObjHydrator.decrypt(DefaultSecObjHydrator.java:100)
 at com.rsa.keymanager.core.database.sql.hydrate.DefaultSecObjHydrator.getVerifiableData(DefaultSecObjHydrator.java:89)
 at com.rsa.keymanager.core.database.sql.hydrate.DefaultSecObjHydrator.hydrate(DefaultSecObjHydrator.java:53)
 at com.rsa.keymanager.core.database.sql.hydrate.DefaultHydratorSqlBlock.hydrate(DefaultHydratorSqlBlock.java:13)
 at com.rsa.keymanager.core.database.sql.execute.DefaultSqlExecutor.executeQuery(DefaultSqlExecutor.java:79)
 at com.rsa.keymanager.core.database.sql.execute.DefaultSqlExecutor.query(DefaultSqlExecutor.java:31)
 at com.rsa.keymanager.core.natural.find.DefaultSecObjFinder.swizzle(DefaultSecObjFinder.java:53)
 at com.rsa.keymanager.core.natural.find.SecureSecObjFinder.swizzle(SecureSecObjFinder.java:20)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
....
 at com.rsa.keymanager.core.api.DefaultSimple.getKey(DefaultSimple.java:415)
 at com.rsa.keymanager.core.api.SecureSimple.getKey(SecureSimple.java:287)
 at com.rsa.keymanager.core.audit.AuditSimple.getKey(AuditSimple.java:374)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:585)
 at au.net.netstorm.boost.nursery.proxy.DefaultMethod.invoke(DefaultMethod.java:26)
 at com.rsa.keymanager.core.entry.LogLayer.invoke(LogLayer.java:42)
 at com.rsa.keymanager.core.entry.LogLayer.invoke(LogLayer.java:35)
 at au.net.netstorm.boost.util.proxy.LayerInvocationHandler.invoke(LayerInvocationHandler.java:20)
 at $Proxy5.getKey(Unknown Source)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:585)
 at au.net.netstorm.boost.nursery.proxy.DefaultMethod.invoke(DefaultMethod.java:26)
 at au.net.netstorm.boost.spider.onion.layer.passthrough.DefaultPassThroughLayer.invoke(DefaultPassThroughLayer.java:9)
 at au.net.netstorm.boost.util.proxy.LayerInvocationHandler.invoke(LayerInvocationHandler.java:20)
 at $Proxy5.getKey(Unknown Source)
 at com.rsa.keymanager.server.transport.wombat.core.DefaultWombatProvider.getByClass(DefaultWombatProvider.java:57)
 at com.rsa.keymanager.server.transport.wombat.core.DefaultWombatProvider.getByClass(DefaultWombatProvider.java:48)
 at com.rsa.keymanager.server.transport.wombat.core.DefaultWombatProvider.get(DefaultWombatProvider.java:27)
 at com.rsa.keymanager.server.transport.wombat.core.DefaultWombatKeyProvider.get(DefaultWombatKeyProvider.java:35)
 at com.rsa.keymanager.server.transport.wombat.core.DefaultWombatRequestHandler.tryProvideKey(DefaultWombatRequestHandler.java:36)
 at com.rsa.keymanager.server.transport.wombat.core.DefaultWombatRequestHandler.handle(DefaultWombatRequestHandler.java:29)
 at com.rsa.keymanager.server.transport.wombat.core.WombatServlet.handle(WombatServlet.java:19)
 at com.rsa.keymanager.server.transport.wombat.core.WombatServlet.get(WombatServlet.java:11)
 at com.rsa.keymanager.server.transport.core.servlet.EdgifierServlet.doGet(EdgifierServlet.java:67)
 at com.rsa.keymanager.server.transport.core.servlet.EdgifierServlet.doGet(EdgifierServlet.java:50)
....
CauseWhen LunaSA HSM is restarted, any active sessions are lost. Although on a restart HSM partition becomes active, client applications (in this case RKM) needs to re-authenticate.  This should be a non-issue if LunaSA High Availability (HA) group is configured and Luna Client / RKM is appropriately configured to use HA virtual card slot; in this scenario RKM should not need to re-authenticate.
ResolutionIn order to support auto-start on RKM in the above scenario, multiple LunaSA HSMs should be configured in a High Availability (HA) group, and RKM should be configured to use LunaSA HA virtual card slot.
Follow these steps to ensure optimal configuration of LunaSA HA and RKM for uninterrupted operations:
  1. Follow SafeNet documentation to install and configure multiple LunaSA HSMs in High Availability mode.
     
  2. If LunaSA HSM model is a PED (Trusted Path) Authentication version, that requires the Luna PED and PED Keys for authentication and access control, ensure that each Partition has Activate and AutoActivate options enabled.
     
  3. Follow SafeNet documentation to install and configure LunaSA Client (choose both CSP and JSP options) on the RKM box.  Ensure that the required SafeNet files are copied to the appropriate application server directories as mentioned in the RKM Server Installation Guide.
     
  4. Follow SafeNet documentation and use "vtl" utility on LunaSA Client to configure HA group and add Partitions from respective LunaSA HSMs participating in HA.  LunaSA Client configuration is saved in a file chrystoki.conf or crystoki.ini.
     
  5. After configuring LunaSA Client, ckdemo command can be run to get a slot list.  Here's an example output if two HSMs were setup in a HA group:
     
    Slots available:
    slot#1 - LunaNet Slot
    slot#2 - LunaNet Slot
    slot#3 - HA Virtual Card Slot

     
    Where, slot numbers 1 and 2 refer to physical slots on the two HSMs and slot number 3 refers to HA virtual card slot.  The HA slot is always the last one in the list. If one of the LunaSA HSMs become unavailable, the unavailable HSM slot is removed from the list and the HA virtual card slot is re-assigned.  For example, if Luna SA 2 in the above example became unavailable, the slot list would be as follows:
     
    Slots available:
    slot#1 - LunaNet Slot
    slot#2 - HA Virtual Card Slot

  6. 6. RKM Server uses a slot number in its configuration file, keyManagerServer.properties.  For example, the properties file may contain the following parameters using LunaSA HA slot:
    provider.profile=level1Sn
    provider.slot=3

     

    However, if one of the LunaSA HSMs became unavailable, the slot assignment for HA would change and RKM Server will not be able to connect to Luna SA.  Follow the next step to properly configure LunaSA Client and RKM.
     
  7. Configure LunaSA Client so that only the HA virtual card slot is available to the Client and hence to RKM Server. Luna SA Client can be configured using vtl utility to only show HA slots when retrieving slot list.  Use the following command on the Luna SA Client to do so:
    vtl haAdmin -HAOnly -enable

    The above command is available on LunaSA version 4.1.0 client and above.
     
  8. Configure RKM Server to use the only HA virtual card slot.  For example, keyManagerServer.properties file may contain the following provider configurations:
    provider.profile=level1Sn
    provider.slot=

Legacy Article IDa44706

Attachments

    Outcomes