Ikeyman

MustGather information for Ikeyman (and gsk7cmd) problems

Known issues to check first

        Certificate management error messages

•       "All the signer certificates must exist in the key database"
•       Intermediate certificate not in KDB
•       Subject/Authority key Identifier mismatch
•       "Error processing X509 certificates" (MUST check entire ertificate chain for all of these issues)
•       Null Subject/Issuer Alternate Name
•       Invalid T.61 String
•       Empty NameConstraints extension
•       Issuer does not exist in secondary key database while using  cryptographic accelerator
•       Empty User Notice extension
•       DSA key (invalid as key used in server certificate)
•       "An error occured while inserting keys to the database"
•       "Certificate request not found"
•       "The CMS Java native library was not found"
•       "The specified database has been corrupted" (Strong Encryption on PKCS12)
•       "The specified database has been corrupted" (Password is wrong)
•       "The database cannot be created or opened because permission was denied by the operating system"
•     If this message is seen while opening a PKCS11 cryptographic token:
•       Make sure the GSKit version is at least 7.0.4.14.
•       For IHS 6.1 and earlier, ensure the native GSKit Ikeyman is being used: removing gskikm.jar.
•     Otherwise, verify the KDB is writable by the user running ikeyman.
•       "Exception in thread "main" java.lang.NoClassDefFoundError: com/ibm/asn1/ASN1Exception"
•       "A duplicate certificate already exists in the database"
•       The certificate authority being added to the KDB may already exist with some other label
•      Ikeyman may be misreporting an obscure encoding error

Other certificate management symptoms

•    New private key only has 1023 bits instead of 1024 (or 2047 bits instead of 2048)

•    Can't start Ikeyman or it displays with blank screen controls

•    Java crash in ikeyman on z/Linux when PKCS11 token is being manipulated

•    Ikeyman reports wrong version

•    Ikeyman 8.0 Information

•    Ikeyman widgets perform unexpectedly

•    Error receiving/importing PKCS7(.p7b or arm) file

•    Cannot import certificate encrypted with a password that differs from keystore password

•    Duplicate certificate label for personal certificates

o    Command-line certificate management problems

•    gsk7cmd -certreq -list doesn't show some certificate requests

•    If a certificate request is recreated via the -certreq -recreate action in gsk7cmd or gsk7capicmd, it will not appear in the list of certificate requests.

•    Solution: The certificate remains in the Personal Certificates list only, and Ikeyman will still allow you to perform a receive operation on the renewal.

•    gsk7capicmd -cert -receive returns GSKKM_ERR_REQKEY_FOR_CERT_NULL

•    gsk7capicmd before version 7.0.4.20 cannot receive a certificate that was issued as a result of a a "renew" or "recreate request".

•    Solution: Use an identical command line but substitute gsk7cmd for gsk7capicmd

•    gskcmd returns 'Too many values for parameter '-dn' were specified:'

•    This is a JRE defect. Use gskcapicmd instead, or edit the "ikeycmd" script in your bundled JRE and add double-quotes around the last two characters in the script -- $@.

•    Cannot renew certificate with Verisign

•    Failure validating certificate issued by GPKI certificate authority

•    Adding certificates before they're valid

•    Hangs or delays using key management tools and vmware

Certificate FAQs

o    Why doesn't an imported personal certificate show up with "trust" status?

The tooling is in error, because trust status is never applicable to personal certificates (certificates with a private key). GSKit v8 will not show trust status on any personal certificates.

Unable to start Ikeyman

GSKit v5 Ikeyman doesn't start in Windows 2003

On Windows 2003, Ikeyman requires setting of the "Application Compatibility" flag:

1. Right click in the Ikeyman icon and select "Properties"

2. On the properties dialog select the "Compatibility" tab

3. In the "Compatibility mode" section of this tab tick the "Run this program

in compatibility mode for:" check box.

4. Select "Windows 95" from the resultant list box.

5. Press "OK" on the "Properties" dialog box

