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
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
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.
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.
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 I
Solution: Ask your certificate authority for a pkcs12 formatted file or individual certificates, or unpack the PKCS7 files manually with openssl
Solution: Receive certificate into the KDB that made original request or resubmit certificate request.
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.
Solution: Move jre/lib/ext/gskikm.jar out of the way
Solution: Move jre/lib/ext/gskikm.jar out of the way
Solution: install compat-libstdc++ which provides libstdc++.so.5
Solution: 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
Alternatively, install IHS 6.1 on any supported OS and use that system for key management.
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
openssl x509 -in cert.arm -noout -text|grep -C1
EMPTY
X509v3 Issuer Alternative Name: <EMPTY>
Solution: CA needs to recreate compliant certificate
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
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
The NameConstraints extension must not be empty, or Java will reject the certificate.
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.
openssl asn1parse -in CA.cer -strparse number
If openssl x509 -in certificate.cer -text
produces an error message but
openssl pkcs7 -in certificate.cer -print_certs
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.
Copy everything between (and including) the "-----BEGIN CERTIFICATE-----" and "-----END CERTIFICATE-----" markers into a new file, and make sure your file begins and ends with these markers and includes no additional blank lines. This file can be "received" into ikeyman.
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
Solution: Remove the expired cached copy of the intermediate certificate from the browser's SSL configuration.
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.
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 parametersSolution: Install the appropriate JCE policy files for your JRE:
Java 1.4.2 on HPUX, Solaris: Sun unrestricted JCE policy files
$JAVA_HOME/lib/ext/gskikm.jar
to $JAVA_HOME/lib/ext/gskikm.bak
as described
here
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
).
Make sure pkcsconf -t
doesn't report USER_PIN_TO_BE_CHANGED for the slot in question
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-initialized before being set again.
See the following redbook: Using Cryptographic Adapters for Web Servers with Linux on IBM System z9 and zSeries
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.
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 directive SSLAllowNonCriticalBasicConstraints
.
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:
Example Configuration:
<VirtualHost *:443> SSLEnable SSLAllowNonCriticalBasicConstraints on </VirtualHost>
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.
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.
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
LogLevel
to Debug
and
SSLTrace
in httpd.conf.