An unhandled TLS 1.2 error in plugin after upgrading from TLS 1.1 to TLS 1.2 in ccm
We have a clm server upgraded from 6.0.5 to 6.0.6.1 and the TLS was 1.1 working on that. Now the TLS is upgraded to TLS 1.2. We had one plugin which used to work fine when TLS 1.1, but after upgrading it to TLS 1.2, we are facing Issue.
The Issue we are facing is , when I change "Planned for" it throws an unhandled exception and gives TLS error.
Can anyone please help to solve this Issue.
There seems no Issue with plugin as it has been working all the time before upgrading the TLS to 1.2.
I am not able to get hold of the error.
Java version is 1.8 for the environment and clm 6.0.6.1
Error statement :
3 answers
If this is a custom plugin, you have the code and can check where this is happening.
The error message seems to imply that not only TLS 1.2, but some other protocol is enabled.
"An unhandled exception occurred during "Test Task creation". Only TLS1.2 protocol can be enabled in SP800_131 strict mode."
Otherwise I do not know.
Comments
Hi Ralph,
I am not able to find much in the logs except for that it mentions
"INFO lr.rmdv.testtaskcreation.service.RQMOSLCConnection"
ERROR com.ibm.team.process.common
Also the file which is mentioned above has a part of the code as :
"public RQMOSLCConnection()
{
this.httpClient = new DefaultHttpClient();
HttpUtils.setupLazySSLSupport(this.httpClient);
}
public RQMOSLCConnection(String serverUri, String login, String password)
{
this.rqmServerUri = serverUri;
this.rqmLogin = login;
this.rqmPassword = password;
this.httpClient = new DefaultHttpClient();
HttpUtils.setupLazySSLSupport(this.httpClient);
}"
{
this.httpClient = new DefaultHttpClient();
HttpUtils.setupLazySSLSupport(this.httpClient);
}
public RQMOSLCConnection(String serverUri, String login, String password)
{
this.rqmServerUri = serverUri;
this.rqmLogin = login;
this.rqmPassword = password;
this.httpClient = new DefaultHttpClient();
HttpUtils.setupLazySSLSupport(this.httpClient);
}"
Also I wanted to ask that if we upgrade to TLS1.2, we need to update in server.xml files for it? or in reverseproxy config file aslo?
First of all: This happens in EWM/RTC, correct?
The package name 'lr.rmdv.testtaskcreation.service.RQMOSLCConnection' indicates this is a custom follow up action. IBM does not use package names like that. So someone has developed this thing and deployed it on your server. It is currently configured in at least one project area.
Based on the name it creates a connection to another server. Probably RQM. It uses an HTTP client and seems to have a hardcoded login.
The code you mention above is from the OSLC workshop or from other OSLC examples that I have seen. HttpUtils.setupLazySSLSupport(this.httpClient); is code that is used if one wants to communicate to uncertified or wrongly certified servers. I am pretty sure that our production code does not contain anything like this.
Also an HTTP client is configured and used. This configuration is most likely not TLS1.2
Here my suggestions:
1. Check with the project area admins, where this is used and ask them to deactivate it
2. Check who has the code for the plugin and ask for the plugin to be fixed.
3. Locate the plugin in the conf/ccm/sites and conf/ccm/provision_profiles folder
4. Undeploy the plugin and do a server reset request.
5. Make sure the extension is tested with TLS1.2 before it is redeployed.
6. Read up on the documentation about TLS1.2. My assumption would be that you want all servers involved on TLS1.2 but I am not qualified to talk about this.
It might be able to rewrite the offending code of the follow up action to work better and not cause the issue. However, because of the code quality concerns I would suggest a review and an architectural review of the extension and what it does and if it is still needed or should be recoded in a different way.
I had SSL issues with TLS 1.2 strict mode. During my case with IBM i learned that when you enable strict TLS 1.2 and the another sytem is set for anythign other than 1.2 only (say TLS 1.1 or 1.2), you would think they would negotiate to use 1.2. However, due to an oddity in the TLS 1.2 RFC the connection is denied unless all endpoints are configured for TLS 1.2 only (not necessarily strict 1.2). We did not have requirement for 800-131 so we simply configured all ELM servers for TLS 1.2 only - not stict mode.