Home / server / Questions / 1093174
Accepted
acgbox
Asked: 2022-02-10 06:50:27 +0800 CST

How to disable lines in java.security to avoid javax.net.ssl.SSLHandshakeException?

  • 772

I need to disable the following lines in the java.security file (java 8 SE):

jdk.tls.disabledAlgorithms=SSLv3, TLSv1, TLSv1.1, RC4, DES, MD5withRSA, \
   DH keySize < 1024, EC keySize < 224, 3DES_EDE_CBC, anon, NULL, \
   include jdk.disabled.namedCurves

in windows

Image in Windows.

Windows path: Program Files\Java\jre1.8.0_301\lib\security\java.security

The purpose of disabling these lines is to avoid the following error message:

Error: javax.net.ssl.SSLHandshakeException: No appropriate protocol 
(protocol is disabled or cipher suites are inappropriate)

And the solution proposal published here (which is to comment on these lines).

I'm not sure if putting a comment at the beginning of the line (#) will disable them for both operating systems. Because this oracle document say is //

whichever one is used to comment out the lines, I also don't know if it is necessary to comment out all 3 lines, or just commenting out the first disables all 3. Example:

this way:

# jdk.tls.disabledAlgorithms=SSLv3, TLSv1, TLSv1.1, RC4, DES, MD5withRSA, \
   DH keySize < 1024, EC keySize < 224, 3DES_EDE_CBC, anon, NULL, \
   include jdk.disabled.namedCurves

or that way?

# jdk.tls.disabledAlgorithms=SSLv3, TLSv1, TLSv1.1, RC4, DES, MD5withRSA, \
#   DH keySize < 1024, EC keySize < 224, 3DES_EDE_CBC, anon, NULL, \
#   include jdk.disabled.namedCurves

Question:

How to comment out (disable) the previous lines in java.security file on Windows and Linux to avoid "Error: javax.net.ssl.SSLHandshakeException", or someone explain to me if there is another solution, different from the one published

windows java linux

1 Answers

  1. Best Answer

    Yes the comment character is # on all systems. The webpage you link is about security policy files, for the SecurityManager (originally designed for applets and now little-used); java.security is not a security policy file.

    Yes do all 3 lines. The continuation syntax (backslash-eol) only works on uncommented lines, so to comment an item continued over multiple (physical) lines, comment each line.

    However, since you now make clear the error is on the protocols, it would be safer to only delete the offending protcol(s) (almost certainly TLSv1(.0) and/or TLSv1.1 -- SSLv3 has been disabled since 8u31 in 2015 after it was catastrophically broken by POODLE) and leave the rest.

    Are you by chance trying to use an old version of javamail? There was a (mis)feature for a while which defaulted secure mode to TLSv1(.0) (only) and triggered this symptom when 8u291 and several other versions came out; we have several existing Qs about it, just search "javamail no appropriate protocol". While removing or reducing the disabledAlgorithms setting (or regressing below 8u291) will allow the client to attempt a TLS1.0 connection, many servers today will not accept it because TLS1.0 is considered broken; that's why Java is now changed to disable it by default. In this case it would be better to upgrade javamail or to explicitly configure mail.{smtp,imap,pop3}.ssl.protocols to a value suitable today probably TLSv1.2,TLSv1.3.

    (Other) Alternatives: in general instead of changing things in JRE/lib/security/java.security which affects all JVMs, you can set system property java.security.properties to point to a different (modified) file separately for each/any JVM e.g. with -D on commandline, or you can call Security.setProperty() in your code sufficiently near the beginning.

    • 1