The pyOpenSSL version on the Key Trustee Server cluster should be updated to 16.2 before changing the TLS version to 1.2. If pyOpenSSL is not updated, KTS service fails to restart and throws errors.
This was a response given by cloudera engineer if i want to upgrade TLSv 1.2 on KTS servers.
My question is we are using Rhel/centos 6 for our KTS servers, so is this version of pyOpenSSL is compatible with centos/rhel 6.
if not what is the workaround, currently all our KTS clusters on Rhel/Centos 6.
I am unable to find the RPM for pyOpenSSL 16.2 version compatible with Rhel/Centos 6 available online.
In order for you to be able to restrict TLS protocol to TLSv1.2 you need to have the components support that configuration. PyOpenssl.
What version do you have now?
You can run:
# pip show pyopenssl
I am pretty sure that all modern releases of pyopenssl should support OP_NO_TLSv1_1, but let's start with finding out what version of pyopenssl you have on your keytrustee server host.
Thanks Ben for the response.
this is the version of PyOpenSSL we have on our KTS servers and these KTS servers are Rhel/Centos 6.
0.13 does not contains support for SSL_OP_NO_TLSv1_1 so indeed you will need to update your python version's PyOpenSSL.
Can you try running:
# pip install --upgrade pyopenssl
Hopefully this will update to 0.14 or higher which support SSL_OP_NO_TLSv1_1
HI Ben - We have pip installed in 3 places: /usr/bin, /opt/anaconda/2 and /opt/anaconda/3.....which pip to use for the upgrade? Want to make sure when it's upgraded Cloudera will pick it up.?
Since its pip for OS python as you recommended -- our KTS servers are Rhel 6 and centos 6 and we are unable to find the RPM for it which is above 13.1.
There is a directory on our KTS servers which already seems to have pyopenssl version 0.14, I am not sure if this enough.
Other location where the Pyopenssl is located and have 0.13 version
We tried to make changes to Java.security file to enforce TLS 1.2(but did not do any upgrades to Pyopenssl version) and made config changes in KTS service to use 1.2 and restarted both KTS and KMS services after that and they were able to start without throwing any errors. so I am kinda puzzled if KTS is already using the pyopenssl upgraded version from one of our locations or ?
I read the the documentation from Cloudera where it says if we do not upgrade pyopenssl version and enforce TLS 1.2 by making changes to java.security, the services will not start and will throw errors but I was able start the services.
Please let us know if we missed anything or following the right procedure so far ?
I am not expert on the KTS side, but if the server starts, then it sounds like you may not be hitting a problem. You can test to make sure KTS is only accepting TLSv1.2 by using openssl or nmap.
openssl s_client -connect <kts_host>:<kts_port> -tls1_2
Key Trustee Ships as a self contained product. While the front end of Key Trustee can and does support TLS 1.2 the postgreSQL version that presently ships with Key Trustee has no support for cipher enforcement. Even though it is capable of supporting TLS 1.2 other cipher specs cannot be forcefully disabled.
If your goal is to ensure that all of the components on your system use only TLS 1.2 you should be advised that the security scanners will continue to report other TLS versions for the release of postgreSQL that currently ships with Key Trustee even with available work arounds. We also do not provide any UI based methods for altering the TLS configuration for the backing Key Trustee Database. You will need to reach out through normal support channels to obtain the work around we can provide.
The KT service exports the following parameters along with others during startup to the environment. You should not attempt to update any part of the parcel content. Note where the python home is located.
The parcel presently ships with pyOpenSSL-0.14.
Please show us the documentation you are referencing and also please be advised that there are various other components which also use python through out the platform.