Cryptographic accelerator Questions and Answers

How can IBM HTTP Server be used with CoolThreads/Niagra/UltraSparc servers from Sun Microsystems?

See this whitepaper (alternate link) from Sun Microsystems for detailed analysis and administrative steps. Configuring RSA offload via the PKCS#11 interface is critical to achieve good SSL performance on this platform.

Threaded applications such as IBM HTTP Server may see a dramatic SSL handshake performance degradationwhen using the RSA offload capabilities of the Niagra platform. Customers encountering slow PKCS#11 performane should work with oracle to ensure they have all applicable fixes for multi-threaded applications using the PKCS#11 driver.

When the software token described in the whitepaper above is used, the Niagra PKCS#11 driver will also default to doing many other cryptographic operations in software instead of using the coprocessors. Information on disabling these mechanisms in the software-based driver are discussed in section 4 here.

Some users have reported importing of existing keys is difficult in this environment. We recommend using Ikeyman to convert any pre-existing keys to PKCS12 format, then using the native Solaris tools (pk12util, pktool) to perform any interaction with the cryptographic token.

What cryptographic hardware is supported with IBM HTTP Server?

The hardware listed here is supported by the Tivoli Global Security Kit (GSKit) library used by IBM HTTP Server. This DeveloperWorks article is the most up to date and authoritative source of information.

Why does my PKCS11 token routinely get erased?

Consult your enterprise Linux vendor for an updated opencryptoki library to fix this truncation of the soft-token.

How can I tell if my PKCS11 token is ready to be used by IBM HTTP Server?

Detecting an improperly initialized cryptographic token

Note: all examples assume the first token is being used, so each pkcsconf invocation contains "-c 0".

Run the following command in a terminal:

$ pkcsconf -t -c 0| grep Flags

If the output matches any of the following patterns, your PKCS11 token is not usable by IHS because it has not been configured properly.

outputexplanationaction (see list below)
Flags: 0xnCnnnn USER_PIN_LOCKED and USER_PIN_TO_BE_CHANGED 3,4
Flags: 0xn8nnnn USER_PIN_TO_BE_CHANGED4
Flags: 0xn4nnnn USER_PIN_LOCKED3,4
Flags: 0xCnnnnn SO_PIN_LOCKED and SO_PIN_TO_BE_CHANGED1,2,3,4
Flags: 0x8nnnnn SO_PIN_TO_BE_CHANGED 2
Flags: 0x4nnnnn SO_PIN_LOCKED 1,2,3,4

For more information about the Flag values see this file

Solutions (make sure these complete succesfully)

  1. To correct SO_PIN_LOCKED, contact a system administrator and have them run: (Note: This may destroy corresponding personal certificates)
    pkcsconf -I -c 0
  2. To correct SO_PIN_TO_BE_CHANGED, change (set) the Security Officer PIN:
    pkcsconf -P -c 0
  3. To correct USER_PIN_LOCKED, contact a system administrator or initialize the user PIN (may destroy corresponding personal certificates):
    pkcsconf -u -c 0
  4. To correct USER_PIN_TO_BE_CHANGED, change (set) the user PIN:
    pkcsconf -p -c 0
    Note: Solution 2 uses a upper case 'P' and solution 4 uses an lower case 'p'.

An example of a properly configured token is:

Flags: 0x44D

Examples of improperly configured token is:

Why doesn't IHS 7.0 recognize the certificates stored on my cryptographic device?

If the mandatory configuration steps to use Ikeyman with IBM HTTP Server are not followed, personal certificates created/imported onto cryptographic devices will not be usable with the IBM HTTP Server runtime.

Note that it is never sufficient to just rename java/jre/lib/ext/gskikm.jar to any other filename in the java/jre/lib/ext/ directory.

If java/jre/lib/ext/gskikm.jar has been renamed properly, the Help/About menu in Ikeyman will report a version beginning with "7".

The symptom of creating a personal certificate without performing the configuration is the following error message for each handshake: SSL0227E: SSL Handshake Failed, Specified label could not be found in the key file

What cryptographic operations does IHS offload when configured with SSLPKCSDriver?

IHS offloads RSA cryptographic operations (assymetric operations) when configured with SSLPKCSDriver, if supported by the cryptographic hardware.

IHS 6.0.2.39, 6.1.0.29, 7.0.0.0 and later can be configured to offload symmetric crypto operations (e.g. DES, RC4, AES), if the crypgoraphic hardware supports it, with the following configuration in the SSLEnabled virtual host:

 
# Symmetric offload
SSLAttributeSet 417 549

Why does z/Linux crypto offload not work in SLES11 SP1?

Maintenance from Novell is required to use crypto offload on this OS after SP1. Contact Novell for a fix for bugzilla #643843 and #582774