TM1 Forum

Hi guys,

Any idea how do I generate my own SSL certs? I have been looking at libressl for Windows, but not sure how to progress further. Any help would be appreciated.

Thanks
Kaz

paulsimon wrote:Hi Steve
However, I am not sure that there is an issue. The BI App Server needs to have the TM1 Client installed on it. I would have thought that, so long as this Client has the SSL v2 Cert then BI would be able to communicate with TM1 via the v2 Cert? Is there possibly something in the BI Inter-operability layer that is causing a problem?

Possibly, but I am yet to find it. The App Server only needs the TM1 API to be installed, whilst the ssl directory there does have both certs there is something, somewhere telling BI to use the v1 cert. I have had great feedback from my PMR so far, so I'm hoping the info needed can be found and relayed soon. We also had our account manager on site yesterday (purely by chance) and they are well aware of the issues customers are facing. This issue in particular was highlighted last night to them, so we have 2 in-roads to try and get the info.

http://www-01.ibm.com/support/docview.w ... wg27041183

Step 3 of this technote covers what needs to be altered on a BI server using TM1 as a data source in order to swap it to the v2 cert. After a restart of the BI services this works fine, have tested it on the following;

TM1 10.2.2 FP1 IF1015
BI 10.2.1 FP4
Both on Windows Server 2012 64bit

Ensure that the full local path to the cert is entered into the xml file.

kaazimraza wrote:Hi guys,

Any idea how do I generate my own SSL certs? I have been looking at libressl for Windows, but not sure how to progress further. Any help would be appreciated.

Thanks
Kaz

Open a new topic on the board and you will get help.

The more evidence of your own research you present, the better the question will be answered ... just a hint from the front line

The IBM stuff all refers to TM1. Has anyone heard whether they will be supplying similar fixes for Cognos Express? Presumably this will only be applicable for versions 10.1 and 10.2.1 since 9.5 and 9.0 are out of support and CX 10.2.2 is just vanilla TM1.

paulsimon wrote: I have another client who is still on 9.5. They are intending to upgrade to 10.2 but they wanted to get an upgrade to their general ledger finished first. I know that IBM won't confirm it, as 9.5 is no longer supported, however, it seems likely that the new certificates with the extended expiry dates will work on earlier versions. The instructions refer to downloading an Updater. However, that just seems to be something like a self-extracting zip file that creates folders with the new certificates. After that it seems to be a matter of using standard tools that were already there in 9.5 to install the certificates:

The Interim Fix deals only with certificates in three places
C:\Program Files\ibm\cognos\tm1_64\webapps\pmpsvc\WEB-INF\bin64\ssl
C:\Program Files\ibm\cognos\tm1_64\bin64\ssl
C:\Program Files\ibm\cognos\tm1_64\bin\ssl

Install the IF on to a test server and grab one of these directories to copy
Stop the TM1 Admin server/App server
Paste the directory contents into the machine you want upgraded
Start all servers and instances

stephen waters wrote:The IBM stuff all refers to TM1. Has anyone heard whether they will be supplying similar fixes for Cognos Express? Presumably this will only be applicable for versions 10.1 and 10.2.1 since 9.5 and 9.0 are out of support and CX 10.2.2 is just vanilla TM1.

Im going to try the interim fix on CX 10.2.1 now

stephen waters wrote:The IBM stuff all refers to TM1. Has anyone heard whether they will be supplying similar fixes for Cognos Express? Presumably this will only be applicable for versions 10.1 and 10.2.1 since 9.5 and 9.0 are out of support and CX 10.2.2 is just vanilla TM1.

I'm not so worried about CX since all our CX customers are now on "virtual CX" using TM1 enterprise. I'm much more concerned about CDM and Cognos BI as it seems the simple "just swap out the certs and change the names" method while working fine for TM1, fails for CDM & BI. As yet nothing posted from IBM as far as other products goes.

lotsaram wrote:

stephen waters wrote:The IBM stuff all refers to TM1. Has anyone heard whether they will be supplying similar fixes for Cognos Express? Presumably this will only be applicable for versions 10.1 and 10.2.1 since 9.5 and 9.0 are out of support and CX 10.2.2 is just vanilla TM1.

I'm not so worried about CX since all our CX customers are now on "virtual CX" using TM1 enterprise. I'm much more concerned about CDM and Cognos BI as it seems the simple "just swap out the certs and change the names" method while working fine for TM1, fails for CDM & BI. As yet nothing posted from IBM as far as other products goes.

Cant speak to CDM as Dev are working on it, but BI doesnt have an issue with certs AFAIK

Thanks Duncan. Full credit to you that someone from IBM is listening.

Informal update I have received from IBM, subject to correction !

