There are many installation scenarios that can cause TRIRIGA reports, especially BIRT reports, to fail to export due to timeout. Microsoft Excel exports are often the ones that you can observe because all of the file formatting happens during export.
Let’s focus on WebSphere Liberty installations, but this recommendation can be used for other web servers with some tweaks. Mostly, this is related to timeout settings, especially for HTTPS (SSL/TLS) connections. A good troubleshooting test is to perform the same action in a non-HTTPS (HTTP) connection. Does the report export? If so, take note of the time needed to export it and plan to extend the timeout in the HTTPS connection to at least double the time.
Refer to the IBM Knowledge Center > WebSphere Liberty > HTTP Endpoint topic. Look for the “sslOptions”, and also double-check the “httpOptions”, for timeouts.
[Admin: This post is related to the 04.20.17 post about setting the TRIRIGA session expiration warning in the portal. To see other related posts, use the Timeout tag.]
Due to security regulations, certain customers must disable TLS protocols 1.0 and 1.1. However, when they do this and use only TLS 1.2, they lose connectivity from the TRIRIGA Reserve Outlook add-in.
The problem was that the add-in was compiled with .NET 4.0 which doesn’t support TLS 1.2. The fix is to explicitly force support for the TLS 1.2 protocol. Moving forward, the IBM TRIRIGA Workplace Reservation Manager add-in is now able to communicate with the TRIRIGA server over the TLS 1.2 protocol.
[Admin: To see other related posts, use the Add-in tag or TLS tag.]
Does TRIRIGA support TLS 1.1 or TLS 1.2 or SSL? If yes, what steps do I need to take to make TRIRIGA use one of these protocols?
TLS and SSL, from a TRIRIGA perspective, are supported by certificate technology for security and use HTTPS URLs. TRIRIGA works with HTTPS: Does IBM TRIRIGA support HTTPS, SSL and TLS? As a result, TRIRIGA can be used with TLS and SSL, regardless of the version.
There is no TLS or SSL configuration necessary within TRIRIGA. If TLS 1.1 or TLS 1.2 or SSL is properly configured through your application server and web server, TRIRIGA can be used with it. TLS and SSL are security configurations using certificate installs that exist outside of TRIRIGA. The TRIRIGA Support team cannot assist with environmental configurations of these technologies. Clients should work with their application server vendors (e.g., WebSphere, WebLogic) as well as other infrastructure-related technologies (e.g., web servers, load balancers, etc.) to properly configure these.
[Admin: This post is related to the 09.30.14 post about whether TRIRIGA supports HTTPS, SSL, and TLS, and the 04.10.17 technote about TLS, SSL, and HTTP.]
If you are going to upgrade IBM TRIRIGA Platform or IBM TRIRIGA Portfolio Data Manager (Application), you might want to review the following checklist:
- (CK01) Third party considerations…
- (CK02) Sizing recommendations…
- (CK03) Preparing the environment…
- (CK04) Upgrading the platform…
- (CK05) Upgrading the application…
- (CK06) Tuning your product…
- (CK07) High availability considerations…
- (CK08) SSO & seamless login information…
- (CK09) TLS & SSL (HTTPS) support…
[Admin: This post is related to the 12.15.15 post about the latest 3.5.0 upgrade documentation, and the 06.16.15 post about the latest 3.4.2 upgrade documentation.]
When trying to login to CAD Integrator (CI), we get a generic error: https:// secure site, SSL related. We had recently upgraded to TRIRIGA Platform 126.96.36.199 and are running CAD Integrator 12.1.1. We have taken a patch for 188.8.131.52 to get the option to “Always Trust SSL Certificates”. But that did not resolve our login issue.
When attempting to login to CI, it is reporting a login failure:
2016-02-20 12:42:16,855 ERROR [com.tririga.ci.login.LoginServiceImpl](pool-1-thread-6) Login failed: org.springframework.web.client.ResourceAccessException: I/O error on POST request for "https://FRONT_END_SERVER:443/pc/ci/dispatch":peer not authenticated; nested exception is javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated
Caused by: javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated
The cause is the incorrect version configuration for TLSv1. We requested that the customer provide us with a MustGather summary for our extended team to review the WebSphere configuration. Following the instructions for “Collecting Data Manually”, we were able to identify a disconnect in the version of TLSv1. The SSL trace shows:
[3/25/16 9:27:01:186 EDT] 000000bf SystemOut O WebContainer : 0, fatal error: 40: Client requested protocol TLSv1 not enabled or not supported javax.net.ssl.SSLHandshakeException:
Looking at the security.xml file for the node, we can see that it is set to use TLSv1.2 exclusively. Therefore, it is not able to accept the SSL handshake from the client, because it is trying to use TLSv1. To resolve this issue, it is necessary to either configure the client to use TLSv1.2, or configure the server to allow TLSv1.
[Admin: For convenience, here are the meanings of the acronyms: Secure Sockets Layer (SSL), Transport Layer Security (TLS).]
Are HTTPS, SSL and TLS supported by IBM TRIRIGA product? I need to implement HTTPS, SSL and TLS for my IBM TRIRIGA solution.
The Transport Layer Security (TLS) and its predecessor, Secure Sockets Layer (SSL), are both supported via Hypertext Transfer Protocol Secure (HTTPS). The HTTPS protocol is the result of simply layering the Hypertext Transfer Protocol (HTTP) on top of the SSL/TLS protocol, thus adding the security capabilities of SSL/TLS to standard HTTP communications. This is implemented via Web Server configuration. We have tested HTTPS for IBM TRIRIGA and support it via Web Server set up. See: Enable HTTPS in WebSphere for Maximo, SCCD, TSRM, and TRIRIGA.
But we do NOT support:
- Secure Shell (SSH) on the IBM TRIRIGA system. But during installation, the IBM TRIRIGA installer may connect to the application server as the IBM TRIRIGA user via the SSH protocol. Another remote terminal application protocol may be used as well. See the IBM TRIRIGA Application Platform Version 3.4.1 Installation and Implementation Guide [PDF].
- The Microsoft Remote Desktop Protocol (RDP) proprietary protocol.
- The encrypting communication session IP packet Internet Protocol Security (IPsec) protocol suite. Your application server may support it, but this has never been tested by IBM TRIRIGA.
- The Citrix Systems proprietary application server Independent Computing Architecture (ICA) protocol.
[Admin: This post is related to the 08.04.16 post about configuring TLS or SSL, and the 04.10.17 technote about TLS, SSL, and HTTP.]