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: If using a level of GSKit that does not support pkcs7, ask your certificate authority for a pkcs12 formatted file or individual certificates.
Solution: Recieve certificate into the KDB that made original request or resubmit certificate request.
Solution: Rename jre/lib/ext/gskikm.jar
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.
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.
openssl pkcs12 -in 2048bit.p12 |openssl x509 -text|grep "Public Key"
Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (2048 bit)Solution: Install the appropriate JCE policy files for your JRE:
1.4.2+ JRE on HPUX, Sun: IBM
unrestricted JCE policy files
1.4.2+ JRE on AIX, Linux, WindowsSun unrestricted JCE policy
files
Sometimes no obvious "large" encyption key is visible in the PKCS12 file, but the unrestricted policy files still resolve this error
LogLevel
to Debug
and SSLTrace
in httpd.conf.