- IBM were hoping the "Updater" ( to apply the fixes) would be published today (Fri 23 Sep) but it has been delayed. Hopefully will be released "early next week"

- The "Updater" will be available for Cognos Express as well as TM1.

- There are problems using updated where TM1 is being used with Controller and\or CDM

btw We noticed today that the IBM tech note about configuring the 2048 certs had been withdrawn, ie the URL said document no longer available. It has now re-appeared
http://www-01.ibm.com/support/docview.w ... wg21697266 but seems to advise this method should only be used

unless you either:
a) Do NOT use TM1 Operations Console/PMHub/CAFE
b) or are on TM1 10.2.2 FP4+

I Think that means don't use if you are on 10.2.2 FP4+ AND you use Op Console/PMHub/CAFE

I also told IBM I think there should be single person at IBM co-ordinating and taking responsibility for this issue, liaising with partners and customers. If there is someone, I haven't heard yet who it is!!

Some more informal info I've had today;

NO patch for anything below 10.x is likely.
Fix for 10.x is due to be released imminently - no date available but believe it just awaits packaging and publishing.
Only viable options for those on 9.x is to either upgrade or generate / install your own certs.

The reason for the 10.2.2 FP4 disclaimer is due to other components that are more complicated than just changing a config, which is what most key parts can accommodate. That includes CDM, Café, Ops Console, PMhub, Connector etc. They can only be fixed by applying the update...

Some more informal info I've had today;
NO patch for anything below 10.x is likely.
Fix for 10.x is due to be released imminently - no date available but believe it just awaits packaging and publishing.
Only viable options for those on 9.x is to either upgrade or generate / install your own certs.

Steve,
Sounds very similar to what I was told last Friday. I just wish "imminently" had a firm date! Our customers, particularly the larger ones, are getting increasingly worried about the delay in issuing the "updater". If it is not issued by end of this week we will need to try and escalate urgently within IBM

Concerning customers on earlier versions (ie pre 10.x) and those who do NOT have a support contract. I believe most customers have bought TM1 under a perpetual license. if the software stops working at a defined date due to a mechanism inserted by the author, does this breach the licence or is IBM able to wash their hands of responsibility (as they seem to be doing at present)?

I am not a lawyer but this could be an interesting legal point.

Steve Vincent wrote:Fix for 10.x is due to be released imminently - no date available but believe it just awaits packaging and publishing.

I wish IBM would stop saying "imminently", the phrase is a bit empty. It has been "imminent" since this was first raised in June/July.
Oxford: imminent = "about to happen"
Webster: imminent = "happening very soon"

Larger IT shops work on release cycles for productive applications. The bigger (and presumably more important to IBM) a customer, the less likely they are to be shoot from the hip hyper-agile, chances are there will be some well defined rules of engagement about software changes and code changes. Some TM1 applications might be on a monthly release cycle but bi-monthly and quarterly are not uncommon. So what happens for a customer on a bi-monthly release cycle with the next release scheduled for October 7 who have been patiently waiting for the IBM Updater? Do you push back the release or start planning for an "emergency" interim release. Both options have consequences and consume time and energy. Surely IBM knows this is the reality of corporate IT?

My point precisely and something that has been very firmly put to our contacts in IBM. We are indeed a very large customer for them, we are getting movement but its coming too slowly for us to enact a significant change to business critical systems. They might just be changing licenses, but due diligence means we have to take the same steps as we would a major upgrade.

Doing that in 7 weeks? Yeah. Not happy.

and this news flash last night takes the mickey;

http://www-01.ibm.com/support/docview.w ... SS9RXT-_-E

how is anyone supposed to comply with that when they haven't provided the fix?

I am simulating the D-day by switching the clock ahead to 2017 and this is what we will be seeing (?) in the admin host debug log. Admin server will fail to start.
Can anyone confirm this is the right steps to verify ?

5272 DEBUG 2017-09-29 00:58:55,708 TM1.Event mt_SetEvent: Set event 0x000000000000035C succeeded.
10512 DEBUG 2017-09-29 00:58:55,708 TM1.Event mt_WaitForMultipleObjects: Successful. Event 0 (0x000000000000035C) signalled.
3856 DEBUG 2017-09-29 00:58:55,708 TM1.Comm.SSL Message in file: ..\tm1_r7s\Sys_net.c Line: 4460 Msg: Error in acceptOpenSSL error code: 336151573 in .\ssl\s3_pkt.c line 1146.TM1 SSL error data SSL alert number 45
3856 DEBUG 2017-09-29 00:58:55,708 TM1.Server.Memory al_FreePool - apifunc# "0" - pool# "0" - poolsize "37158.000000"

