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
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:
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: 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.
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:
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.
A file provided by the IBM JRE, gskikm.jar, can conflict with or mask GSKit maintenance applied alongside IHS. One clear sign of this problem is that the version reported in ikeyman differs from the version of GSKit installed on the system.
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, change the file extension or move it into a different directory.
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.
Solution: Move jre/lib/ext/gskikm.jar out of the ext/ directory (do not just rename the file)
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.
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.
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.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.
gsk7ikm
directly.
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
Continue on for another common cause of this error message
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.
$JAVA_HOME/lib/ext/gskikm.jar
to $JAVA_HOME/lib/ext/gskikm.bak
as described
here
If you cannot add a CA certificate using ikeyman, and you're sure it's not actually a duplicate, try adding
the CA with gsk7capicmd
to check if a different error code is issued.
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.
When validating a certificate, GSKit versions 7.0.4.1 and higher first converts the certificate to a BER encoding, the most detailed encoding of the certificate.
Another encoding, DER, is the more commonly used as a file format for certificates. It's also the mandatory format used as input to the certificate signing process. GSkit converts the BER into DER (it may or may not have started as DER) before checking that the alleged issuer really signed this certificate.
The DER encoding 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 the BER-encoded form instead of the DER-encoded form, GSKit signature validation will fail because the certificate authority has not created a proper signature for this particular certificate.
Most X509 certificate extensions have a "Criticality" field that defaults to off. The presence of this field with a value of FALSE, when the default value is FALSE, triggers the signature error discussed above.
$ dumpasn1 /tmp/pmr/certs/keysig-7c-vs-7d/3.der |grep -B1 -i false
623 3: OBJECT IDENTIFIER authorityKeyIdentifier (2 5 29 35) 628 1: BOOLEAN FALSE -- 659 3: OBJECT IDENTIFIER subjectKeyIdentifier (2 5 29 14) 664 1: BOOLEAN FALSE -- 710 3: OBJECT IDENTIFIER certificatePolicies (2 5 29 32) 715 1: BOOLEAN FALSE -- 960 3: OBJECT IDENTIFIER cRLDistributionPoints (2 5 29 31) 965 1: BOOLEAN FALSE
Contact your certificate authority and provide them the info above to re-issue your certificate
pkcsconf
tool, some error messages may not have
been noticed and the "user PIN" may not have been set after
being initialized. The PIN may also have been locked due to too many
failing password attempts.
If ikeyman crashes due to this issue, the top of the javacore backtrace will look like this:
com.ibm.gsk.ikeyman.basic.CryptographicToken.c_BuildKeyLabelList(Native Method)
The user PIN must be changed/set (pkcsconf
-p
) after being initialized (pkcsconf
-u
). If the user PIN is locked due too many incorrect passwords,
the token must be re-initialized (pkcsconf -I
)
Note: all examples assume the first token is being used, so each pkcsconf invocation contains "-c 0".
Run the following command in a terminal:
$ pkcsconf -t -c 0| grep Flags
If the output matches any of the following patterns, your PKCS11 token is not usable by IHS because it has not been configured properly.
output | explanation | action (see list below) |
---|---|---|
Flags: 0xnCnnnn | USER_PIN_LOCKED and USER_PIN_TO_BE_CHANGED | 3,4 |
Flags: 0xn8nnnn | USER_PIN_TO_BE_CHANGED | 4 |
Flags: 0xn4nnnn | USER_PIN_LOCKED | 3,4 |
Flags: 0xCnnnnn | SO_PIN_LOCKED and SO_PIN_TO_BE_CHANGED | 1,2,3,4 |
Flags: 0x8nnnnn | SO_PIN_TO_BE_CHANGED | 2 |
Flags: 0x4nnnnn | SO_PIN_LOCKED | 1,2,3,4 |
For more information about the Flag values see this file
Solutions (make sure these complete succesfully)
pkcsconf -I -c 0
pkcsconf -P -c 0
pkcsconf -u -c 0
pkcsconf -p -c 0
An example of a properly configured token is:
Flags: 0x44D
Examples of improperly configured token is:
Flags: 0x8044D
Flags: 0xC044D
Flags: 0xA044D
Verify the SSLServerCert
directive starts with the same "Label" as displayed by
pkcsconf -t
The file pointed to by the SSLStashFile
directive, created with the <ihsinst>/bin/sslstash utility,
does not contain the same password as the user PIN associated with the token indicated in SSLServerCert
directive.
Solution: Open your cryptographic token in ikeyman and verify the token name and label for your personal cert
match your SSLServerCert directive in httpd.conf. Use the <ihsinst>/bin/sslstash utility to re-stash the
User PIN to the file referenced by your SSLStashFile
directive.
You can query the cryptographic token on the command line, substituting your token label and password, with the command below. To be usable with IHS, you should have at least one result that has a private key (displayed with a dash in the first column)
Certificates found: * default, - has private key, ! trusted myca - mylabel
If no personal certificates exist, they must be created via ikeyman before IHS can use the crypto card.
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.
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.