Planning Analytics

Bernd Siebert posted Sat December 14, 2024 05:22 PM

What happens when you replace   hostNameVerification=“false”   by   verifyHostname="false"   ?

See

Hostname verification for Liberty

 WebSphere and wlp hostname verification on SSL

Vlad Didenko posted Sat December 14, 2024 07:20 PM

Have you imported the TM1 server and CA chain certificates to your TM1Web keystore?

Philippe CHAMPLEBOUX posted Sun December 15, 2024 02:58 AM

Thanks Bernd,

I try 

    
    <ssl id="DefaultSSLSettings" keyStoreRef="defaultKeyStore" skipHostnameVerificationForHosts="*" verifyHostname="false"/>

but nothing better

regards,

Philippe

Philippe CHAMPLEBOUX posted Sun December 15, 2024 03:05 AM

Hi Vlad,

I import  (I think, I hope) the tm1server certificate with :

keytool -importcert -keystore "E:\ibm\cognos\tm1web\bin64\ssl\ibmtm1.p12" -storepass "xxxxxxx" -storetype pkcs12 -noprompt -alias ibmtm1 -file "E:\ibm\cognos\tm1_64\bin64\ssl\ibmtm1.arm"

do i need to import another "file" ?

My ibmtm1.p12 contain :

 - my custom certificat

 - ibmtm1 (wich is ibmtm1.arm

 - tm1svr

Regards,

Philippe

Vlad Didenko posted Sun December 15, 2024 07:29 PM

To confirm, are you using the default ibmtm1.arm certificate for the TM1 server? Have you imported the root and intermediate certificates?

Please see this technote: https://www.ibm.com/support/pages/how-configure-ibm-planning-analytics-spreadsheet-service-custom-ssl-using-existing-keystore

Philippe CHAMPLEBOUX posted Mon December 16, 2024 01:06 AM

Thanks Vlad,

But with 2.1.6 we have not theses files, only ibmtm1.arm.

Regards,

Philippe

Martin Erlmoser posted Mon December 16, 2024 05:21 AM

i have a very similar issue with 2.1.6, not sure what the difference is to 2.0.9 setup yet.
custom web and data tier cert, works fine in 2.0.9 environment, web tier works but data tier refuses to work in tm1web on a new 2.1.6 / win 2022 server. (no tm1 servers visible)
last time i deployed the keystore with custom certs it was the file tm1store, not ibmtm1.p12 mentioned here, but i think you can check this in jvm.options as well. 

already added verifyHostname="false" to server.xml, is there something similar needed for jvm.options?

Walter Coffen posted Mon December 16, 2024 04:51 PM

Philippe,

Are you using the same certificate for the Win 2022 server as you used for the older server?

"The host name used to access the server does not match the SubjectDN or Subject Alternative Name (SAN) information in the server certificate"

Would seem to indicate that the Win 2022 server FQDN is not in the certificate. If the old certificate was a wildcard cert, it would probably work, but usually an endpoint certificate is for one server(the old one?) or it has a specific list of servers in the "Subject Alternative Name" field and may have been generated before the Win 2022 server came into existence.

Vlad Didenko posted Mon December 16, 2024 05:21 PM

Can you post the content of the tm1web\wlp\usr\servers\tm1web\server.xml file? Just mask any sensitive information

Philippe CHAMPLEBOUX posted Tue December 17, 2024 01:11 AM

Walter,

Yes, I use the same certificat as i used for older server.

I asked to my customer to generate and give me a new certificat with more informations in SubjectDN and SAN.... I am waiting for it..... I hope it would be the solution.

Regards,

Philippe

Philippe CHAMPLEBOUX posted Tue December 17, 2024 01:15 AM

Hi Vlad,

My server.xml

Regards,

Phiippe

Philippe CHAMPLEBOUX posted Tue December 17, 2024 01:18 AM

Martin,

I try 

-Dcom.ibm.ssl.verifyHostname=false

in jvm.options but .... not better ;-(

regards,

Philippe

Dominik Schott posted Tue December 17, 2024 04:41 AM

According to my documentation it should be 

<ssl id="defaultSSLConfig" verifyHostname="false" />

(not DefaultSSLSettings).

Philippe CHAMPLEBOUX posted Tue December 17, 2024 05:14 AM

Thanks Dominik,

yes, you are rigth. !!

I modify .

but .... Not better... does'nt work

We create a ticket with IBM support, wait and see

An other solution is to install spreadsheet 2.1.5  

kind regards,

Philippe

Vincent Zeng posted Sat December 21, 2024 07:34 PM

We experienced the same issue after we switched our PA 2.1.6 TM1Web from http to https by following this post

https://www.ibm.com/docs/en/planning-analytics/2.1.0?topic=ipass-configuring-ssl-planning-analytics-spreadsheet-services-tm1-web-existing-keystore

Make sure to use the keytool.exe to add the alias for the ibmtm1.arm to your custom keystore.

Before we switched to https, our TM1web can list tm1 instances. After we switched to https, our TM1web can't list tm1 instances anymore. In <install_dir>\tm1web\wlp\usr\servers\tm1web\logs, we found the same error message of "[ERROR ] CWPKI0824E: SSL LINK ESTABLISHMENT FAILURE: host name verification error when connecting to host [127.0.0.1]".  However, if we modified the server.xml file AND restarted "IBM Planning Analytics Spreadsheet Services" to switch back to http, our TM1web could list all the tm1 instances again. 

When we enabled https,  we set httpPort="-1" httpsPort="9510"  in the server.xml. When we disabled https, we set httpPort="9510" httpsPort="9513" and removed the <keyStore id="defaultKeyStore" entry. This might be different from your setting.

Disabling host verification mentioned in the post IBM Planning Analytics Spreadsheet Services after update/fresh install of version  2.0.99 or never, cannot list database instances when using custom SSL did work for us.

We added  <ssl id="defaultSSLConfig" verifyHostname="false" />to <INSTAL_DIR>\tm1web\wlp\usr\servers\tm1web\server.xml and restarted the server. Problem solved. 

Hope it helps your troubleshooting of this same issue.

Philippe CHAMPLEBOUX posted Wed December 25, 2024 02:52 AM

Vincent Zeng posted Thu December 26, 2024 03:54 PM

Happy Holidays everyone! 

Hi Philippe, our PA 2.1.6 is also installed on Windows 2022.

Saif Ali Sabri posted Fri December 27, 2024 11:47 PM

My response was crafted with AI assistance, tailored to provide detailed and actionable guidance for your query.

The issue you're facing is related to SSL hostname verification. This commonly occurs when the SSL certificate being used doesn't match the hostname specified in the configuration or the server's actual hostname. Here's a systematic approach to troubleshoot and resolve the issue:

---

1. Certificate Configuration

• Verify the Certificate:
  Ensure the certificate used matches the server's fully qualified domain name (FQDN) or IP address.

  • If the hostname is 127.0.0.1, the Subject Alternative Name (SAN) of the certificate must include 127.0.0.1.
  • If you're accessing the server using a specific FQDN (e.g., tm1server.mycompany.com), the certificate's SAN must include tm1server.mycompany.com.

• Check KeyStore:
  Confirm the keystore contains the correct certificate:

  
  bash
  
  
  Copy code
  
  
  keytool -list -keystore <path_to_keystore>
  
  
  

  Verify that the alias matches the one referenced in your server.xml.

---

2. Update Configuration

• Modify server.xml: Ensure your server.xml includes the correct SSL settings:

  
  xml
  
  
  Copy code
  
  
  <ssl id="DefaultSSLSettings" keyStoreRef="defaultKeyStore" hostNameVerification="false" />
  <keyStore id="defaultKeyStore" location="<path_to_keystore>" password="<keystore_password>" />
  
  
  

  Replace <path_to_keystore> and <keystore_password> with the actual path to your keystore and its password.

• Disable Hostname Verification (Temporary Solution):
  If you must bypass hostname verification temporarily for testing:

  
  xml
  
  
  Copy code
  
  
  <ssl id="DefaultSSLSettings" keyStoreRef="defaultKeyStore" hostNameVerification="false" sslProtocol="TLSv1.2" />
  
  
  

  Note: Disabling hostname verification is not recommended in production environments.

---

3. Hostname Mapping

• Update hosts File:
  If you're using 127.0.0.1 to connect, map the server's hostname in the hosts file:

  • On Windows:
    Edit C:\Windows\System32\drivers\etc\hosts:

    
    
    
    
    Copy code
    
    
    127.0.0.1 tm1server
    
    
    

  Then, access the TM1 instances using tm1server instead of 127.0.0.1.

---

4. TM1 Configuration

• Verify tm1s.cfg:
  In each TM1 instance's tm1s.cfg, check the ServerCAMURI and ClientCAMURI to ensure they point to the correct URL (matching the certificate's SAN or hostname).

• Update tm1web_config.xml:
  Make sure the TM1 Web configuration points to the correct URL:

  
  xml
  
  
  Copy code
  
  
  <TM1WebConfiguration>
    <AdminHost>localhost</AdminHost>
    <TM1Server>your_tm1_instance_name</TM1Server>
    <UseSSL>true</UseSSL>
  </TM1WebConfiguration>
  
  
  

---

5. Logs and Diagnostics

• Review Logs:
  Check the following logs for detailed errors:

  • <install_dir>\tm1web\logs\systemout.log
  • <install_dir>\tm1web\logs\systemerr.log
  • WebSphere logs (if applicable).

• Enable Debugging:
  Add debug options to your server.xml for SSL troubleshooting:

  
  xml
  
  
  Copy code
  
  
  <logging traceSpecification="SSL=all" />
  
  
  

---

6. Validate Connection

• Use tools like curl or browsers to test the SSL connection:

  
  bash
  
  
  Copy code
  
  
  curl -v -k https://127.0.0.1:9443
  
  
  

  Check for any certificate or hostname mismatch warnings.

---

7. Fallback Option

• Recreate the Certificate:
  If the above steps don’t work, recreate a self-signed certificate or obtain a new certificate with the correct SAN entries:

  
  bash
  
  
  Copy code
  
  
  keytool -genkeypair -alias tm1web -keyalg RSA -keysize 2048 -validity 365 -keystore <path_to_keystore>
  
  
  

---