If this is the case, I have a solution but this will only work with TM1 server and Perspective for now. Technically I can make it work with TM1Web, Cafe but this will require much more work.
I have tested it successfully with 10.x and 9.5. Not sure about 9.4 as I can't recall is 9.4 already running SSL mode.

This is what you will see in debug log for Admin host, take note of the timestamp:

968 DEBUG 2017-09-29 01:06:05,007 TM1.Comm.SSL SSL Connection accepted.
968 DEBUG 2017-09-29 01:06:05,007 TM1.Comm.SSL Available ciphers:
968 DEBUG 2017-09-29 01:06:05,007 TM1.Comm.SSL Cipher Version: TLSv1/SSLv3, Name: DHE-RSA-AES256-SHA
968 DEBUG 2017-09-29 01:06:05,007 TM1.Comm.SSL Cipher Version: TLSv1/SSLv3, Name: DHE-DSS-AES256-SHA
968 DEBUG 2017-09-29 01:06:05,007 TM1.Comm.SSL Cipher Version: TLSv1/SSLv3, Name: AES256-SHA
968 DEBUG 2017-09-29 01:06:05,007 TM1.Comm.SSL Cipher Version: TLSv1/SSLv3, Name: EDH-RSA-DES-CBC3-SHA
968 DEBUG 2017-09-29 01:06:05,007 TM1.Comm.SSL Cipher Version: TLSv1/SSLv3, Name: EDH-DSS-DES-CBC3-SHA
968 DEBUG 2017-09-29 01:06:05,007 TM1.Comm.SSL Cipher Version: TLSv1/SSLv3, Name: DES-CBC3-SHA
968 DEBUG 2017-09-29 01:06:05,007 TM1.Comm.SSL Cipher Version: TLSv1/SSLv3, Name: DHE-RSA-AES128-SHA
968 DEBUG 2017-09-29 01:06:05,007 TM1.Comm.SSL Cipher Version: TLSv1/SSLv3, Name: DHE-DSS-AES128-SHA
968 DEBUG 2017-09-29 01:06:05,007 TM1.Comm.SSL Cipher Version: TLSv1/SSLv3, Name: AES128-SHA
968 DEBUG 2017-09-29 01:06:05,007 TM1.Comm.SSL Cipher used for connection: Version: TLSv1/SSLv3, Name: DHE-RSA-AES256-SHA
968 DEBUG 2017-09-29 01:06:05,007 TM1.Server.Network internal_net_Recv select on: 920
968 DEBUG 2017-09-29 01:06:05,007 TM1.Server.Network internal_net_Recv select returned: 1

Hi there
I'm working on the expectation that the interim fix will contain updated 1024 bit certificate files
All that would be needed is to replace the three pem files on the server ssl folder and the applixca.pem on the clients

My production environment is on 32bit 9.5.2 sp3 so I am expecting that new certificates will just work
Does anyone see any flaws in this?

I'm not sure whether the v2 ssl files would work in 9.5.2 "it's only a key"- but I will be testing shortly...

Ian B

Update
I now have 9.5.3 (non production of course) working on the v2 certs

All I did was to rename the 3 certificate files to their given Applix names and to replace the 3 files in the server bin\ssl folder and replace the applixca.pem in the client bin\ssl folder (default file names are hard-coded somewhere)

The server started and was able to register with the admin server
The client sees the server announced by the admin server and can log in as normal
I left the dh1024, cipher and key files unchanged


I haven't tried winding my clock forwards - but my tm1svrcert now expires in 2022...
Anyone see any risk in this solution?

Ian B

IanB wrote:Update
I now have 9.5.3 (non production of course) working on the v2 certs

All I did was to rename the 3 certificate files to their given Applix names and to replace the 3 files in the server bin\ssl folder and replace the applixca.pem in the client bin\ssl folder (default file names are hard-coded somewhere)

The server started and was able to register with the admin server
The client sees the server announced by the admin server and can log in as normal
I left the dh1024, cipher and key files unchanged


I haven't tried winding my clock forwards - but my tm1svrcert now expires in 2022...
Anyone see any risk in this solution?

Ian B

Nope. I think for any pre v10 server what you have done is pretty much the only option. (or don't rename and go with custom certs).
https://cubewise.com/blog/solutions-exp ... tificates/

This approach also enables a rather neat managable solution for deploying the change across multiple clients and servers

At the client, the certificate authority file is in the client options dialog.
Retain the existing applixca and deploy tm1ca_v2 to the bin\ssl folder in advance of making server changes

When a user sets this to applixca, they will see current production servers in server explorer. Changing this to tm1ca_v2, will show only the servers with updated certificates

I see a stress-free switchover coming...

IanB