After upgrading Tomcat from 7 to 8.0.26, we are getting SSL connect error in making an https outbound call from our app. The destination site uses Thawte certificate and strangely even curl command in the box to that site is failing with SSL connect error after TC8 upgrade. We don't have ciphers setting in server.xml, so we were using the default ciphers for the JVM with Tomcat 7, and now Tomcat 8 is using HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5 by default. Can the ciphers change cause the SSL connect error in outbound https call or curl command? We had no problem calling the https call before.
Related
Using Kong v.2.8.0-alpine docker version, I get SSL errors "no SNI provided by client, serving default SSL certificate" (which is the internally generated KongHQ cert). My host certificates are loaded against the /certificates endpoint with the desired SNI entries (and viewing the certificate from the admin endpoints show my certificates).
Using a springboot application (v2.6.2) or a standalone java rest client, SSL calls are successful through Kong when the server name (https://this.host.com:8443/some-endpoint) is used as the host. However, when making the same call within the Docker network by referencing https://kong:8443/some-endpoint, the call fails with a handshake failure related to SNI being missing. Viewing the java ssl:handshake debug output, the server_name extensions is present on the fqdn host configuration, but is missing when using the docker container name.
The version of Java used is 1.8_0_212 and 1.11.
I am unable to reproduce this issue with Python or curl.
Is there a way to override the Kong default certificates?
I have a Java11 application that exposes a SOAP endpoint on a Linux Centos7 server. I can call the SOAP endpoint from my localhost successfully via Postman.
https://abx.co/xyz/soapWS
We have a client who when they try call the endpoint (via their SAP system), they get the following error message:
Peer certificate rejected by ChainVerifier
Any ideas please?
I thought the issue may be that that the client needs to ad a certificate to their keysore, but my localhost does not have one, and it works. Do they maybe have to upgrade to a higher version of TLS?
I used self signed ssl on vps for payara (fork of glassfish)
then i duplicated the payara on another server then https on 2nd vps doesnt work
and i create new self signed ssl by this tutorial.
now https works on my application but i cant enable-secure-admin or open payara control panel
it gives me sslhandshake exception.
I wrote a simple app to send email to our smtp server. Java version is 1.8.0_101
Our server use only TLSv1.2. I wrote a simple app to send email to our server. I build this soft as jar and run it. It works normally and java use default tls version which is 1.2 on jdk1.8. Then I wrote a web service that accept request and send email to out smtp server. I use tomcat v9.0(also tested v7 and v8) I build war file and put the tomcat web app folder. But when I call my web service I got the below error
Could not convert socket to TLS.
Remote host closed connection during handshake
Then I realized that java does not use TLSv1.2 and use TLSv1. I tried lots of solution but no ones helped me. I could not change TLS version. Is there any way to change TLS version? Do I change this config on java side or tomcat?
Is there any way to disable the use of TLS v1.1 (and v1) for all SSL configured listeners in Glassfish 4.1? I've tried to set the JVM property
-Ddeployment.security.TLSvX.Y=false
as recommended by this Oracle blog post (https://blogs.oracle.com/java-platform-group/entry/java_8_will_use_tls) but the protocols are still being used in the https negotiations.
Ok, i've found how to do it by messing around with Glassfish command interface.
Run the following commands:
asadmin set configs.config.server-config.network-config.protocols.protocol.http-listener-2.ssl.tls-enabled=false
asadmin set configs.config.server-config.network-config.protocols.protocol.http-listener-2.ssl.tls11-enabled=false
And this will leave only TLSv1.2 enabled. This commands are run against the default HTTPS listener (port 8181), so remember to run against any other secure HTTP listener if you need to.