The current connector code in the server.xml file is working fine (https://URL is working fine)
1. On checking the server.xml the connector port is defined as:
<Connector port="8443" protocol="HTTP/1.1" connectionTimeout="20000" SSLEnabled="true" scheme="https" secure="true" clientAuth="false" sslProtocol="TLS" keystorePass="xxx" keystoreFile="xxx" maxThreads="150" minSpareThreads="25" acceptCount="100" enableLookups="false"/>
2. To reconfigure the tomcat to use TSLv1.2 we need to make the above code as:
<Connector port="8443" protocol="HTTP/1.1" connectionTimeout="20000" SSLEnabled="true" scheme="https" secure="true" clientAuth="false" sslProtocol="TLS" sslEnabledProtocols=”TLSv1.2” keystorePass="xxx" keystoreFile="xxx" maxThreads="150" minSpareThreads="25" acceptCount="100" enableLookups="false"/>
Steps to perform this change:
1. Stop tomcat
2. Make the above code changes in the config file.
3. Restart the tomcat.
4. Test the URL
Also is there a way to verify if the protocol is using TSLv1.2 version only. Please note, we cannot install any 3rd party tool or utility to check this on the server due to client restrictions.
Tim Moores wrote:If the host is publicly accessible, you could run a test with https://www.ssllabs.com/ssltest/. But given that the port is 8443, it probably isn't.
SSL Labs is a great test/analysis tool, but as Tim mentioned, it isn't going to work with a port other than 443. One work-around, if you have Internet-facing firewall, would be to temporarily rewrite the destination port for Internet traffic for port 443 to 8443, so that the online tool would be able to access your Tomcat instance.
It's also worth noting that for web applications that will appear on the public Internet (where you would need to be most careful about limiting TLS protocols), that it's generally not recommended to connect Tomcat directly.
DNS services don't record port numbers, only IP addresses, so http will assume port 80 by default and https will assume port 443. To get to port 8443, the client would have to explicitly request it in their URL request (that is, https://myserver.com:8443). Which is inconvenient and error prone.
Port values below 4096 are not available to general application program users such as Tomcat, so to actually use Tomcat directly on ports 80 and 443 would require running Tomcat as a privileged user, which is a security risk.
More often, a reverse proxy server such as Apache, Nginx or IIS is used as the public web interface and an internal connection is made from the proxy server to Tomcat. The internal connection is generally not encrypted, since it's usually done vie an encoded channel and one hopes that your backend LAN is secured against public access anyway. So in a case like this, the limits on transport protocols would be made in the configuration of the proxy server, not Tomcat, since that's where the decryption will be done.
In addition to software proxy servers there are also hardware proxy servers, which are often also load balancers for a cluster of backend appservers. Here, too, the TLS constraints to would be done in their configurations.
"privilege" comes from the Latin words for "private" and "law" (legal) and dates to feudal times. To "claim privilege" meant that you were above the laws that applied to the common people.