Troubleshooting certificate store and key database problems

Use the following table to help you troubleshoot some of the more common certificate store and key database problems you may encounter while working with Digital Certificate Manager (DCM).

Problem Possible Solution
The system has not found the key database, or has found it to be invalid. Check your password and file name for typographical errors. Be sure that the path is included with the file name, including the leading forward slash.
Key database creation failed or Create a local CA creation fails. Check for a file name conflict. The conflict may exist in a different file than the one for which you asked. DCM attempts to protect user data in the directories that it creates, even if those files keep DCM from successfully creating files when it needs to.
Resolve this by copying all of the conflicting files to a different directory and, if possible, use DCM functions to delete the corresponding files. If you cannot use DCM to accomplish this, manually delete the files from the original integrated file system directory where they were conflicting with DCM. Ensure that you record exactly which files you move and where you move them. The copies allow you to recover the files if you find that you still need them. You need to create a new local CA after moving the following files:
/QIBM/USERDATA/ICSS/CERT/CERTAUTH/DEFAULT.KDB
/QIBM/USERDATA/ICSS/CERT/CERTAUTH/DEFAULT.TEMP.KDB
/QIBM/USERDATA/ICSS/CERT/CERTAUTH/DEFAULT.RDB
/QIBM/USERDATA/ICSS/CERT/CERTAUTH/DEFAULT.STH
/QIBM/USERDATA/ICSS/CERT/CERTAUTH/DEFAULT.STH .OLD
/QIBM/USERDATA/ICSS/CERT/CERTAUTH/DEFAULT.KYR
/QIBM/USERDATA/ICSS/CERT/CERTAUTH/DEFAULT.POL
/QIBM/USERDATA/ICSS/CERT/CERTAUTH/DEFAULT.BAK
/QIBM/USERDATA/ICSS/CERT/CERTAUTH/DEFAULT.TEMP
/QIBM/USERDATA/ICSS/CERT/CERTAUTH/DEFAULT.STHBAK
/QIBM/USERDATA/ICSS/CERT/CERTAUTH/DEFAULT.TEMP.STH
/QIBM/USERDATA/ICSS/CERT/CERTAUTH/LOCAL_CERTIFICATE*(*).TMT
/QIBM/USERDATA/ICSS/CERT/CERTAUTH/LOCAL_CERTIFICATE*(*).TXT
/QIBM/USERDATA/ICSS/CERT/CERTAUTH/DEFAULT.POLTMP
/QIBM/USERDATA/ICSS/CERT/CERTAUTH/DEFAULT.POLBAK
/QIBM/USERDATA/ICSS/CERT/DOWNLOAD/CERTAUTH/LOCAL_CERTIFICATE*(*).CATMP
/QIBM/USERDATA/ICSS/CERT/DOWNLOAD/CERTAUTH/LOCAL_CERTIFICATE*(*).CACRT
/QIBM/USERDATA/ICSS/CERT/DOWNLOAD/CLIENT/*.USRCRT
You need to create a new *SYSTEM certificate store and system certificate after moving the following files:
/QIBM/USERDATA/ICSS/CERT/SERVER/DEFAULT.KDB
/QIBM/USERDATA/ICSS/CERT/SERVER/DEFAULT.BAK
/QIBM/USERDATA/ICSS/CERT/SERVER/DEFAULT.RDB
/QIBM/USERDATA/ICSS/CERT/SERVER/DEFAULT.STH
/QIBM/USERDATA/ICSS/CERT/SERVER/DEFAULT.STH.OLD
/QIBM/USERDATA/ICSS/CERT/SERVER/DEFAULT.STHBAK
/QIBM/USERDATA/ICSS/CERT/SERVER/DEFAULT.TMP
/QIBM/USERDATA/ICSS/CERT/SERVER/DEFAULT.TEMP.STH
/QIBM/USERDATA/ICSS/CERT/SERVER/SRV.TMP
/QIBM/USERDATA/ICSS/CERT/SERVER/SRV.BAK
/QIBM/USERDATA/ICSS/CERT/SERVER/SRV.TXT
/QIBM/USERDATA/ICSS/CERT/SERVER/SRV.SGN
/QIBM/USERDATA/ICSS/CERT/SERVER/SGN.TMP
/QIBM/USERDATA/ICSS/CERT/SERVER/SGN.BAK
/QIBM/USERDATA/ICSS/CERT/SERVER/EXPSRV.TMP
/QIBM/USERDATA/ICSS/CERT/SERVER/EXPSGN.TMP
  You may be missing a prerequisite licensed program (LPP) that DCM requires be installed. Check the list of DCM set up requirements and ensure that all licensed programs are installed properly.
The system does not accept a CA text file that was transferred in binary mode from another system. It does accept the file when it is transferred in American National Standard Code for Information Interchange (ASCII). Key rings and key databases are binary and, therefore, different. You must use File Transfer Protocol (FTP) in ASCII mode for CA text files and FTP in binary mode for binary files, such as files with these extensions: .kdb, .rdb, and so forth.
You cannot change the password of a key database. A certificate in the key database is no longer valid. After verifying that an incorrect password is not the problem, find and delete the invalid certificate or certificates from the certificate store, and then try to change the password. If you have expired certificates in your certificate store, the expired certificates are no longer valid. Since the certificates are not valid, the password change function for the certificate store may not allow the password to be changed and the encryption process will not encrypt the private keys of the expired certificate. This keeps the password change from occurring, and the system may report that certificate store corruption is one of the reasons. You must remove the invalid (expired) certificates from the certificate store.
You need to use certificates for an Internet user and therefore need to use validation lists, but DCM does not provide functions for validation lists. Business partners who are writing applications to use validation lists must write their code to associate the validation list with their application as expected. They must also write the code that determines when the Internet user's identity is appropriately validated so that the certificate can be added to the validation list. For more information review the IBM® i Information Center topic QsyAddVldlCertificate API. Consult the IBM HTTP Server for i5/OS documentation for help with configuring a secure HTTP server instance to use the validation list.
You attempted to import a certificate but received an error that states the certificate contains an incorrect signature algorithm.
A digital signature of a certificate is created from one of many signature algorithms. DCM supports the following list of signature algorithms.
  • MD2WithRSASignature
  • MD5WithRSASignature
  • SHA1WithRSASignature
  • SHA1WithDSASignature
  • SHA224WithRSASignature
  • SHA256WithRSASignature
  • SHA384WithRSASignature
  • SHA512WithRSASignature
  • SHA1WithECDSASignature
  • SHA224WithECDSASignature
  • SHA256WithECDSASignature
  • SHA384WithECDSASignature
  • SHA512WithECDSASignature

If the certificate you are importing is not signed with a supported signature algorithm, it must be regenerated with a supported signature algorithm to be imported into DCM.