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?
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 get (http) request in my Java code, in localhost I can run normally, my code works, but in production I get no response. Returns error 500.
When I test my production request by Postman, it returns a message missing SSL certificate. My questions are how to solve this problem and is the error possible due to lack of SSL?
My production site does not have SSL certificate
I posted this issue and i could solve it deleting from the WebLogic startups parameter the next:
-Djsse.enableSNIExtension=false
Can someone explain this?
The parameter -Djsse.enableSNIExtension=false disables SNI.
Let's say you go to endpoint endpointaaa.com/aaa. Behind this endpoint endpointaaa.com there could be multiple application servers, all with their own certificate. So /aaa could point to server A and /bbb sould point to server B. SNI let's you send the endpoint you are trying to reach in it's initial contact (SSL handshake I think?). This will let the receiving end know, to which application server you are trying to connect, so it can response with the right certificate.
If SNI isn't enabled, it's possible that a different application server responds with a different certificate.
We are trying to access a restful web service resource hosted on IIS server with https protocol.
When we disable TWO WAY SSL Auth (server side validation of client certificate disabled) everything works fine.
When the IIS imposes TWO WAY SSL (server side validation of client certificate enabled) we are getting the below exception:
403 - Forbidden: Access is denied.
You do not have permission to view this directory or page using the credentials that you supplied.
We are using java 1.8 update 102, IIS server 7.5 and TLS 1.2 for ssl
For detailed issue please open the below link:
For details SSL Debug log, certificates, client program
It will be great help if someone help us.
Thanks!
See this warning in the SSL log:
no suitable certificate found - continuing without client authentication
Your server is sending a list of accepted CAs to request a client certificate, but your client does not find a suitable one. It seems your keystore has the correct certificate. Ensure that your certificate is correct, for example installing it in the browser and navigating to a protected resource
May be it is a configuration issue of your Java client. Please read HttpClientBuilder documentation carefully
System properties will be taken into account when configuring the default implementations when useSystemProperties() method is called prior to calling build().
You did not call useSystemProperties().
See also this bug report that might affect you https://issues.apache.org/jira/plugins/servlet/mobile#issue/HTTPCLIENT-1477
I am connecting to a WCF web service with a Java client I am constructing. Someone else has already successfully built WCF clients to connect to this service. The WSDL available via HTTP provides Message Level Security. The WSDL available via HTTPS uses both TLS and Message Level Security. I understand that using TLS on top of Message Level Security is basically dual-encrypting, but that is a key requirement.
Since I can connect to the HTTP service correctly, I believe I have all the trust store and key store issues resolved.
I am connecting to the service using Metro 2.1.1. I have built the client in both Eclipse and Netbeans. I fetch the WSDL from the HTTP site, and using wsimport (with the -extensions flag) I build and execute the clients successfully.
When I fetch the WSDL using the HTTPS site I can again build both clients successfully. But when I execute them - I get the following error:
Exception in thread "main" javax.xml.ws.soap.SOAPFaultException: An error occurred when verifying security for the message.
at com.sun.xml.ws.fault.SOAP12Fault.getProtocolException(SOAP12Fault.java:225)
at com.sun.xml.ws.fault.SOAPFaultBuilder.createException(SOAPFaultBuilder.java:122)
at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:119)
at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:89)
at com.sun.xml.ws.client.sei.SEIStub.invoke(SEIStub.java:140)
at $Proxy43.request(Unknown Source)
The only difference between the two WSDLs (the one fetched via HTTP and the other via HTTPS) is the reference in the WSDL to HTTPS:// vs. HTTP://.
I do not have easy access to the WCF service logs - normally there is a 3-6 hour delay between when I request a set of logs and when I can view them.
My question is has anyone encountered a similar circumstance - and is there something I am blatantly missing here? Is there something in a NetMon or Wireshark trace I can look for to see that the issue is? I have been struggling with this for days - any help would be most appreciated.
If you have access to the service configuration try disabling security context on the endpoint you're using:
<message establishSecurityContext="False" clientCredentialType="UserName"/>
You can read more about security context token (SCT):
Security Context Token
Message security knobs
Java client for WCF service with wsHttpBinding over SSL