I've created a Spring Boot application that I'm running as a poor man's daemon to call another Java service on another tomcat instance. I'm getting an SSL error when connecting to the other Java service but if I hit the other service with something like SoapUi(or Postman) using the same URL and headers I get an OK response. So something must be wrong with my Spring Boot configuration.
I'm using the same JKS for Spring Boot and SoapUI. I've tried using the cert in the application.properties as well as specifying it on the command line using -Djavax.net.ssl.keyStore as well as the related password parameter.
When I run the other service locally without SSL I can connect just fine via my Spring Boot application.
The SSL error I'm getting is: sun.security.validator.ValidatorException: Netscape cert type does not permit use for SSL server
Best I can think is that SoapUI(or Postman) identify's itself as a client application and my Spring Boot identifies itself as a server? So I think I'm asking how can I make Spring Boot identify itself as a client but I'm still not sure I understand the SSL error to begin with.
You have a multitude of problems. First off, soapui doesn't do verification of the server SSL certificate when it connects, java by default does not. You can however configure java client to also ignore server cert verification.
How to ignore depends on what client you use, apache httpclient is the most common one and you can find details on that in this thread.
Now, you should not really do that. Instead, you should have a trust store that contains the certificates that would validate the server cert. In that case you would be interested in truststore configuration, not a keystore - keystore is for other way around, when you're identifying yourself to some other party. You'd need to import the root CA and intermediate certificates to your trust store, then point to that in your configuration.
Related
Is it possible to use Kafka with SSL encryption but with no server verification nor client authentication?
I know that by default the latter is disabled, but is it possible to also disable the former?
I encountered the similar problem. Since kafka is a java process, it will load the default jdk certs when running, which is under /usr/local/jdk/jre/lib/security/cacerts. if your server is trusted there, (in my scenario, my kakfa server is MSK, and is trusted already), then you don't have to config all the keys and certs.
So all in all, I only added kafka config of security.protocol=SSL and it worked.
For my current project i need to implement http over tls at client ,for this i need a local server able to simulate this . is there any online or offline tool. which i can use and and see the handshake in wireshark .
For watching the TLS handshake you might not get far enough with wireshark. For such kind of monitoring you would ensure the security is low enough for wireshark to be able getting the session key from watching the handshake for decoding the later parts. Thus, you need to avoid any forward secrecy.
Otherwise any (https) server that is accessible (and willing to talk) to your client will do.
In case you are in an environment that is supported (e.g. any unix/linux), you might try using openssl. It allows setting up a server that will do handshake. And it will log the handshake such that you will be able looking at what is going on. This will eliminate the need for using wireshark for debugging.
For achieving this you need a Web Server accepting connection over TLS.I have achieved this on Apache Tomcat web Server.
TLS configuration needs to be done in the server.xml file present in config directory of Tomcat webserver. Connector tag needs to be added in the server.xml file that contains information like
TLS version to be used, port, List of supported Cipher Suites, Keystore path and password, Truststore path and password.
Any regular Rest client can be used to make a call like Postman client. But to use that over TLS/SSL certificate is needed to be installed in Chrome browser.
Hope this answers your doubt.
I am dabbling with WCF and SSL and have hit a bit of a problem.
I have a self-hosted WCF service and a basic client which connects to request a token.
I have it set up on my development machine it appears to communicating over SSL just fine.
But when I set it up on a different machine to test the deployment the client keeps getting nothing back from the service.
I assume it has something to do with the certificates I have set up as this is the only thing I think could be different.
I have used the netsh command to associate my port with an existing certificate that was already on the server. And it appears the same as my dev machine (where I created the certificate with makecert manually.
I initially tried to follow the same steps on the deployment server but failed as there was already a certificate with a common name of the server, so eve though the certificate generated when ever I tried to use the cert hash thumbprint of the newly generated certificate I was being given the :
SSL Certificate add failed, Error: 1312
A specified logon session does not exist...
The only way I could get the netsh http add to work was by specifying the cert hash of the existing certificate.
Is this my problem or a red herring? How do you debug issues like this?
Personally I just configure WCF tracing. It usually provides more user friendly info about a problem. Here's a how to link Configuring Tracing
Hope it helps!
We have an Apache servers, edge servers, running as a reverse proxy (in this scenario).
When a user connects to these servers they're required to use SSL X509 certs.
At one point a request has to be made to an ESB running BizTalk 2010.
When the Apache servers pass the request onto BizTalk, Apache is putting the SSL in the header of the message rather than "re-attaching" the SSL certificate, or re-sending the SSL certificate when the request goes out to the ESB. BizTalk is unable to, or I'm not sure how to configure it, read these SSL's that come with the request.
Is there a way of configuring Apache to send SSL's with a message that BizTalk can understand, when Apache is running as a reverse proxy? Or is there a way to configure BizTalk to read these SSL certs that come in the header?
Update:
Is Apache decrypting the entire SSL stack, and that's why it's having a hard time passing the SSL through normally? Is there any way to resolve this?
Someone recommended that we put all the client certs on Apache, and have Apache just load up one of those to and pass that on with the request to BizTalk. Any other ways around this?
You can use S/MIME components with BizTalk to pull off a certificate from a message. It sounds similar to what Apache is doing. Depending on what pipeline component you used, you would specify the certificate details as a property on the component. It is hard to tell you exactly which component (built-in or 3rd party) to use without more information on the the way Apache is doing this.
Is the SSL approach called SSL offloading? I recommend not putting the certs on the Apache server if you can avoid it because it will be more difficult to manage (from an ESB perspective). You would also lose some security between the Apache server and the BizTalk server.
Scenario: calling a client web service over SSL (https) with mutual SSL authentication. Different service endpoint URLs and certs (both keystore and truststore) for test vs. production environments. Both test and production environments run tomcat / JBoss clustered. Production environment has load balancing / BigIP, runs Blade and non-Blade machines.
Truststore is set (using -Djavax.net.ssl.trustStore=value) at startup. Keystore is set using System.setProperty("javax.net.ssl.keyStore", "value") in Java code. Web service call made using Axis2. All works fine in test environment, but when we moved to production environment (6 servers), it appears certs are not being forwarded for the handshake. Here's what we've done:
in test environment, handshake using test versions of certs has been working all along, with no ssl debugging enabled
confirmed in test environment that handshake with client production
endpoint succeeds (production certs,
both ours and theirs, are fine) --
this was done using
-Djavax.net.debug=handshake,ssl
confirmed that the error condition occurs on all 6 production servers
took one server out of the cluster, turned on ssl debugging for
just that one (with a restart), hit
it directly, handshake works!
switched to a different server without the debugging turned on,
handshake error condition occurs
turned debugging on on that second server (with a restart), hit it directly, handshake works!
From the evidence, it seems like somehow the debugging being enabled causes the certificates to be properly retrieved/conveyed, although that makes no sense! I wonder whether somehow the enabled debugging makes the system pay attention to the System.setProperty call, and ignore it otherwise. However, in local and test environments, handshake worked without debugging enabled.
Do I maybe need to be setting keystore on server startup like I'm setting truststore? Have been avoiding that because the keystore will differ for each of our test environments (16 of them).
Turns out that the debug setting was a red herring. What actually bit us was that there was an existing client with an SSL/basic authentication web service we call when one of their users logs in. Since in that context the keystore wasn't relevant, the javax.net.ssl.keyStore property doesn't get set -- but the SSL exchange still tries to load a keyStore (which ends up not loading any certs). Since, unfortunately, even if the javax.net.ssl.keyStore value is changed, it does not get reloaded, calls to the other client's web service sent along no keystore certs.
The solution was to set the keyStore property at server startup rather than at the point of the web service call. If at some point in the future we need to be able to use different keyStores in different contexts, it looks like we'd need to implement a custom SocketFactory.