6. Run Ikeyman as normal

Ikeyman fails to load / crashes on PPC Linux

Solution: Ensure a 32-bit JRE is being used

Ikeyman displays with blank window controls on Windows XP

Note: Windows XP is not supported as a production system - only with limited support as a development system.

If you try to use Ikeyman on Windows XP and the window is displaying with blank controls, then you may be able to solve it using one of the following:

Possible Solution 1: 
(Ikeyman must be invoked from the Start menu for this to help. It won't help for invoking the ikeyman.bat from a command-prompt.)

1. Locate Ikeyman in the Start menu

   ('All Programs -> IBM HTTP Server V6.1 -> Start Key Management Utility')           

2. Right-click this entry and select "Properties"

3. On the properties dialog select the "Compatibility" tab

4. In the "Compatibility mode" section of this tab tick the

   "Run this program in compatibility mode for:" check box.

5. Select "Windows 2000" from the resultant list box.

6. Press "OK" on the "Properties" dialog box

7. Run Ikeyman as normal

     

Possible Solution 2:

There is also reported success with solving this by disabling DirectX features per: 
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6311320

Can't receive certificate in Ikeyman: All the signer certificates must exist in the key database

To receive a certificate, your KeyFile must be able to validate the new certificate all the way up to a trusted root in the signer certificate section of the KDB.

If your certificate was issued by a certificate authority that is not among the default trusted certificate authorities automatically included in new KDB files by ikeyman, you must add the certificate of the issuer (the signer) to your KDB before receiving your certificate

Adding the signer certificate

9.     Download the Signer Certificate from your certificate authority

10. Open your KDB, click "Signer Certificate", then "add".

11. Enter a label and click "OK"

12. Open the signer cert you just created, and check that the "Set the certificate as a trusted root" is checked

If ikeyman still issues the same error message when you try to receive your certificate, use the following procedure to verify that the signer certificate is the same as the one that actually signed your certificate

openssl x509 -text -in certificate_from_certificateauthority.crt|grep Issuer: 
openssl x509 -text -in signer_certificate.cer |grep Subject: 

If the output of the two commands isn't the same distinguished name, you are either using the wrong signer certificate or your certificate is signed using an intermediate certificate.

Intermediate Certificates

Some certificate authorities issue certificates that are signed by an intermediate issuer, and not one of the default trusted root CA certificates that are pre-loaded into your KDB. Your certificate authority should provide any intermediate certificates required to build the trust chain and you must add them to your KDB before receiving your signed certificate.

Solution: To add the correct intermediate certificate(s), download all intermediate certificates from your certificate authority. Perform the steps outlined here for each certificate starting from the root CA and ending with the signer certificate that issued your certificate.

Subject/Authority key identifier mismatch (Microsoft CA)

If the certificate you are trying to receive or add contains an Authority Key Identifier (AKI), the issuer of this certificate in your KDB must have a Subject Key Identifier (SKI) with the same value.

The AKI/SKI can be an arbitrary binary value, or a combination of the issuers DN and Serial Number.

Both intermediate and end-entity certificates may contain an AKI.

openssl x509 -in intermediate.crt -text|grep -C1 "X509v3 Authority Key Identifier:" &&openssl x509 -in root.crt -text|grep -C1 "X509v3 Subject Key Identifier:"

                X509v3 Authority Key Identifier:

                keyid:7B:58:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX

                X509v3 Subject Key Identifier:

                keyid:4A:D3:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX

 

Solution: Contact certificate authority for the proper version (possible Serial Number bump) of the issuer certificate with the matching SKI.

Ikeyman: An error occurred while inserting keys to the database

Solution: This can occur when importing from a PKCS12 or CMS key file, onto a CMS Cryptographic Token. It is resolved by upgrading GSKit to at least 7.0.3.27 and removing gskikm.jar for IHS 6.1 and earlier.

If upgrading and removing gskikm.jar does not resolve the issue, adding the private key and signer certificates in separate steps can sometimes workaround the issue:

13. Verify your unrestricted JCE policy files are installed

14. Make a copy of the PKCS12 file, privkey.p12, and open the copy in ikeyman.

15. Select "Signer Certificates" and "extract" each signer certificate necessary for your personal certificate into a file.

16. Remove each signer certificate from the PKCS12 file.

17. Close the PKCS12 file.

18. Open the CMS Cryptographic Token in ikeyman and choose the applicable secondary CMS key database.

19. Select "Signer Certificates" and "add" each extracted signer certificate.

20. Select "Personal Certificates" and "import" from your privkey.p12

Ikeyman: Certificate Request Not Found

Certificates can only be received into the KDB where the request was originally created. Attempting to duplicate the parameters of a previously submitted certificate request in a new KDB will not allow you to receive the certificate in the new KDB..

Solution: Receive certificate into the KDB that made original request or resubmit certificate request.

Ikeyman widgets perform unexpectedly

It has been reported that ikeyman sometimes performs erratically when it is displayed on the PC X11 Server distributed by Exceed. The behavior is not seen when used with XFree86/Xorg X11 servers running natively or under Cygwin, and is also not seen when being run in a VNC server running on the IHS system.

Reported Symptom: When selecting a country name from the selection box, the select box may be reset to default (US)

Solution: Display ikeyman on a different X11 server, or contact X11 server vendor.

Ikeyman: Wrong version reported in "About" dialogue

In IHS 7.0 and earlier, the bundled java's gskikm.jar provides a different level of Ikeyman than what's bundled with GSKit. This can cause differences in the version numbers reported between the java-based certificate management tools and the native GSKit and IHS runtimes.

In IHS 6.1 and earlier, a manual post-install configuration step is required to setup IHS to use the proper (up to date) certificate management implementation. See #GSKIKM for instructions.

In IHS 7.0, leaving gskikm.jar in place causes a more up to date Ikeyman and gsk7cmd to be used (v8). To revert to the legacy Ikeyman 7.0 with IHS 7.0, see #GSKIKM.

Ikeyman 8.0 in IHS 7.0

oIkeyman 8.0 is used in IHS 7.0 when $IHSROOT/java/jre/lib/ext/gskikm.jar is present.

oWhen IHS 7.0 has been setup to use Ikeyman 8.0 as described above, $IHSROOT/bin/gsk7cmd also uses the updated codebase.

oWith IHS 7.0, only Ikeyman 8.0 is supported on Solaris or HP-UX.

oAuthoritative documentation for Ikeyman 8.0 is available here

oInformation on the PKCS11 configuration used by Ikeyman v8 in IHS 7.0 is available here

removing gskikm.jar to use GSKit-provided Ikeyman

A file provided by the IBM JRE, gskikm.jar, can override the version of Ikeyman, which would otherwise be dictated by the level of GSKit maintenance applied alongside IHS.

Solution: Ensure the JVM being used to run Ikeyman does not have a file named gskikm.jar under $JAVA_HOME/jre/lib/ext/. If this file exists move it into a different directory (changing the filename alone is not sufficient).

o    For IHS 6.0.x, this is in the _jvm subdirectory within the IHS installation directory.

o    For IHS 6.1.x and later, this is in the java subdirectory within the IHS installation directory, and the file should always be moved.

o    For IHS 7.0, the file must not be moved on Solaris and HP-UX, but may optionally be removed to use the legacy v7 certificate management on other operating systems.

                        IHS runtime reports wrong GSKit level

On windows, a stray gsk7*.dll in the C:\Windows\system32 can cause IHS to report (and use) the wrong GSKit level at startup. No GSKit files should be present in this directory.

                        Ikeyman: Can't create CMS key database, error loading native CMS library

o    IHS 7.0 before 7.0.0.5 can report this error when installed from the 64-bit supplement CDs, because of a mismatch between the architecture of the bundled Java and the architecture of the bundled GSKit.

This is resolved automatically at version 7.0.0.5 and later.

o    IHS 6.1.0.11 and earlier, installed from 64-bit WebSphere images (including images for 64-bit Linux and Windows), cannot create CMS key databases because the bundled 64-bit JRE cannot properly load the 32-bit GSKit CMS native library.

This problem is corrected in IHS 6.1.0.13 and later, where both a 32-bit and 64-bit GSKit are installed on 64-bit platforms. The updated ikeyman script will choose the appropriate version of GSKit to run based on the architecture of the JRE found at runtime.

o    If the following message in the console accompanies the CMS native library error while runnning gsk7cmd or ikeyman:

"The library initialization routine was not successfully called."

  Update the JRE bundled with IHS to the latest level (Using the latest WASSDK fixpack)

  Remove gskikm.jar after the update, mv IHSROOT/java/jre/lib/ext/gskikm.jar IHSROOT/lib

This symptom has been observed in IHS 7.0 with GSkit 7.0.4.27 on AIX.

o    IHS 6.1 and earlier: Ensure the JVM being used to run Ikeyman does not have a file named gskikm.jar under $JAVA_HOME/jre/lib/ext/. See removing gskikm.jar.

o    All releases prior to 7.0: Validate your global GSKit installation

  IHS 2.0.42 on PPC Linux: Ensure /usr/lib/libgsk6cms.so exists and is a valid symlink

  IHS 2.0.42: Ensure /usr/lib/libgsk5cms.so exists and is a valid symlink

  IHS 1.3.28/2.0.47 on IA32 Linux: Ensure /usr/lib/libgsk7cms_gcc295.so exists and is a valid symlink

  IHS 1.3.28, 2.0.47, 6.0, 6.1: Ensure /usr/lib/libgsk7cms.so exists and is a valid symlink

o    Linux: Make sure RPM compat-libstdc++ is installed (ldd `which gsk7ver` should not be missing any libraries)

Solution: install compat-libstdc++ which provides libstdc++.so.5

                        New private key only has 1023 bits instead of 1024 (or 2047 bits instead of 2048)

                        A defect in older levels of Java causes ikeyman to create new certificates with a 1023 bit private key instead of a 1024 private bit key.

                        If the procedure in the following technote has been followed to enable 2048 bit keys for v6.0, then this same problem can cause the key to be 2047 bit insetad of 2048: 
The iKeyman utility within IBM HTTP Server V6.0 does not provide the option to create a certificate request (CSR) 2048 key size

                        Solutions:

o    For levels prior to IHS 6.0, the system JRE (based on JAVA_HOME environment variable) is used for key management. Upgrade to the latest service release of IBM Java 1.4.2 or 1.5 
{Note: IHS 6.0 uses a bundled Java that cannot be upgraded}

o    Install IHS 6.1 or later on any supported OS + a recent WASSDK fixpack (to update the java), and use that system for key management.

o    Use gsk7capicmd to create the certificate request since it doesn't have a Java dependency.

Error received during import/receive: "Error processing X509 certificate"

This error is typically seen in Ikeyman when one or more X509 extensions present in the certificate are malformed. Some common errors follow.

If your certificate is part of an existing key database, you can extract the certificate with the following command. Otherwise, you can analyze your certificate directly.

gsk7cmd -cert -extract -label label -db key.kdb -pw abc123 -format ascii -target cert.arm

Causes:

o    Stray newlines in CA certificate file

View the certificate you're trying to add in a text editor. Some versions of Java will reject your certificate if there is whitespace or newlines before or after the "-----BEGIN CERTIFICATE-----" or "-----END CERTIFICATE-----" separators.

In ikmtrace.log (or debugTrace*)(ikeyman -x output), the Java exception looks like:

<KeyStoreManager::addCACertificate 9999-4, CertificateException=java.security.cert.CertificateException: Unable to initialize, java.io.EOFException

o    IssuerAltName/SubjectAltName is present but value is null

Use the openssl command line tool to view the extension in question:

openssl x509 -in cert.arm -noout -text|grep -C1 EMPTY

            X509v3 Issuer Alternative Name:

            <EMPTY>

 

Solution: CA needs to recreate compliant certificate

o    Certificate contains malformed T.61 string

A frequent problem with T.61 strings is the encoding of anything but the most basic of non US-ASCII characters, including symbols like a dollar sign ('$') or hash mark ('#') or anything with the "high order bit" set:

Use openssl command line tool to view the ASN.1 structures:

openssl asn1parse -in cert.arm | grep T61

      503:d=5  hl=2 l=  23 prim: T61STRING         :MyCA $50 Warranty

In this second example, the cert has some non US-ASCII bytes in a certificate field, any unprintable output in the first command, or any output at all in the second, is a sign to try the workaround below:

$ openssl asn1parse -in clientcert.arm | egrep 'T61'

  223:d=5  hl=2 l=  14 prim: T61STRING         :Testbruger ���

$ openssl asn1parse -in clientcert.arm | egrep 'T61'|od -t x1|egrep '[89abcdef][0-9a-zA-Z]'

0000060 54 65 73 74 62 72 75 67 65 72 20 e6 f8 e5 0a

Solution: CA needs to recreate compliant certificate; note that RFC3280 deprecates the use of T61String in new certificates.

Workaround: Set environment variable GSK_T61_AS_LATIN1=YES in <ihsinst>/bin/envvars

o    Invalid NameConstraints extension

The NameConstraints extension must not be empty, or Java will reject the certificate.

  Find the offset of the extension

openssl asn1parse  -in CA.cer  | grep :2.5.29.30 | awk -F: '{print $1}'

If there's no output, the certificate doesn't have this bug.

  Find the value of the extension using the offset from the first step (a decimal number)

 openssl asn1parse -in CA.cer -strparse number

  If there's no output, the certificate is invalid and must be fixed by the customer.

o    Import, or receive of a personal certificate, complains about dupliate [signer] certificates

The *.cer sent by your certificate authority is normally a single X509 certificate, but some issuers provide what amounts to an entire keyring embedded in the *.cer and ikeyman cannot use this directly. This format is not fully supported by GSKit.

If openssl x509 -in certificate.cer -text produces an error message but openssl pkcs7 -print_certs < certificate.cer does not, then you have a PKCS7 file.

The output of the previous command lists a series of certificates. Find the certificate you requested by looking for a line beginning with "subject=" and containing the Distinguished Name you specified at certificate request time.

  For Ikeyman 8 and later, the PKCS7 can be "received" in a single operation.

  For Ikeyman 7.0.4.14 and later, the PKCS7 can be "received" in a single operation if there is no overlap between the CA certificates in the PKCS7 and the KDB.

  For older versions of Ikeyman, or whenever other PKCS7 limitations arise, consult the steps below.

Copy everything between (and including) the "-----BEGIN CERTIFICATE-----" and "-----END CERTIFICATE-----" markers into a new file (certN.arm), and make sure your file begins and ends with these markers and includes no additional blank lines.

  For each signer certificate in the PKCS7 file that doesn't exist in your KDB, "add" the certN.arm to your KDB.

  For your requested certificate, "receive" the certN.arm into your KDB.

o    Empty User Notice extension

If the User Notice field of the Certificate Policies extension is an empty sequence, the level of Java in the base IHS 6.1.0.0 install will throw an exception during certificate management.

$ openssl x509 -in failing.arm -text | grep -C1 "User Notice:"

                  CPS: 1.2.4.5.5

                  User Notice:

                  ^^^^^^^^^^^^^^^ whitespace

$ dumpasn1 failing.der | grep -A2 unotice

 686    8:                     OBJECT IDENTIFIER unotice (1 3 6 1 5 5 7 2 2)

 696    0:                     SEQUENCE {}

                               ^^^^^^^^^^^ empty sequence

Solution: Upgrading the bundled JRE to latest available SDK maintenance will fix the problem.

6.1 release

Download the "Java SDK" fix pack for the current fix pack release (example name: 6.1.0-WS-WASSDK-AixPPC32-FP0000017) and use the Update Installer to apply it to the IBM HTTP Server installation just as you would for an IBM HTTP Server fix pack.

6.0 release

The bundled Java for this IBM HTTP Server release cannot be updated. Set JAVA_HOME to point to a recent WebSphere-provided level of the JDK and run gsk7ikm directly.

o    DSA key used in server certificate

When software other than ikeyman is used to create a certificate or certificate request, the servers certificate may use a DSA key instead of an RSA key. DSA keys are not supported as server certificates.

When such a certificate is selected for an SSL handshake, IHS issues the following message:

SSL0210E: SSL Handshake Failed, ERROR validating ASN fields in certificate.

openssl x509 -in cert.arm -text|grep "Public Key Algorithm"

            Public Key Algorithm: dsaEncryption

                                  ^^^

To check In ikeyman, select the detailed view of the personal certificate and find the "Subject Public Key Information" field. A value of OID 1.2.840.10040.4.1 signifies a DSA public key.

Solution: Create a new certificate request, either using ikeyman or forcing the use of an RSA key.

Issuer does not exist in secondary key database while using cryptographic accelerator

When cryptographic hardware is in use, iKeyman will sometimes report "Error processing X509 certificate" instead of "All the signer certificates must exist in the key database" when the issuer of a certificate you're receiving is not present in your secondary key file.

Verify the issuer of the certificate you're trying to receive exists in the "Signer Certificates" section in iKeyman

Ikeyman: The specified database has been corrupted (Strong Encryption).

Often PKCS12 files (or other Key Databases) use strong encryption that is not available in the default JCE policy files provided by java.

To test if the cryptography level in your PKCS12 file exceeds the JCE defaults, use the keytool command supplied in your JRE:

keytool -list -v -keystore /tmp/your.p12 -storetype pkcs12 -storepass password

        ... Unsupported keysize or algorithm parameters

Solution: Install the appropriate JCE policy files for your JRE:
Java 5 on all platforms, or Java 1.4.2 on AIX, Linux, Windows IBM unrestricted JCE policy files

Java 1.4.2 on HPUX, Solaris: Sun unrestricted JCE policy files

Continue on for another common cause of this error message

Ikeyman: The specified database has been corrupted

Outside of PCKS12 keystores, the most common cause of this message is using an incorrect password. If IHS can service SSL requests (even if clients terminate the handshake due to an expired individual certificate) with the KDB, that means the KDB is not corrupt and the password being provided does not matched the stashed password.

gsk7cmd reports: "Exception in thread "main" java.lang.NoClassDefFoundError: com/ibm/asn1/ASN1Exception"

Solution: Rename $JAVA_HOME/lib/ext/gskikm.jar to $JAVA_HOME/lib/ext/gskikm.bak as described here

erroneously reported "A duplicate certificate already exists in the database"

If you cannot add a CA certificate using ikeyman, and you're sure it's not actually a duplicate, try adding the CA withgsk7capicmd to check if a different error code is issued.

gsk7capicmd -cert -add -db key.kdb -pw YOURPASSWORD -file your_issuer.arm -label myca

If the error reported by gsk7capicmd is GSKKM_ERR_VALIDATION_KEY_SIGNATURE, and you're using GSKit 7.0.4.1 or higher, see DER encoding error below.

Certificate validation failures with GSKit 7.0.4.1 and higher

When validating a certificate, GSKit versions 7.0.3.22 and higher first converts the certificate to a BER encoding, the most detailed encoding of the certificate, and then into the ubiquitous DER form. CA issuers calculate certificate signatures over the DER encoding. GSKit always sends this calculated DER-encoding of the certificate to the client.

The DER specification dictates that default values must not be present in the DER-encoded representation. If a certificate uses an illegally constructed DER, or if the certificate authority has signed either the BER-encoded form or a malformed DER-encoded form, the following may occur:

o    GSKit may fail to verify the signature on the true DER encoding of the certificate.

o    Clients may fail to verify the signature on the true DER encoding of the certificate as presented by GSKit, because the cryptographically secure signature does not match the true DER encoding.

o    In a mixed environment with old and new levels of GSKit (before/after 7.0.3.22), slightly different DER encodings of the same certificate may be sent to the client.

Any extension in a certificate may contain an element of a sequence with a default value. If a DER-encoded certificate contains such default values explicitly listed in the certificate, the signature is likely to be incorrect and the incompatabilities listed above are likely to arise.

A common example is the "criticality" field present in each certificate extension, which immediately follows the specific extension type in the ASN.1 encoding. This field defaults to FALSE (0), and should never appear with a value of '0' in a proper DER encoding. The definition of the structure of each certificate extension is included below:

Extension ::= SEQUENCE {

        extnId  EXTENSION.&id ({ExtensionSet}),

        critical BOOLEAN DEFAULT FALSE,

        extnValue OCTET STRING

                -- contains a DER encoding of a value of type &ExtnType

                -- for the extension object identified by extnId

}

In the example below of an invalid DER encoding, the beginning "SEQUENCE" marks a new certificateExtenson whose first field is the id of a particular extension (formatted for us by openssl below as "X509v3 Basic Constraints") and whose second field is a boolean with a default of false. A proper DER encoding, and thus a proper signature value, would not include the "BOOLEAN" line with a value of 0 below:

$ openssl asn1parse -in /tmp/pmrs/ok-ca.cer|grep -B1 'BOOLEAN :0'

  507:d=4  hl=2 l=  15 cons: SEQUENCE         

  509:d=5  hl=2 l=   3 prim: OBJECT            :X509v3 Basic Constraints

  514:d=5  hl=2 l=   1 prim: BOOLEAN           :0   <--- criticality field, should not be present, or part of signature, in DER form

  517:d=5  hl=2 l=   5 prim: OCTET STRING      [HEX DUMP]:30030101FF

Each extension must be checked against its definition in the OID database, as there are also extension-specific fields which may contain default-valued fields that must NOT be encoded with their default values.

Solution

Contact your certificate authority and provide them the info above to re-issue your certificate (or CA, depending on which is invalid). No workaround or circumvention is possible as improper DER encoding causes invalid cryptographically secure signatures which various software will need to check. If client software complains about re-use of serial numbers or other unusual certificate errors, some relief may be provided if you move to an environment where all HTTP Servers use 7.0.3.22 or later.

Cannot import certificate encrypted with a password that differs from keystore password

Some non-GSKit certificate management utilities allow you to create private keys with one password and store them in a keystore with a different password. In GSKit utilities, it is assumed the private key and keystore password are the same.

If you try to import a personal certificate of this type, GSKit will report that the private key is corrupted or unsupported, because it tries to decrypt it with the keystore password.

The only known workaround is to use whatever native tool created the keystore and change the passwords.

Duplicate certificate label for personal certificates

In IBM HTTP Server v7 or later, the Ikeyman v8 bundled with java lists some personal certificates twice. This will be fixed in future JSSE maintenance. In the interim, backing up then removing the key.rdb request database will remove the GUI abnormality.

There is no functional problem when the personal certificate label is duplicated.

Cannot renew Verisign certificate

When issuing a certificate, Verisign may add custom text to the Distinguished Name of the requested certificate in several Organizational Unit (OU) fields. When you renew this certificate via ikeyman, the Certificate Signing Request (CSR) will include the additional OU fields originally added by Verisign.

Verisign may reject the CSR because it already explicitly contains the Verisign OU.

Solution: Create a new certificate signing request instead of clicking "renew" in Ikeyman.

Failure validating certificate issued by GPKI certificate authority

GPKI is an SSL certificate standard published by the government of Japan that deviates from the two standards supported by IHS and the Tivoli Global Security Kit (GSKit). One such deviation that does not pass validation is an issuer chain with both a critical "Certificate Policies" (or any other RFC3280-specific) extension and a non-critical "Basic Constraints" extension

The presence of an RFC3280-specific critical extension (e.g. Certificate Policies) anywhere in the validation chain forces GSKit to validate the certificate using RFC3280/PKIX rules, however PKIX rules state that issuer certificates MUST set the "Basic Constraints" extension as critical. These certificates fail validation. IHS 6.1.0.9 and later can support this specific deviation in otherwise RFC3280-compliant GPKI issuer certificates with the directiveSSLAllowNonCriticalBasicConstraints.

To determine if SSLAllowNonCriticalBasicConstraints is required for a specific server or client certificate, inspect the fields in each Certificate Authority (including intermediates) and look for BOTH of the following in the validation chain:

o    Any non end-entity (i.e. Signer/Issuer) certificate with the Basic Constraints field NOT marked critical

o    Any certificate with a field new in RFC3280 that is marked critical, e.g. Certificate Policies.

Example Configuration:

<VirtualHost *:443>

SSLEnable

SSLAllowNonCriticalBasicConstraints on

</VirtualHost>

Adding certificates before they're valid

If an end-entity or issuer certificate is created with its beginning validity date in the future, it cannot be added to a KeyFile via ikeyman.

o    If the validity date is a short amount of time in the future due to differences in system time, as opposed to being intentionally post-dated, wait until the time on the ikeyman system "catches up" to the time on the system where the certificate was issued.

o    If the certificate's validity date is far in the future, consider re-issueing the certificate with the current date.

o    If the certificate cannot be re-issued with the current date within the validity range, wait until the certificate is valid to add it to your KeyFile.

o    If you cannot wait until the validity date to add the certificate to your KeyFile, copy the KeyFile to a workstation where the system date can be set to a date within the certificate's validity range and add the certificate on that system.

When the issuer or end-entity certificate becomes valid, IHS will not begin to use it until IHS has been restarted within the validity range.

Hangs or delays using key management tools and VMware

On systems running inside of VMware, ikeyman and related tools can encounter a shortage of random data and appear to hang after many certificate operations.

Solution: Perform complicated key management tasks on a native platform or retry with the following VMware configuration option set to 'false'

monitor_control.virtual_rdtsc

                        Gathering documentation for IHS support when problem is not a known issue

Ikeyman problems

0.     IHS 6.1 and later support a "-x" flag to ikeyman to collect traces. IHS 6.1 writes them to your working directory, and IHS 7.0 and later write them to /tmp.

1.     Restart Ikeyman with <ihsroot>/bin/ikeyman -x

2.     Recreate the problem and record the exact steps you take as well as the difference in expected/observed results into a text file (steps.txt). Append the KDB password to the list of steps.

3.     IHS 6.1 and earlier: Collect $PWD/ikm* $PWD/jnitrace*

4.     IHS 7.0 and later : Collect /tmp/ikeyman*, /tmp/ikm* (Ikeyman v7 only), /tmp/jnitrace*, and /tmp/debugTrace*(Replaces /tmp/ikm* in Ikeyman v8).

5.     If you also get unexpected output with gsk7capicmd, set the native environment variable GSKCAPICMD_TRACE_FILE=/tmp/gskcapicmd.trc and reproduce your issue.

6.     Send the following to IBM support:

  The version-specific Ikeyman logs described above

  If applicable, the output of gsk7capicmd (gskcapicmd) as well as its resulting trace file.

  KDB file in use along with accompanying .sth/.crl/.rdb files.

  steps.txt, which contains the steps and expected/observed results as well as the KDB password.

  httpd.conf

  Any intermediate certificate provided by Certificate Authority

  Details of cryptographic token configuration described above (pkcsconf output), when appropriate.