PingFederate uses the jetty engine for its internal web server. To disable TLS version 1.0 in jetty, there are two files that need to be updated on every server in the cluster, namely jetty-admin.xml and jetty-runtime.xml. Although the keen PingFederate administrator will recognize that only one file is technically needed based on the server operational mode as configured in the run.properties file, this blog recommends changing both to avoid any issues down the road.
Within the file /pingfederate/etc/jetty-admin.xml, locate the the sslContextFactory and add TLSv1 as an Excluded Protocol as shown in the configuration snippet below. The same configuration element is located in the file /pingfederate/etc/jetty-runtime.xml. However, in the runtime configuration there are two SSL context factories, mainly namely the primarySSLContextFactory and secondarySSLContextFactory. Both of these context factories need to add the TLSv1 as an Excluded Protocol as shown in the configuration snippet below. After updating these files the PingFederate service will need to be restarted. This process will need to be repeated on each node in the PingFederate cluster (including the Admin console node).
PingAccess does not use Jetty, instead it uses Netty which is a non-blocking I/O client server framework for the development of a Java network application. Netty delegates the SSL context configuration to the Java Runtime Environment (JRE). In the case of a PingAccess deployment, this will be the JRE defined for PingAccess to leverage at runtime. In order to disable TLS 1.0, we need to update the security settings in the JRE. This is accomplished by editing the file: jre/lib/security/java.security. Find the property for jdk.tls.disabledAlgorithms and add TLSv1 to the list (Note: This entry only exists in JRE 1.8 and will not work in older versions of the JRE). The updated entry will look like this:
jdk.tls.disabledAlgorithms=SSLv3, TLSv1, RC4, MD5withRSA, DH keySize < 768
After updating this JRE setting, the PingAccess service will need to be restarted. This process will need to be repeated on each node in the PingAccess cluster (including the Admin console node).
Whether your PingFederate or PingAccess environment was recently established or it’s been active for some time, it is always a good idea to ensure security, as well as optimum configuration. We can help you get the most out of your Ping deployment. Our checkup services will fully review your implementation, whether it be a version and patch upgrade, taking advantage of new improvements to features, or process improvement, we are ready to assist. Contact us to schedule your checkup!