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.
Related
I've read a lot of articles regarding the import of a cert, but I am still unclear on a couple things.
When connecting to an SSL site from a Java application [in this case, a JBOSS web app], does the client cert need to be explicitly installed on the application server prior?
I can install a client cert manually, but there is an expiration date. So I'll need to manage the expiration dates of all client installed certs on our application server, and take an outage to update each one.
It feels like there should be a better way.
Shouldn't the application automatically accept a valid signed cert? [In this case, it is signed by VeriSign]
We are getting an exception currently when trying to access an https url from the application without explicitly installing the cert.
The API proxy library is swallowing the internal exception, so I dont know the details.
If the cert should be accepted automatically, then there may be a different issue here...
Can a signed certificate be used without importing explicitly?
Yes, it does not need to be installed prior to use. In fact, if you know in advance of what to expect, then you can include that information into the application. That has an added benefit of improving the application's security posture.
To avoid importing the certificate, use a custom X509TrustManager and override checkServerTrusted. In checkServerTrusted, ensure the server's public key is expected (i.e., pin the server's certificate or public key); or verify the server's certificate is valid (i.e., is within validity and forms a chain to your trusted root).
When connecting to an SSL site from a Java application [in this case, a JBOSS web app], does the client cert need to be explicitly installed on the application server prior?
In the case of client certificates, the server advertises the issuer whom it relies upon to issue client certificates. So the server will need to know the trust point for issuing client certifcates for authenticating clients.
In this case, it is signed by VeriSign
This could be really bad. In this case, you will trust all of your clients signed under the Verisign PKI, and all of Verisign's other clients signed under the Verisign PKI.
In this case, it would probably be better to avoid public CAs and run your own PKI (i.e., be your own CA). In this case, pick up a copy of Network Security with OpenSSL. The book will show you how to accomplish the customary tasks using both the openssl command and programmatically.
From the Azure / Windows side ...
When you follow the steps at http://msdn.microsoft.com/en-us/library/windowsazure/ff795779.aspx#upload with ServiceConfiguration.Cloud.cscfg containing, e.g.
<Certificates>
<Certificate name="www.myserver.com"
thumbprint="ad513653e4560fe4afce5bdac88c744fbcf93525"
thumbprintAlgorithm="sha1"/>
</Certificates>
and ServiceDefinition.build.csdef containing, e.g.
<Endpoints>
<InputEndpoint name="HttpIn" port="80" protocol="tcp" />
<InputEndpoint name="HttpsIn" protocol="tcp" port="443"/>
</Endpoints>
<Certificates>
<Certificate name="www.myserver.com"
thumbprint="AD513653E4560FE4AFCE5BDAC88C744FBCF93525"
thumbprintAlgorithm="sha1" />
</Certificates>
and the certificate with this thumbprint is uploaded via the Azure Platform web console to our Hosted service thenthe certificate is deployed to the Server Certificates in IIS when the Azure instance starts. We can RDP into the instance and see the certificate in the Server Certificates of the IIS console.
From the Java side ...
When you connect to the "Windows-MY" keystore in Java with
KeyStore keystore = KeyStore.getInstance("Windows-MY");
keystore.load(null, null);
And then look for the keystores available, you do not see this certificate. If we RDP into the Azure instance and manually add the certificate via certmgr.msc then our Java process does see the certificate using the "Windows-MY" keystore.
I see many examples of Java / Azure certificate integration - e.g. http://blogs.msdn.com/b/avkashchauhan/archive/2010/11/07/adding-ssl-https-security-with-tomcat-java-solution-in-windows-azure.aspx - where the certificate is exported to a keystore file which is then deployed with the azure package, but we would like to find a way whereby the Certificate can be managed independently of the package build and using the standard Azure certificate management approach. Note that we don't have access to the certificate that is to be used, since it is managed by another party.
I also see examples of how to get this certificate using .net code - e.g. How can you get a certificate in code on Windows Azure.
How would you access this Azure deployed certificate directly from Java? Is it deployed into another keystore other than "Windows-MY"? Can you access a certificate from the Server Certificates in IIS directly from Java?
Thanks,
Update (20th May)
We got a tip from someone to use the storeLocation="CurrentUser" in the ServiceDefinition.csdef file, which sounded like it should do the job, e.g.
<Certificate name="www.myserver.com"
storeLocation="CurrentUser" storeName="My" />
However for some reason Azure does not seem to be deploying the certificate to the CurrentUser store. I only see the certicicate deployed to the server if storeLocation is set to LocalMachine (and as described above) this ends up in the Local Machine certificate store which Java doesn't seem to be able to access
According to this article there are only Windows-MY and Windows-ROOT as possible certificate store providers for windows. The Azure-managed certificates are stored in the local machines personal certificates and therefore don't seem to be accessible through the Keystore API.
As a workaround you could either try to get the certificate via native apis (e.g. via JNI or jna) or write a wrapper executable (e.g. written in native c++ or .net) which provides the required certificate to your java process.
You may be able to do something like the following:
Java access to intermediate CAs from Windows keystores?
In that, they are building a certificate chain with certificates from other stores. So using that, I think you will be able to access the certificate.
I have a Java CXF client that connects to a SSL secured Web Service with mutual authentication.
I have my keystore and my truststore properly configured on the client-side and it works fine.
I am concerned here by the fact that my keystore contains only one client certificate and on the CXF configuration it is not possible to say "ok for this SSL communication you'll use this certificate".
As I only have one certificate it's not difficult to choose the good one for CXF durign SSL handshake.
But this client will be deployed in a environment where it will be used with multiple possible client having their own certificate and each of them will be signed by the same certification authority. When the server will ask for a client certificate that is signed by a specific authority, there will be no way to distinguish one certificate from another.
How can I tell CXF (or Java) to use the proper certificate in this context?
Do I need to build as many SSL context as client certificates? (ie. having N keystore each of them containing only one certificate).
Or is there a way (in CXF conf or in Java) to say "use this certificate in this context"?
Thanks in advance for your help.
All the certificates must refer to the same client, otherwise the CAs are derelect in their duty. So they should all have for example the same subjectX500Principal. So why do you need a specific certificate? All of them identify the same client, so from an authentication point of view they are all equivalent.
It's starting to sound as though you want to use a particular certificate for authorization purposes, not just to establish identity via authentication. If so it is the wrong approach, a misuse of PKI. Authorization is an application-controlled step once you have an authenticated identity: get the identity of of the peer certificate and look up your authorization database to see if that identity is allowed to access this part of the application. Don't try to use a cacerts file as an authorization database, that's not what it's for.
I don't know if this is an option for you but I've done dynamic alias selection using WSIT before (i.e. one keystore, many private key entries). See this article for more detail. (Let me know if that article isn't enough - I can post more detail if you need)
I have a web application that downloads a jar file from the web server using java web start. The jar is signed using J2SE security tool. However, I get the security warning "The application digital signature cannot be verified. Do you want to run the application?"
Am I missing something that is causing this??
If it is self-signed you also need to add the certificate into windows certificate store.
If you use a Certificate Authority such as Verisign then you will not have the problem.
See here for an explanation (from Verisign) on why to sign from them.
I've generated a self-signed certificate for my Java app using keytool. However, when I go to the site in a browser it always pops up with a warning - saying this site does not own the certificate - is there a way to self-sign/doctor a certificate so I won't get these warnings in a browser? Both server and browser are located on the same host and I navigate to the site using "http://localhost/". I do not want to add an exception to the browser because I have tests which run on a big build farm so it is excessive to add an exception to all browsers on all build machines.
No, you can't. You might as well ask "How can I make a fake certificate for hsbc.com?"
There are two ways to get a browser to accept a certificate:
Buy a certificate for a domain from a trusted authority (which means proving to that authority that you own that domain) and then use that domain as the name of your test servers
Install your signing certificate into the browsers, so that you effectively become a trusted authority for that browser.
Without touching the browsers, there's no other way to do it - how could there be, if the internet is to remain secure?
You could also setup a self-signed Certificate Authority (CA) using OpenSSL or possibly your Java tool. You can then use that CA to sign a number of server certs.
You are still going to need to manually trust your self-signed CA on all clients that access your test servers, but at least you only have to trust one root CA, rather than a bunch of individual self-signed server certs.
Another option is to check out CAcert.
Is the certificate you created for localhost or for test.textbox.com? If you create a certificate for the FQDN test.textbox.com, that's how you need to be reaching the server to not get those errors, as long as the certificate is properly signed. You can't generate a certificate for the FQDN and then use an IP or an alias (localhost) to access it without being warned that things aren't matching up properly. Or am I misunderstanding your problem?
Make the certificate for "localhost" instead. It needs to match the hostname you have in the URL.
You will still be bothered as the certificate is not trusted, but that is another issue.