Set the CN to the FQDN of the OCI DWH you expect your end users to use to access the DWH. OCI doesn't care about the O or C values
Use c:\encryptRequest.csr to obtain a signed certificate from your CA.
Before we move to Phase 2, you need to have your signed certificate, and all the certificates in your CA chain of trust. Typically, your organization will have a root CA certificate, and one or more intermediate signing certificate authorities - we need ALL the public certs from any CA in the chain between the signed OCI DWH cert, and your organizations root CA cert
Phase 2 - Making Cognos happy
We have a handful of certificates.
To proceed, we want:
The OCI DWH certificate in its own file
The Root CA certificate in its own file
All the CA certificates, including the root CA, in one .p7b file
Microsoft's native certificate functionality is pretty strong - you probably can import all these certificates into a Microsoft keystore. Within Microsoft certificate tools, you can shift+select multiple certificates, and export them together into a .p7b. It may be possible to also arrange these files with OpenSSL or another certificate tool.
When we have the files ready, RDP to the OCI DWH server, and copy the files
Open a cmd prompt, running with administrative permissions.
We may have difficulty due to Java path statements- so, in this command prompt we are going to wipe out the PATH variable
In the cmd prompt, navigate to ..\SANscreen\cognos\c10_64\bin
Where ca.cer is your organization's root certificate - this step is required to tell Cognos to trust this root certificate. It is weird, but trust us that this is required, even though the previous certificate importation steps seems to log messages about trusting certificate authorities.
Now, open IBM Cognos Configuration
We need to change Cognos to use a 3rd party CA
Save the Configuration by clicking the floppy disk icon (if you are under 35 years old, ask someone older what a floppy disk is)
Restart the Cognos Services by clicking this icon:
A Window will popup, logging all the events as Cognos services recycle - you may see an error if you have NOT configured SMTP as it will attempt to test it. When things are back up, log into the OCI DWH reporting portal on tcp 9300 - you should no longer see warnings about certificates
FYI - IE and Chrome "outsource" certificate management to Windows' native certificate stores, whereas Firefox uses its own certificate store. If you are using Firefox, and you have NOT installed your organization's CA certs into its certificate store, you will likely still see warnings about untrusted certificates... because you didn't configure Firefox to trust your CA chain.
I have now the problem, that the backup of the DWH does not work any longer? From teh log file it seems to have a problem with the certificate:
2016-10-16 17:02:00,492 ERROR [Thread-85939 (group:HornetQ-client-global-threads-306425475)] BackupScheduleBean (BackupScheduleBean.java:58) - Failed to generate and send dwh and cognos reports.: com.netapp.sanscreen.dwh.upgrade.UpgradeException: Failed to connect to reporting server, server might be down. Confirm reporting server availability and try again.
Caused by: com.netapp.sanscreen.dwh.cognos.CognosClientException: Failed to connect to reporting server, server might be down. Confirm reporting server availability and try again. at com.netapp.sanscreen.dwh.cognos.CognosClient.open(CognosClient.java:112) at com.netapp.sanscreen.dwh.cognos.CognosClient.<init>(CognosClient.java:92) at com.netapp.sanscreen.dwh.cognos.CognosClient.<init>(CognosClient.java:69) at com.netapp.sanscreen.dwh.upgrade.Backup.backup(Backup.java:73) ... 332 more Caused by: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target at org.apache.axis.AxisFault.makeFault(AxisFault.java:101)
Sorry for the comically late reply. I'm mostly posting so I see this next time I run into the same problem.
I recently encountered this problem in a customer environment and discovered that it was due to a misspelled hostname in the CN portion of the certificate request. Once we corrected that, we were able to move on to other errors.