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 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.
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.
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
Solution: Ask your certificate authority for a pkcs12 formatted file or individual certificates, or unpack the PKCS7 files manually with openssl
Solution: Recieve 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
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
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
Solution: Remove the expired cached copy of the intermediate certificate from the browsers 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.
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
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
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.
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:
1.4.2+ JRE on HPUX, Sun: Sun unrestricted JCE policy files
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.
LogLevel
to Debug
and
SSLTrace
in httpd.conf.