I have a desktop application who access webservice with mutual authentication. The authentication uses System.setProperty and it works.
But I have to create physical file from my certificate and sometimes users change permissions in program's folder and also, is not safe to create physical file. I'm using an A1 certificate.
Is there way to access the webservice putting the certificate in memory or something like this?
Related
I need to call a webservice from a Java stand-alone application. The webservice requires client-auth access and it has a https:// url.
The user of the application should provide a p12 certificate and a pin code in order to gain access to the webservice.
The customer provided me an example certificate to test the webservice, but I actually have no idea how to implement it.
In the real application the certificate is stored in a smartcard (pkcs#11).
Where should I have to see to find a howto or some examples? Thanks...
i have an existing java client code which calls an asmx webservice. However the asmx webservice is being deprovisioned and is migrating to a secure webservice(svc).
As far i can understand i have to change the endpoint url and https from http in the url.
and then recreate the client code using the new WSDL.
However i also have to send a certificate along with every request, can anyone help me on how to do that using java?
Let me know if you need more information.
Many Thanks
You have to import the public key of the server you want to communicate in the client trust store. JDK provided Keytool can be used to import certificate into the truststore.
You have to specify the trust store details in the client VM. The following parameters have to bet set on the client VM to specify the trust store:
javax.net.ssl.trustStore - The location of the trust store file which has the public keys of the servers it wants to communicate.
javax.net.ssl.trustStorePassword - The passowrd of the trust store.
References:
Java SSL
Key Store Vs Trust Store
I'm running Apache Tomcat locally and have installed a self signed certificate using OpenSSL. I also have a servlet running.
What I want to do is the following:
The servlet takes in POST parameters and will echo back the parameters signed using the PrivateKey of the server. That is, treat the input parameter as an integer and raise it to the power of the private key.
The problem: Is it even possible to access the server's PrivateKey from the servlet? If deployed on some other hosting, it's probably not possible to access it directly. So is there any way that I can request that the server 'sign' some piece of data with its Private key?
Thanks in advance.
If I were writing a weberver I'd go to great lengths to prevent code from reading from the certificate store - I certainly wouldn't provide an API call for it!
Usually the cert is stored as a file on the webserver's filesystem (not always) but for a site with any serious security on it, this would be encrypted and require a passphrase to decrypt. Since you are using a self-signed certificate its probably not encrypted - just import the cert from the file into the keystore.
This depends on the way the container is configured. In the general case, the SSL configuration of the container will not be accessible by a servlet it contains. For example, in Apache Tomcat, that connector's SSL configuration can be completely independent of the settings accessible by a servlet. (In addition, SSL may be handled by APR or an Apache Httpd front-end, for example, which won't have much to do with the Java keystore configuration).
You would probably be able to gain access to the keystore if they are configured using the javax.net.ssl.* properties. However, that's not necessarily the way the SSLContext of the server connector is configured from. It's not generally a good idea to pass those parameters on the command line either in a production environment.
What you may be able to do is to load the keystore used by the container, from your servlet, but you'd have to know where it is, in advance. In addition, I would suppose that a hosting service would run Tomcat with a security manager turned on, which may prevent you from doing this.
Note that you could use your own keystore, shipped within your webapp (it can even be loaded from the classpath as a resource stream). Whether this keystore will contain the same private key as the one use by the server's SSL layer is up to the server's administrators (if they let you have it).
If you use a Java keystore you can access it from your servlet, as long as it knows the keystore location and password.
Servlet can access any data on your machine including keys. The only situation can be when Apache and Tomcat are running from different user names and keys are locked to be accessed only by Apache user name. You can do a trick in this case as su a process under Apache user name and read the file.
In case of webapplicaiton I can understand that there is no difference between the client authentication and user authenticaiton; Ignoring XSS and other exploits the web client is generated by the server/servlet.
But suppose you have a Java client application talking to the Java Server application; The server has a certificate associated with it so that the client can validate and verify if server is trusted. Now client also has a certificate (client cert) so that the server can verify if this is a trusted client; Once this mutual authentication is done, instead of presenting a username/password dialog to the user, the users certificate (user cert) can be passed to the server.
Question is whether there is any advantage/use in this case in having a (client cert); Or will the user certificate alone will suffice to trust the client as well ??
I know this is an obvious question/ but cant a rouge client application be created ?? So will the client cert protect against this scenario.
Any time you have a client server application the server needs to assume the client is compromised. When an authentication occurs (username/password, certificate, etc... it doesn't matter) the server should grant the user certain permissions to use the functionality of the server. Whenever a request is made to the server the server needs to check whether the authenticated user has the permission to perform that action.
Trusting the client to only make authorized requests opens yourself up to attacks. If you check permissions on the server and scrub inputs then you don't have to worry about whether the user is using a trusted client because even an untrusted client won't be able to do more than the trusted client could with the same authentication credentials.
These principles apply regardless of wether you are using a web client or a stand alone client. Even in a web app I can write a new client and POST data, use RESTful services, or generally talk to the web server and completely bypass the web ui you present to me.
If some attacker gets to alter in some way the client application, it could use the valid user certification to access the server.
The server should verify the client app, not for server sake (we assume the server checks if client can do this or that operation, but for ensuring the client is not being phished by a bogus client). Then the server can proclaim that all operations made by client-1 we're made through some verified client-app (agent) so they were really intended by the user.
The client application's certificate (and it's private key) can be easily ripped off the application and rogue application can be created. The ways to counteract this are (a) use user's certificate and let the user provide it when needed and (b) use a USB cryptotoken to store the client certificate and it's private key. Cryptotokens don't let the private keys out so the attacker can't copy it (though he can use the token with his application, if he has physical access to the token).
I have a swing application deployed in HTTP Server. Users use the browser to point an URL and install the client using java webstart. Now I need to enable https access to my application deployed on HTTP server. I am using JDK 1.5 as default jdk supported in the jnlp file. For time being I use a self signed certificate to the sign the jars (by default created using Sun's jarsigner, keytool, etc, utils).
Solution/steps would be much appreciated.
Thanks in advance
Ramesh
As far as I understand your question you don't need to change anything to your code of the client. If you only want to give access to the JNLP via HTTPS you would only need to reconfigure the application server distributing the JNLP or if you have a webserver in front of the application server (as we do here: user - https -> apache -> AJP -> tomcat) you need to reconfigure the webserver to allow the access to the JNLP via HTTPS.
You need to enable HTTPS on the web server. To get the certificate you need to provide credentials and the host name of the server to a certificate authority (CA) like VeriSign or Thawte. They can provide you with a server certificate signed by their root certificate or some intermediate certificate. This certificate must then be imported into the web server to enable HTTPS over SSL. The web clients, like a browser or webstart will then verify the certificate chain when accessing the server.
If you use a self signed jar, all your users will be presented with a warning message about potentially unsafe code. To avoid this you should get a code signing certificate from a CA, which would be somewhat similar to the web server certificate. This CA-provided certificate can be imported into the keystore and used in the same way you use the self signed certificate. The code signing certificate will be signed by the CA so that the certificate chain can be verified by webstart.
What is the feature of https that you are hoping to leverage?
The signing/server authentication is done by code signing, though you are undermining this using a self-signed certificate.
Does your application code contain secrets that must be hidden from eavesdroppers?
As you say you "need to enable" there must be an underlying reason.
I believe that before you "need https" you need a proper code signing certificate. You might want to rephrase your question so that your underlying problem can be solved instead of the very specific question.