Our application uses Apache HttpClient 4.5.3 and we are observing a very weird behavior with communication between our client and the server using SNI capability
The server is configured to return a Go Daddy signed certificate if the SSL request comes in the with the server name expected from our client(ie: the host name of the server) and it will return a self signed certificate for all other domain names
Behavior observed
The client receives the correct server certificate on all server except on our production machine
The client code is running in an application deployed on tomcat 8, we have noticed that initial requests to the endpoint go through successfully. After some time of running we receive an SSL exception on the client.
The error is because the server is not sending the correct certificate(it sends the default self signed certificate)
If we restart the tomcat server on which the client is deployed, the calls again start to go through successfully.
We have used javax.net.debug for debugging purposes in the past but we cannot use it in this case as we need to restart the tomcat server for its effect to take place and when we restart the tomcat server, the calls to the endpoint server start to succeed.
Also the javax.net.debug logs a lot of information which will flood our logs and hence we wanted it enabled only for a specific request.
We are hoping to log only the Client Hello(which contains the server_name passed to the endpoint)
I have read through
https://docs.oracle.com/javase/7/docs/technotes/guides/security/jsse/JSSERefGuide.html#OwnX509ETM
But not sure of what we can use to print only the SSL server name indicator pushed down to the server.
I had the same concern as yours, then firstly I was thinking about dynamically adding environment variable, but it's always taking old value. Then I found out that javax.net.debug environment variable is read once only with static block in SSLSocketFactory.java. The full source code is available here.
static {
String s = java.security.AccessController.doPrivileged(
new GetPropertyAction("javax.net.debug", "")).toLowerCase(Locale.ENGLISH);
DEBUG = s.contains("all") || s.contains("ssl");
}
Related
I'm currently facing some troubles by reaching my https-endpoint for my alexa-custom-skill.
My endpoint is an internal PC on my network. For reaching this web server I use a DDNS (<server>.linkpc.net) for my router. The router itself has a port forwarding (443 => internal WebServer Port). That means the current architecture is:
Alexa => Router (.linkpc.net):443 => :
=> RESPONSE => ROUTER => Alexa
I also created a self-signed certificate, that is placed inside a jks and loaded by my WebServer.
This solution works well, by calling the URL (<server>.linkpc.net/xxx/xxx) via browser from outside my network. I receive a message that connection is unsecured due to an untrusted certificate (my self-signed one). But that is a normal behaviour.
I imported the self-signed certificate to own "SSL certificate" via Amazon DEV Console (PEM Format).
From my point of view, everything should be fine, but I get the following error by sending a request to Amazon Dev Console:
"The remote endpoint could not be called, or the response it returned was invalid."
If I'm going to copy the xml-text and insert it into JSON chapter I got:
"There was an exception during the SSL handshake. Please check the
certificate you have provided."
I also created a BreakPoint in Eclipse. It works by using a Browser, but it didn't by using Alexa Dev Console. No response in the code. That means, from my personal point of view, the request is not even reaching my WebServer at all. There are three possible explanations (maybe):
The router provides the wrong certificate to Alexa (strange, because it should not work as a proxy and shouldn't need the self-signed certificate?!)
Self-Signed certificate was wrongly built for Amazon Alexa ?!
A bug inside amazon dev console (unlikely)
Could you please support? :-)
Greetings
Richard
I have a certificate which i need to pass along with the SOAP Request in JMeter.
I have edited the system.properites file to add
javax.net.ssl.keyStore= path to keystore file
javax.net.ssl.keyStorePassword=password
I am still getting the error You need valid client certificate from DHW to access page.
Am I missing somethig here?
The same request is working well from SOAP_UI.
There is a lot that can be going wrong here.
Here is my guess though...
The server is most likely setup for mutual authentication. You can test this by running your java client with the following system property: -Djavax.net.debug=ssl
You should see the ssl handshake and see if the server is requesting a client certificate or not. The messaging will be VERY verbose and you will have to diligently look though the log output to see what is actually occurring.
Hopefully, in the output you will see a list of Certificate Authorities (CAs) that the server trusts. Your client's certificate MUST be signed by one of these CAs. If not, the client won't even attempt to send its client certificate.
If you have access to the server, you can create your own CA and then sign the clients certificate with that new CA and that will work. I actually just did that yesterday. :D
The issue is resolved. I was giving only single backspace instead of two backspaces as per java conventions. It works fine with this minor modification.
I built a Web-Service application in Jdeveloper 11.1.1.7 and deployed it on weblogic 10.3.6 with all Key-store and SSL configuration.
SSl Configuration:
Use Server Certs : Checked
Two Way Client Cert Behavior: Client Certs Not Requested. [That is means it is one-way ssl.
Correct me if that wrong]
SSL Listen Port Enabled: Checked
Key-store Configuration:
Custom Identity and Custom Trust. The file path has been specified for those custom key store
A sample client application has been created and everything seems to be fine; I mean the client can not access the server application without specifying the trust store file location where the server certificate is stored and it is trusted at the client end.
By the server certificate I mean the same certificate that has been configured in server Key-store Configuration
for your information the client application referring to trust store as follow:
System.setProperty("javax.net.ssl.trustStore",[Trust-store location goes here]);
System.setProperty("javax.net.ssl.trustStorePassword", [password goes here]);
Till now nothing wrong. Next is the problem details:
For the purpose of testing I tried to access the deployed web-service application using the SoapUI (open source software). What is confusing is the request has been sent, accepted at the server and proceed without specifying any thing for server certificate nor trust store location in SoapUI project configuration !!
Why the SOAP request has been accepted from SoapUI without referring to server certificate? The request should be rejected in this case.
My experience with SoapUI is that it is quite lenient. For example, if it doesn't check if the CN of server certificate matches the fully qualified domain name in the URL. In your case, your server most likely uses a CA signed certificate. Most of the root and intermediate certificates of well known CA's (e.g. VeriSign/Symantec) are already included in the default truststores for most systems. If your server had used a self-signed certificate, then SoapUI would have incurred SSL error unless you import the self-signed certificates into the truststore of the host where SoapUI is running.
We have configure a Big F5 load balancer virtual server for a particular IP address which redirects incoming https requests to several Windows servers where there is functionality to generate responses.
I am using SoapUI to test access to these windows servers via the IP address of virtual server in the Big F5.
Using Server and Client certificates generated by the organization where the we have also this set up and sending requests via SoapUI I get the predicted responses back.
The business requirements call for Commercially signed certificates by Thawte.
We created a Certifcate Servcice Request (CSR) to generate a Server certificate and its private key and then we had it signed by Thawte, and also requested a Client Commercially signed certificate from Thawte.
We loaded both certificates in SoapUI client and the Big F5 load balancer but we attempting to test the requests we get the "javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake" error.
My questions are:
How can I monitor where exactly the 2 way SSL handshake is terminated
The actual reason what exactly is happening?.. why using commercially signed certificates this does not work now?
Any replies are welcome. Thanks.
However when we swithch Serverto commercially signed by Thawte
This is possibly due to the Java security feature. If so you need to edit the soapui-4.x.x.vmoptions file located at soapui-4.x.x\bin folder and add -Dsun.security.ssl.allowUnsafeRenegotiation=true to the end.
You may also need to export the certificate as a pfx file and set it up in soapUI preference page. For details you can check http://geekswithblogs.net/gvdmaaden/archive/2011/02/24/how-to-configure-soapui-with-client-certificate-authentication.aspx and http://forums.devarticles.com/java-development-38/javax-net-ssl-sslhandshakeexception-received-fatal-alert-handshake-failure-11809.html .
The client is a SoapUI request that has not changed except a different client certificate
That suggests that the server doesn't trust the new client certificate, which in turn implies that the client certificate wasn't even sent because it wasn't signed by one of the server's trusted signers. Closing the connection is the server's only real option in this circumstance, as there isn't an SSL alert for it.
Make sure you have address translation on and the SNAt set to Auto Map for your VIP
I am using https to connect to an https server.
Specifically I am using apache httpclient and I configure the ssl context to use my keystore and truststore.
The https server I am using is IIS7 and is configured to require client authentication.
I think I have set it up properly.
Anyway, if I configure the httpClent's ssl context with a keystore (i.e. with client certificates) valid for IIS then there is no problem connecting.
Now my problem is the following:
If I do not configure the ssl context with any client certificate to send to IIS, there is no connection with the server. What makes me think though, is the fact that I was expecting to see some java exception in the code as a result of a hanshake failure alert.
Monitoring what is happening with wireshark, I could not see a certificate request from IIS to my application, but I noticed that after ServerHelloDone everything was encrypted.
I did not expect that. I think the handshake is usually in cleartext.
I used private key to decrypt traces and i saw a certificate request from IIS but after many starting and opening of new connections.
My app send back as a response a certificate of length 0 and IIS replies with a TLSv1 Finished.
After that the packets stop (i.e. seems that the communication ends).
I was expecting a handshake alert.
My question is, is this how it is supposed to work or at least how IIS works?
Or if I do not see the alert something is wrong with my use case?
Thanks
It sounds like IIS is only requiring client certificates for certain URLs (ie, for example.com/foo, but not example.com/bar).
In the initial handshake, it does not know which url you are requesting, so it does not require a certificate. When it sees that you are requesting a restricted resource (/foo), it then rehandshakes, requiring a certificate.
However, I would still expect a handshake_failure to occur.
As I was saying in an answer to this question, as far as I remember, IIS uses re-negotiation to get the client certificate. You should be able to change this behaviour using netsh and clientcertnegotiate=enable (depending on the version of IIS you're using).
You might also be interest in this similar question.
Failing to supply a certificate in response to a CertificateRequest isn't an SSL protocol error, so there is no handshake_error. 'Requiring' instead of just 'needing' client certificates is added-in by SSL libraries, and all they can do if you don't send one is just close the connection.