Environment
NetIQ iManager 2.7 SP7
NetIQ iManager 3.0 SP2
NetIQ Identity Manager 4.5 SP5
NetIQ eDirectory
NetIQ iManager 3.0 SP2
NetIQ Identity Manager 4.5 SP5
NetIQ eDirectory
Situation
To setup the Identity Manager (IDM) Remote Loader (RL) to use TLS/SSL the Certificate Authority (CA) certificate is exported from the Identity Vault (IDV) and provided on the RL side. This is often done via iManager, though it could also be done via ConsoleOne or, if the same CA is used for LDAPS/HTTPS services linked to eDirectory, via other tools that can view the certificate chain, such as the 'openssl' command. The CA is exported in base64 (b64/pem) format to be used by the RL.
Attempting to use iManager to export the certificate results in no errors, and the exported file has base64-encoded data as expected. Providing the b64 file to the RL, though, results in the following error when it starts, even before the engine makes a connection to it, as viewed in its trace output:
Attempting to re-export the file, or to recreate the CA, usually results in the exact same type of output, and the same symptom. Changing versions or plugins of iManager does not seem to have any impact either.
Attempting to use iManager to export the certificate results in no errors, and the exported file has base64-encoded data as expected. Providing the b64 file to the RL, though, results in the following error when it starts, even before the engine makes a connection to it, as viewed in its trace output:
Error Initializing connection to DirXML: SSL library initialization error: error: 0B084009:x509 certificate routines: X509_load_cert_crl_file:PEM lib
Attempting to re-export the file, or to recreate the CA, usually results in the exact same type of output, and the same symptom. Changing versions or plugins of iManager does not seem to have any impact either.
Resolution
There are a few possible fixes and workarounds, though in the end this is a defect with the iManager plugin creating the certificate export.
The exported certificate file can be opened in a text editor, such as vi/vim, JEdit, EditPlug, Notepad++, gedit, or kwrite; near the bottom is a blank line before the line which indicates the end of the certificate data. This blank line before that comment line is invalid syntactically and should be removed. Save the resulting file and then the use of this by TLS/SSL clients should work properly. For example, the following is incorrect:
The following is a corrected version of the same data with the blank line removed:
The exported certificate file can be opened in a text editor, such as vi/vim, JEdit, EditPlug, Notepad++, gedit, or kwrite; near the bottom is a blank line before the line which indicates the end of the certificate data. This blank line before that comment line is invalid syntactically and should be removed. Save the resulting file and then the use of this by TLS/SSL clients should work properly. For example, the following is incorrect:
dHJ1c3QuY29tL3Jlc291cmNlcy9yZXBvc2l0b3J5MA0GCSqGSIb3DQEBBQUAA4GB
AHbhEm5OSxYShjAGsoEIz/AIx8dxfmbuwu3UOx//8PDITtZDOLC5MH0Y0FWDomrL
NhGc6Ehmo21/uBPUR/6LWlxz/K7ZGzIZOKuXNBSqltLroxwUCEm2u+WR74M26x1W
b8ravHNjkOR/ez4iyz0H7V84dJzjA1BOoa+Y7mHyhD8S
-----END CERTIFICATE-----
The following is a corrected version of the same data with the blank line removed:
dHJ1c3QuY29tL3Jlc291cmNlcy9yZXBvc2l0b3J5MA0GCSqGSIb3DQEBBQUAA4GB
AHbhEm5OSxYShjAGsoEIz/AIx8dxfmbuwu3UOx//8PDITtZDOLC5MH0Y0FWDomrL
NhGc6Ehmo21/uBPUR/6LWlxz/K7ZGzIZOKuXNBSqltLroxwUCEm2u+WR74M26x1W
b8ravHNjkOR/ez4iyz0H7V84dJzjA1BOoa+Y7mHyhD8S
-----END CERTIFICATE-----
Cause
The certificate data created by the iManager plugin has a bug in that it puts a blank line between the two comments indicating the start and end of the certificate data. A blank line is not valid and must be removed if it is placed in there. Removing the blank line returns the data to a valid state which can be used by the RL or other TLS/SSL client applications. A fix for the plugin is the ultimate resolution.
Bug Number
1026050
Additional Information
ConsoleOne's snapins appear to export the file properly.
Similarly, getting the CA certificate from openssl by connecting to the LDAPS or HTTPS service, which likely has a certificate from the same CA, also works properly:
Similarly, getting the CA certificate from openssl by connecting to the LDAPS or HTTPS service, which likely has a certificate from the same CA, also works properly:
> openssl s_client -connect server.address.goes.here:636 -showcerts