I recently added SSL to my website and it can be accessed over https. Now when my java application tries to make requests to my website and read from it with a buffered reader it produces this stack trace
Im not using a self signed certificate the cert is from Namecheap who uses COMODO SSL as the CA to sign my certificate. im using java 8
javax.net.ssl.SSLHandshakeException: No appropriate protocol (protocol is disabled or cipher suites are inappropriate)
at sun.security.ssl.Handshaker.activate(Handshaker.java:503)
at sun.security.ssl.SSLSocketImpl.kickstartHandshake(SSLSocketImpl.java:1482)
at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1351)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1403)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1387)
at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:559)
My code is very basic and simply tries to read the page on my site using a buffered reader
private void populateDataList() {
try {
URL url = new URL("https://myURL.com/Data/Data.txt");
URLConnection con = url.openConnection();
con.setRequestProperty("Connection", "close");
con.setDoInput(true);
con.setUseCaches(false);
BufferedReader in = new BufferedReader(new InputStreamReader(con.getInputStream()));
String line;
int i = 0;
while((line = in.readLine()) != null) {
this.url.add(i, line);
i++;
}
} catch (Exception e) {
e.printStackTrace();
}
}
Ive tried adding my SSL certificate to the JVM's Keystore and Ive also even tried to accept every certificate (which defeats the purpose of SSL I know) with this code
private void trustCertificate() {
TrustManager[] trustAllCerts = new TrustManager[] {
new X509TrustManager() {
public java.security.cert.X509Certificate[] getAcceptedIssuers() {
return new X509Certificate[0];
}
public void checkClientTrusted(
java.security.cert.X509Certificate[] certs, String authType) {
}
public void checkServerTrusted(
java.security.cert.X509Certificate[] certs, String authType) {
}
}
};
try {
SSLContext sc = SSLContext.getInstance("TLS");
sc.init(null, trustAllCerts, new java.security.SecureRandom());
HttpsURLConnection.setDefaultSSLSocketFactory(sc.getSocketFactory());
} catch (GeneralSecurityException e) {
}
try {
URL url = new URL("https://myURL.com/index.php");
URLConnection con = url.openConnection();
BufferedReader br = new BufferedReader(new InputStreamReader(con.getInputStream()));
String line;
while((line = br.readLine()) != null) {
System.out.println(line);
}
} catch (Exception e) {
}
}
Im stumped and any help would be much appreciated!
In $JRE/lib/security/java.security:
jdk.tls.disabledAlgorithms=SSLv3, TLSv1, RC4, DES, MD5withRSA, DH keySize < 1024, \
EC keySize < 224, 3DES_EDE_CBC, anon, NULL
This line is enabled, after I commented out this line, everything is working fine. Apparently after/in jre1.8.0_181 this line is enabled.
My Java version is "1.8.0_201.
I also run into this with the Java8 update 1.8.0.229 on Ubuntu 18.04.
I changed the following part:
# Example:
# jdk.tls.disabledAlgorithms=MD5, SSLv3, DSA, RSA keySize < 2048
#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
jdk.tls.disabledAlgorithms=SSLv3, RC4, DES, MD5withRSA, \
DH keySize < 1024, EC keySize < 224, 3DES_EDE_CBC, anon, NULL, \
include jdk.disabled.namedCurves
I removed TLSv1 and TLSv1.1 from the list of jdk.tls.disabledAlgorithms inside the file
/etc/java-8-openjdk/security/java.security
After checking this:
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 28
Server version: 5.7.33-0ubuntu0.18.04.1 (Ubuntu)
Copyright (c) 2000, 2021, Oracle and/or its affiliates.
Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
mysql> SHOW GLOBAL VARIABLES LIKE 'tls_version';
+---------------+-----------------------+
| Variable_name | Value |
+---------------+-----------------------+
| tls_version | TLSv1,TLSv1.1,TLSv1.2 |
+---------------+-----------------------+
1 row in set (0.00 sec)
mysql> exit
protocol is disabled or cipher suites are inappropriate
The key to the problem lies in that statement. What it basically means is either:
The TLS implementation used by the client does not support the cipher suites used by the server's certificate.
The TLS configuration on the server has disabled cipher suites supported by the client.
The TLS configurations on the client disable cipher suites offered by the server.
TLS version incompatibility between the client and server.
This leads to handshake failure in TLS, and the connection fails. Check one or all of the three scenarios above.
You can add the expected TLS protocol to your connection string like this:
jdbc:mysql://localhost:3306/database_name?enabledTLSProtocols=TLSv1.2
That fixed the problem for me.
Edit 04-02-2022:
As Yair's comment says:
Since Connector/J 8.0.28 enabledTLSProtocols has been renamed to tlsVersions.
In my case I am runnig Centos 8 and had the same issue with Imap/Java.
Had to update the system-wide cryptographic policy level.
update-crypto-policies --set LEGACY
reboot machine.
Thats it.
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/considerations_in_adopting_rhel_8/security_considerations-in-adopting-rhel-8#tls-v10-v11_security
We started experiencing this problem after upgrading to jre1.8.0_291. I commented out "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 java.security located in C:\Program Files\Java\jre1.8.0_291\lib\security which resolved the problem.
javax.net.ssl.SSLHandshakeException: No appropriate protocol (protocol is disabled or cipher suites are inappropriate)
For posterity, I recently bumped up against this using IBM's JDK8 implementation which specifically disables TLS1.1 and 1.2 by default (sic). If you want to see what TLS versions are supported by the JVM, run something like the following code:
SSLContext context = SSLContext.getInstance("TLS");
context.init(null, null, null);
String[] supportedProtocols = context.getDefaultSSLParameters().getProtocols();
System.out.println(Arrays.toString(supportedProtocols));
The code spits out [TLSv1] by default under AIX JDK8. Not good. Under Redhat and Solaris it spits out [TLSv1, TLSv1.1, TLSv1.2].
I could not find any values in the java.security file to fix this issue but there might be some for your architecture. In the IBM specific case, we have to add:
-Dcom.ibm.jsse2.overrideDefaultTLS=true
In my case I had to upgrade the mysql client library to the latest version and it started working again:
<dependency>
<groupId>mysql</groupId>
<artifactId>mysql-connector-java</artifactId>
<version>8.0.24</version>
</dependency>
I have encountered
javax.net.ssl.SSLHandshakeException: No appropriate protocol (protocol is disabled or cipher suites are inappropriate)
error when accessing TLS 1.3 enabled endpoint from a Java 11 application. That is a usual case in GCP, for example.
The problem has gone away without any changes in my code just by upgrading from Java 11 to Java 14.
The Java 11 doesn't deprecate earlier TLS protocol versions by default. Instead of configuring it, simple upgrade of the runtime to Java 14 has helped.
Apparently, if you have TLS 1.0 disabled the emails won't be sent out. TLS Versions 1.1 and 1.2 do not work. Peter's suggestion did the trick for me.
I was face with the same situation on a tomcat7 server, 5.7.34-0ubuntu0.18.04.1, openjdk version "1.8.0_292"
I tried many approaches like disabling SSL in the server.xml file, changing the connection strings etc etc
but in the end all i did was to edit the file java.security with
sudo nano /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/security/java.security
comment out and remove TLSv1 and TLSv1.1
# Comment the line below
#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
# your new line should read as beloew
jdk.tls.disabledAlgorithms=SSLv3, RC4, DES, MD5withRSA, \
DH keySize < 1024, EC keySize < 224, 3DES_EDE_CBC, anon, NULL, \
include jdk.disabled.namedCurves
For ME in this case :
javax.net.ssl.SSLHandshakeException: No appropriate protocol (protocol is disabled or cipher suites are inappropriate)
I found that this is JDK/JRE (Java\jdk1.8.0_291\jre\lib\security) config related, and in order to solve it you need to Disable the TLS anon and NULL cipher suites.
You can found how to do this in the oficial documentation here:
https://www.java.com/en/configure_crypto.html
Also before doing this, consider the implications of using LEGACY algorithms.
upgraded from 1 to 2 + modifying the $JRE/lib/security/java.security file did the trick.
before after mysql driver
Related
I am stuck with an issue of (SSL alert number 46)
140097325019584:error:14094416:SSL routines:ssl3_read_bytes:sslv3 alert certificate
unknown:../ssl/record/rec_layer_s3.c:1528:SSL alert number 46
Above issue comes when I give crl-file in haproxy config.
Usecase
I am using HAPROXY for ssl termination. I had self signed ca.crt,ca.pem,server.crt,server.pem and client.crt,client.key,crl.pem
Working Scenario
I had generated self signed certificate using Certificate Generate
Ha proxy config
global
log 127.0.0.1 local0 debug
tune.ssl.default-dh-param 2048
defaults
log global
listen mqtt
bind *:2883
bind *:8883 ssl crt /etc/ssl/certs/server.pem verify required ca-file /etc/ssl/certs/ca.pem crl-file /etc/ssl/certs/crl.pem
mode tcp
option tcplog
option clitcpka # For TCP keep-alive
tcp-request content capture dst len 15
timeout client 3h #By default TCP keep-alive interval is 2hours in OS kernal, 'cat /proc/sys/net/ipv4/tcp_keepalive_time'
timeout server 3h #By default TCP keep-alive interval is 2hours in OS kernal
balance leastconn
# MQTT broker 1
server broker_1 ray-mqtt:1883 check send-proxy-v2-ssl-cn
# MQTT broker 2
# server broker_2 10.255.4.102:1883 check
This above config working well with and without crl-file while I generate certificate using Certificate Generate
Non Working Scenario
I generate all certificate using Java bouncy castle library.
Client Certi Generate
public static X509Certificate generateClientCertificate(X509Certificate issuerCertificate, PrivateKey issuerPrivateKey, KeyPair keyPair, X500Name dnName, BigInteger serialNumber) throws IOException, OperatorCreationException, CertificateException {
JcaContentSignerBuilder signerBuilder = new JcaContentSignerBuilder(SHA_256_WITH_RSA).setProvider("BC");
JcaX509v3CertificateBuilder builder = new JcaX509v3CertificateBuilder(
issuerCertificate, //here intermedCA is issuer authority
serialNumber, new Date(),
Date.from(Instant.now().plus(100, ChronoUnit.DAYS)),
dnName, keyPair.getPublic());
builder.addExtension(Extension.keyUsage, true, new KeyUsage(KeyUsage.digitalSignature));
builder.addExtension(Extension.basicConstraints, false, new BasicConstraints(false));
X509Certificate x509Certificate = new JcaX509CertificateConverter()
.getCertificate(builder
.build(signerBuilder.build(issuerPrivateKey)));// private key of signing authority , here it is signed by intermedCA
return x509Certificate;
}
CRL Generate
private static X509CRL generateCrl(X509Certificate ca, PrivateKey caPrivateKey, PublicKey caPublicKey,
X509Certificate... revoked) throws Exception {
X509v2CRLBuilder builder = new X509v2CRLBuilder(
new X500Name(ca.getSubjectDN().getName()),
new Date()
);
builder.setNextUpdate(Date.from(Instant.now().plus(100000l, ChronoUnit.HOURS)));
for (X509Certificate certificate : revoked) {
builder.addCRLEntry(certificate.getSerialNumber(), new Date(), CRLReason.PRIVILEGE_WITHDRAWN.ordinal());
}
builder.addExtension(Extension.cRLNumber, false, new CRLNumber(BigInteger.valueOf(4)));
// builder.addExtension(Extension.authorityKeyIdentifier, false, new AuthorityKeyIdentifier(ca.getEncoded()));
builder.addExtension(Extension.authorityKeyIdentifier, false,
new JcaX509ExtensionUtils().createAuthorityKeyIdentifier(caPublicKey));
JcaContentSignerBuilder contentSignerBuilder =
new JcaContentSignerBuilder(SHA_256_WITH_RSA_ENCRYPTION);
contentSignerBuilder.setProvider(BC_PROVIDER_NAME);
X509CRLHolder crlHolder = builder.build(contentSignerBuilder.build(caPrivateKey));
JcaX509CRLConverter converter = new JcaX509CRLConverter();
converter.setProvider(BC_PROVIDER_NAME);
return converter.getCRL(crlHolder);
}
Here, In HAproxy config when I will not include crl-file then It works with the client certificates.
but when I include crl-file into the haproxy config then it will give alert number 46 (sslv3 alert certificate unknown) error.
I had verified using openssl
cat client3.pem | openssl verify -CAfile ca.crt
which returns OK.
Output of openssl s_client -connect haproxy:8883 -cert client3.crt -key client3.key -CAfile ca.crt
CONNECTED(00000005)
depth=1 CN = *.ray.life
verify return:1
depth=0 CN = haproxy
verify return:1
---
Certificate chain
0 s:CN = haproxy
i:CN = *.ray.life
1 s:CN = *.ray.life
i:CN = *.ray.life
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIBujCCASOgAwIBAgIBATANBgkqhkiG9w0BAQsFADAVMRMwEQYDVQQDDAoqLnJh
eS5saWZlMB4XDTIwMDEwNzExMzIyOFoXDTIwMDQxNjExMzIyOFowEjEQMA4GA1UE
AwwHaGFwcm94eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA0CAq/xYcCXWl
PJgs2+DeRRO5DRK813LIiRzdoMFeKrI9X5yXeNFzc6mSAS9EdFITM/HJYSvL/XhZ
p+Hu3N2f9ZR/zD2hpTq2PP0lK3Ev6gryXpWXoJU2SbtOyLsjPmw1y/+xHUjVv5B6
V+m7b0I3RYN8blcJIkjl7Gz83GMlMucCAwEAAaMdMBswDgYDVR0PAQH/BAQDAgeA
MAkGA1UdEwQCMAAwDQYJKoZIhvcNAQELBQADgYEAnmIG9SXICU78Dz2eGbNN2znY
OGCpt7TBDkuXthStAFAyzHxZFKqexkelnJNMg19CbWzxGrPk6lxJQ+ebCGEYZwiZ
/WB9C1fQm+07/FEKVc1TCKv0odpTGRyXno4NePnFz6MCJGfVmec0huVPMD9fAbeJ
DlcWed88CL1MdgmkKoQ=
-----END CERTIFICATE-----
subject=CN = haproxy
issuer=CN = *.ray.life
---
Acceptable client certificate CA names
CN = *.ray.life
Requested Signature Algorithms: ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512:Ed25519:Ed448:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA512:ECDSA+SHA224:ECDSA+SHA1:RSA+SHA224:RSA+SHA1
Shared Requested Signature Algorithms: ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512:Ed25519:Ed448:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA512
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 1440 bytes and written 1488 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 1024 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
139659759231424:error:14094416:SSL routines:ssl3_read_bytes:sslv3 alert certificate unknown:../ssl/record/rec_layer_s3.c:1528:SSL alert number 46
Any help will be very useful for me.
You need to add the AKI and SKI extension in the CA certificate to validate the CRL by HA proxy.
I am using Play 2.5.x (Scala). The default server is Netty. I can't find a way to disable some (weak) specific ciphers as well as client renegotiation.
The Play doc refers to JSSE settings:
https://www.playframework.com/documentation/2.3.x/ConfiguringHttps
How do I use these JSSE settings in a config file ? Or is there a different way to achieve this ?
As described in the documentation, create a properties file (let's call it jvm.security.properties) that looks something like the following:
jdk.tls.disabledAlgorithms=EC keySize < 160, RSA keySize < 2048, DSA keySize < 2048
jdk.tls.rejectClientInitiatedRenegotiation=true
jdk.certpath.disabledAlgorithms=MD2, MD4, MD5, EC keySize < 160, RSA keySize < 2048, DSA keySize < 2048
Then start up the JVM with that properties file:
java -Djava.security.properties=jvm.security.properties
I have a Java Agent running on a Domino Server. It was running fine on version Domino 9.0.1 FP7. The MS Windows server is 2003. Waiting on SQL server version.
Now we upgraded the Domino Server to 9.0.1 FP9. The JVM went from 1.6 to 1.8.
I am assuming this Exception error is caused by the JVM or Java Policy because I upgraded the JDBC driver from 4.2 to 6.2.2 trying to fix this with no success (same error).
Connection String Original (JDBC Driver ...jvm/lib/ext/mssql-jdbc-6.2.2.jre8.jar)
String driver = "com.microsoft.sqlserver.jdbc.SQLServerDriver";
String url = "jdbc:sqlserver://SERVER";
Connection String Same Result (JDBC Driver ...jvm/lib/ext/mssql-jdbc-6.2.2.jre8.jar) - added encrypt=false.
String driver = "com.microsoft.sqlserver.jdbc.SQLServerDriver";
String url = "jdbc:sqlserver://SERVER:1433;encrypt=false;";
The Exception
com.microsoft.sqlserver.jdbc.SQLServerException: The driver could not establish a secure connection to SQL Server by using Secure Sockets Layer (SSL) encryption. Error: "SQL Server did not return a response. The connection has been closed. ClientConnectionId:e8a3a2c4-d9a9-4f82-a63f-967cae0c29f0".
at com.microsoft.sqlserver.jdbc.SQLServerConnection.terminate(SQLServerConnection.java:2435)
at com.microsoft.sqlserver.jdbc.TDSChannel.enableSSL(IOBuffer.java:1816)
at com.microsoft.sqlserver.jdbc.SQLServerConnection.connectHelper(SQLServerConnection.java:2022)
at com.microsoft.sqlserver.jdbc.SQLServerConnection.login(SQLServerConnection.java:1687)
at com.microsoft.sqlserver.jdbc.SQLServerConnection.connectInternal(SQLServerConnection.java:1528)
at com.microsoft.sqlserver.jdbc.SQLServerConnection.connect(SQLServerConnection.java:866)
at com.microsoft.sqlserver.jdbc.SQLServerDriver.connect(SQLServerDriver.java:569)
at java.sql.DriverManager.getConnection(DriverManager.java:675)
at java.sql.DriverManager.getConnection(DriverManager.java:258)
at OrderTrackOrders.NotesMain(Unknown Source)
at lotus.domino.AgentBase.runNotes(Unknown Source)
at lotus.domino.NotesThread.run(Unknown Source)
Caused by: java.io.IOException: SQL Server did not return a response. The connection has been closed. ClientConnectionId:e8a3a2c4-d9a9-4f82-a63f-967cae0c29f0
at com.microsoft.sqlserver.jdbc.TDSChannel$SSLHandshakeInputStream.ensureSSLPayload(IOBuffer.java:774)
at com.microsoft.sqlserver.jdbc.TDSChannel$SSLHandshakeInputStream.readInternal(IOBuffer.java:830)
at com.microsoft.sqlserver.jdbc.TDSChannel$SSLHandshakeInputStream.read(IOBuffer.java:821)
at com.microsoft.sqlserver.jdbc.TDSChannel$ProxyInputStream.readInternal(IOBuffer.java:1003)
at com.microsoft.sqlserver.jdbc.TDSChannel$ProxyInputStream.read(IOBuffer.java:991)
at com.ibm.jsse2.b.a(b.java:272)
at com.ibm.jsse2.b.a(b.java:148)
at com.ibm.jsse2.at.a(at.java:19)
at com.ibm.jsse2.at.i(at.java:627)
at com.ibm.jsse2.at.a(at.java:689)
at com.ibm.jsse2.at.startHandshake(at.java:432)
at com.microsoft.sqlserver.jdbc.TDSChannel.enableSSL(IOBuffer.java:1753)
... 10 more
Prior to Domino FeaturePack 9 this agent ran fine on FP6 and FP8.
This is a security issue related to disabled TLS security cyphers in the FP9 java.security file when connecting to a MS SQL server running on Windows 2003 server.
The solution is to make this change in the java.security file 'Domino Program Dir/jvm/lib/security/java.security'
Change these two lines to remove 3DES_EDE_CBC, DESede
From:
jdk.tls.disabledAlgorithms=SSLv3, RC4, MD5withRSA, DH keySize < 768, 3DES_EDE_CBC, DESede, \ EC keySize < 224
To:
jdk.tls.disabledAlgorithms=SSLv3, RC4, MD5withRSA, DH keySize < 768, EC keySize < 224
Feature Pack 9 makes the following changes to the java.security file in the Domino Program directory on the server:
Domino Program Dir/jvm/lib/security/java.security
Change 1
Prior to FP9:
jdk.certpath.disabledAlgorithms=MD2, MD5, RSA keySize < 1024
Updated in FP9:
jdk.certpath.disabledAlgorithms=MD2, MD5, RSA keySize < 1024, \
DSA keySize < 1024, EC keySize < 224
Change 2
Prior to FP9: jdk.jar.disabledAlgorithms=MD2, RSA keySize < 1024
Updated in FP9: jdk.jar.disabledAlgorithms=MD2, MD5, RSA keySize < 1024
Change 3
Prior to FP9: jdk.tls.disabledAlgorithms=SSLv3, RC4, MD5withRSA, DH keySize < 768
Updated in FP9:
jdk.tls.disabledAlgorithms=SSLv3, RC4, MD5withRSA, DH keySize < 768, 3DES_EDE_CBC, DESede, \
EC keySize < 224
Change 4 (the following entries are NEW in FP9)
jdk.xml.dsig.secureValidationPolicy=\
disallowAlg http://www.w3.org/TR/1999/REC-xslt-19991116,\
disallowAlg http://www.w3.org/2001/04/xmldsig-more#rsa-md5,\
disallowAlg http://www.w3.org/2001/04/xmldsig-more#hmac-md5,\
disallowAlg http://www.w3.org/2001/04/xmldsig-more#md5,\
maxTransforms 5,\
maxReferences 30,\
disallowReferenceUriSchemes file http https,\
minKeySize RSA 1024,\
minKeySize DSA 1024,\
noDuplicateIds,\
noRetrievalMethodLoops
sun.rmi.registry.registryFilter=javax.rmi.CORBA.Stub
Check out java.security, try to comment disabled ciphers (I cannot get exact property now, search for SSL), or this https://blogs.msdn.microsoft.com/dataaccesstechnologies/2016/11/30/intermittent-jdbc-connectivity-issue-the-driver-could-not-establish-a-secure-connection-to-sql-server-by-using-secure-sockets-layer-ssl-encryption-error-sql-server-returned-an-incomplete-respons/
Real solution would be to test 1433 with openssl and check what encryption settings should be used.
How can I disable a particular cipher suite in java.security?
For example, I wish to disable this SSL_RSA_WITH_3DES_EDE_CBC_SHA.
How should I add it in using the command below?
jdk.tls.disabledAlgorithms=SSLv3, RC4, MD5withRSA, DH keySize < 768, \
EC keySize < 224
And finally, how to verify if it is disabled?
Did you try to append the suite name to the end of the line?
According to the post a full cipher suite name or any part of it could be used as a property value.
So, I presume this should work:
jdk.tls.disabledAlgorithms=SSLv3, RC4, MD5withRSA, DH keySize < 768, \
EC keySize < 224, SSL_RSA_WITH_3DES_EDE_CBC_SHA
Found what I wanted here.
Link
I have strange problem, that I could not fixed.
I have JDK 1.5 version and SSL based communication via sockets, simply send and receive string data.
try {
KeyStore ks = KeyStore.getInstance("JKS");
ks.load(new FileInputStream(
"path_to_.jks"),
"secret_of_jks".toCharArray());
TrustManagerFactory tmf = TrustManagerFactory
.getInstance(TrustManagerFactory.getDefaultAlgorithm());
tmf.init(ks);
KeyManagerFactory kmf = KeyManagerFactory
.getInstance(KeyManagerFactory.getDefaultAlgorithm());
kmf.init(ks, "secret_of_jks".toCharArray());
SSLContext ctx = SSLContext.getInstance("TLS");
ctx.init(kmf.getKeyManagers(), tmf.getTrustManagers(), null);
Socket s = ctx.getSocketFactory().createSocket("address_of_server", PORT);
String jsonEx = "json text to send server";
StringBuilder sb = new StringBuilder();
sb.append(jsonEx.getBytes().length);
sb.append("\r\n");
sb.append(jsonEx);
PrintWriter writer = new PrintWriter(s.getOutputStream(), true);
writer.println(sb.toString());
BufferedReader in = new BufferedReader(new InputStreamReader(s.getInputStream()));
System.out.println(in.readLine());
writer.flush();
} catch (Exception e) {
e.printStackTrace();
}
When I use JDK 1.7+ everything works properly, but when I switch into 1.6- it throws javax.net.ssl.SSLException: Connection has been shutdown: javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake
My certificates are 2048 encrypted and I also installed JCE Unlimited Strength Jurisdiction Policy
http://www.oracle.com/technetwork/java/javase/downloads/jce-6-download-429243.html
Here is full exception if some is interested:
javax.net.ssl.SSLException: Connection has been shutdown:
javax.net.ssl.SSLHandshakeException: Remote host closed connection
during handshake at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.checkEOF(SSLSocketImpl.java:1154)
at
com.sun.net.ssl.internal.ssl.AppInputStream.read(AppInputStream.java:65)
at
sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:411)
at
sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453)
at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) at
java.io.InputStreamReader.read(InputStreamReader.java:167) at
java.io.BufferedReader.fill(BufferedReader.java:136) at
java.io.BufferedReader.readLine(BufferedReader.java:299) at
java.io.BufferedReader.readLine(BufferedReader.java:362) at
ConnectorTest.main(ConnectorTest.java:45) Caused by:
javax.net.ssl.SSLHandshakeException: Remote host closed connection
during handshake at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:739)
at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1025)
at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:619)
at
com.sun.net.ssl.internal.ssl.AppOutputStream.write(AppOutputStream.java:59)
at
sun.nio.cs.StreamEncoder$CharsetSE.writeBytes(StreamEncoder.java:336)
at
sun.nio.cs.StreamEncoder$CharsetSE.implFlushBuffer(StreamEncoder.java:404)
at
sun.nio.cs.StreamEncoder$CharsetSE.implFlush(StreamEncoder.java:408)
at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:152) at
java.io.OutputStreamWriter.flush(OutputStreamWriter.java:213) at
java.io.BufferedWriter.flush(BufferedWriter.java:236) at
java.io.PrintWriter.newLine(PrintWriter.java:410) at
java.io.PrintWriter.println(PrintWriter.java:559) at
java.io.PrintWriter.println(PrintWriter.java:670) at
ConnectorTest.main(ConnectorTest.java:43) Caused by:
java.io.EOFException: SSL peer shut down incorrectly at
com.sun.net.ssl.internal.ssl.InputRecord.read(InputRecord.java:321)
at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:720)
... 13 more
ConnectorTest Line 43 is
System.out.println(in.readLine());
Updated
trigger seeding of SecureRandom
done seeding SecureRandom
Allow unsafe renegotiation: false
Allow legacy hello messages: true
Is initial handshake: true
Is secure renegotiation: false
%% No cached client session
*** ClientHello, TLSv1
RandomCookie: GMT: 1439443814 bytes = { 228, 36, 73, 128, 109, 225, 11, 36, 62, 40, 147, 150, 27, 145, 150, 163, 244, 28, 97, 56, 188, 81, 117, 31, 235, 60, 101, 224 }
Session ID: {}
Cipher Suites: [SSL_RSA_WITH_RC4_128_MD5, SSL_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_DES_CBC_SHA, SSL_DHE_RSA_WITH_DES_CBC_SHA, SSL_DHE_DSS_WITH_DES_CBC_SHA, SSL_RSA_EXPORT_WITH_RC4_40_MD5, SSL_RSA_EXPORT_WITH_DES40_CBC_SHA, SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA, SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA, TLS_EMPTY_RENEGOTIATION_INFO_SCSV]
Compression Methods: { 0 }
***
main, WRITE: TLSv1 Handshake, length = 75
main, WRITE: SSLv2 client hello message, length = 101
main, received EOFException: error
main, handling exception: javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake
main, SEND TLSv1 ALERT: fatal, description = handshake_failure
main, WRITE: TLSv1 Alert, length = 2
main, called closeSocket()
Update 2
I just found out that, difference between them are:
Valid from Tue Feb 16 20:07:36 GET 2016 until Thu Feb 16 20:07:36 GET
2017 1.7 Correct
Valid from Tue Feb 16 16:07:36 GMT 2016 until Thu Feb 16 16:07:36 GMT
2017 1.6 Error
After a lot of research, I found out that, there is no way to do this and of course, installing the unlimited policy is also ugly solution. Sun does not recommend us changing policy. The best way to solve that problem is, that always maintain your Java version better then this one. I had to write on 1.5 and had no other chance to simply upgrade system and decided worse but the only solution, that worked, of course. I created some kind of proxy service with Java 1.8 + Wildlfy 8.2 on the same machine with different port of Jboss and call services from there. 1.5 and 1.8 apps communicate with simple soap protocol. Problem "fixed".
Could be that the server does not support the SSL version of the client (client is offering too low SSL version).
Try adding the system property "javax.net.debug=ssl" so you get a better error description into system out. For example:
System.setProperty("javax.net.debug", "ssl");
or add command line parameter:
-Djavax.net.debug=ssl
Why would you want to use older Java? If you must use 1.6 try updating it to the latest patch version.