MustGather information for Certificate problems

The documentation required to diagnose problems with Cerificates includes

  1. Known issues to check first


    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

    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

    1. Download the Signer Certificate from your certificate authority
    2. Open your KDB, click "Signer Certificate", then "add".
    3. Enter a label and click "OK"
    4. Open the signer cert you just created, and check that the "Set the certifcate 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 certifcate

    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 recieiving 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 certficate with the matching SKI I

    Error importing pkcs7 (.p7b) file

    PKCS7 files are not supported by Ikeymn

    Solution: Ask your certificate authority for a pkcs12 formatted file or individual certificates, or unpack the PKCS7 files manually with openssl

    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: Recieve 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

    Solution: Ensure the JVM being used to run Ikeyman does not have a file named gskikm.jar under $JAVA_HOME/jre/lib/ext/. For IHS 6.0.x, this is in the _jvm subdirectory within the IHS installation directory. For IHS 6.1.x, this is in the java subdirectory within the IHS installation directory.

    Solution: Move jre/lib/ext/gskikm.jar out of the way

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

    1. For 32Bit IHS 6.1 on 64Bit platforms (Including z/Linux) this message is due to the fact that the 64Bit JDK is installed with IHS instead of the 32Bit version. See: Installation technote for the workaround.
    2. Ensure the JVM being used to run Ikeyman does not have a file named gskikm.jar under $JAVA_HOME/jre/lib/ext/. For IHS 6.0 and higher this is in the _jvm directory of the installation directory.

      Solution: Move jre/lib/ext/gskikm.jar out of the way

    3. Validate your 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
    4. 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

    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

    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

    Certificate contains malformed T.61 string
    A frequent problem with T.61 strings is the encoding of special characters like a dollar sign:

    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
    

    openssl asn1parse -in cert.arm -strparse 503

         Error in encoding 21005:error:0D07209B:asn1 encoding routines:ASN1_get_object:too long:asn1_lib.c:132:
    

    Solution: CA needs to recreate compliant certificate.
    Workaround: Set environment variable GSK_T61_AS_LATIN1=YES

    Unexpected security popup in some browsers

    If you're using an intermediate certificate (your server certificate isn't signed by one of a browsers' default trusted root certificate authorities mbut is signed by an issuer who is in turn signed by a trusted CA), web browsers can improperly cache expired copies of the intermediate certificates. This can occur if in the past the user has clicked 'Trust site permanently' on a site that uses the same intermediate certificate authority.

    Solution: Remove the expired cached copy of the intermediate certificate from the browsers SSL configuration.

    Client Authentication is enabled but browser doesn't prompt for certificate

    During the SSL handshake, the web server informs the browser of what Certificate Authorities it trusts to assist the browser in selecting the correct client certificate. If the browser detects that none of the user's client certificates would be validated given the list of certificate authorities sent by the server, the browser will NOT prompt the user for a certificate.

    If a subset of the user's client certificates can be validated by the servers list of certificate authorities, the browser will display that partial list of certificates to the user.

    Solution: The issuer of the client certificates must be added as a trusted Certificate Authority in the servers KeyFile.

    SSL0209E: SSL Handshake Failed, ERROR processing cryptography.

    If you're using PKCS11 crypto hardware (SSLPKCSDriver directive in httpd.conf), make sure that the user specified by the User directive is a member of the pkcs11 group

    SSL0223E: SSL Handshake Failed, No certificate.

    Verify at least 1 personal certificate exists in the specified KDB file. If 1 or more certificates exist, make sure either one is marked as default (asterisk appears next to label in ikeyman) or that httpd.conf contains an SSLServerCert directive for each virtual host with SSLEnable

    SSL0104S: GSK could not initialize, Invalid password for keyfile.

    For each KDB file IHS is configured to use, IHS will also try to open a file with the same file extension changed to .sth. If IHS cannot find, open, or read this file the above error will be reported.

    Solution: If the stash file does not exist, it can be created in Ikeyman

    Be sure the userid and group that IHS is configured to run under have read and execute access to every intermediate directory and to the .sth file itself.

    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:
    1.4.2+ JRE on AIX, Linux, Windows IBM unrestricted JCE policy files

    1.4.2+ JRE on HPUX, Sun: Sun unrestricted JCE policy files

    Error opening pkcs11 crypto token, or java crash in ikeyman while after selecting secondary KDB on z/Linux

    During configuration using the pkcsconf tool, some error messages may not have been noticed and the "user PIN" may not have been set after being initialized. The top of the javacore backtrace will look like:
    com.ibm.gsk.ikeyman.basic.CryptographicToken.c_BuildKeyLabelList(Native Method)

    The user PIN must be changed/set (pkcsconf -p) after being initialized (pkcsconf -u).

    Pay careful attention that no error messages are issued, in some cases the user PIN will not be able to be changed and must be re-initializedbefore being set again.

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

    1. Ikeyman problems

    2. Configure environment for Ikeyman trace
    3. Restart Ikeyman
    4. 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.
    5. Send the following to IBM support:
      • ikm*.log in working directory.
      • 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
    1. IHS startup or request processing problems

    2. Set LogLevel to Debug and SSLTracein httpd.conf.
    3. Configure environment for GSKit trace
    4. Restart IBM HTTP Server.
    5. Start an iptrace that will show the interaction between the web browser and web server. This can be taken from the IHS server, the client machine, or another machine on the network. (Possible tools include sniffer, Network Monitor, or Ethereal.)
    6. Recreate the problem from the browser.
    7. Save a screen capture of the browser window.
    8. Send the following to IBM support:
      • web server error log, access log, and httpd.conf
      • Output from system and web server information, from ihsdiag collector tool
      • GSKit trace file
      • If a client certificate is in use, please include it along with any necessary CAs
      • IP trace file, unformatted
      • KDB file in use along with accompanying .sth/.crl/.rdb files as well as KDB password
      • Detail on time of request/handshake and IP address of client
      • Description of client and server trust chain with Certificate Authority in use