开发者

Can an unsigned applet talk to a CA-certified SSL server?

开发者 https://www.devze.com 2023-02-13 23:35 出处:网络
We have an unsigned applet that talks to a streaming server (not HTTPS, just socket-socket, but that is not important). All is fine using plain TCP/IP, but when I try to use SSL by the usual:

We have an unsigned applet that talks to a streaming server (not HTTPS, just socket-socket, but that is not important). All is fine using plain TCP/IP, but when I try to use SSL by the usual:

SSLSocketFactory sslsocketfactory = (SSLSocketFactory) SSLSocketFactory.getDefault();
SSLSocket sslsocket = (SSLSocket) sslsocketfactory.createSocket(host, port);

// initiate the handshake (blocks)
sslsocket.getSession();

I get an exception during the handshaking. For ease of development and testing, am running as an application, bu开发者_运维技巧t still get the exception.

Adding the certificate to the keystore fixes this, but we wish to deploy to thousands of clients, without manual intervention.

Have searched the web for days - every mention ends up with "add the certificate to the keystore" but is usually relating to a self-signed certificate. In this case, we've got a pukka certificate (a trial, but is in Java's CA list - digicert to be specific).

In short, can an applet talk SSL to a server that has a CA signed certificate, without having to add that certificate to the keystore?

One idea that comes to mind is adding the certificates or keystore within the JAR that contains the applet. Can an unsigned applet read and install such a certificate/keystore?

thanks,


The idea of using SSL with certificates is that I (in this case the applet) can be certain to who I talk - and no man-in-the-middle is trying to intercept me. For this, it is necessary I already have some certificate of someone I trust, who is in turn certificating the server its identity.

This certificate can either be in the keystore of the Java Plugin (or JRE or user keystore), or you can provide your own keystore with trusted keys to the SSL-engine, like this (copy of source from my project, thus with german comments):

public class SSLHelper
{

   ...

    /**
     * Initialisiert die Client-SocketFactory.
     */
    private void initClient()
        throws KeyStoreException, NoSuchAlgorithmException,
               KeyManagementException, IOException,
               CertificateException
    {
        // die Namen für getInstance() sind aus diesem Dokument:
        //   http://java.sun.com/javase/6/docs/technotes/guides/security/StandardNames.html
        KeyStore keystore = KeyStore.getInstance("jks");
        keystore.load(SSLHelper.class
                      .getResourceAsStream("client-keystore.jks"),
                      null);
        TrustManagerFactory tmf = TrustManagerFactory.getInstance("PKIX");
        tmf.init(keystore);
        SSLContext kontext = SSLContext.getInstance("TLS");
        kontext.init(null, tmf.getTrustManagers(), null);

        clientFactory = kontext.getSocketFactory();
    }
}

This way, the SSL client can compare the sent certificates with the certificates in the given keystore, and if some is matching, the connection is accepted. (We ship here a self-signed certificate of our private CA, which also signs the server-keys.)

Of course, this only shifts the basic problem: now you have to make sure your applet (i.e. the keystore in the jar) is not modified by some man-in-the-middle before execution, instead of making sure everyone has the right certificate already installed. So you should deliver your applet only with HTTPS (and from a HTTPS page) for maximum security.


I haven't been in the situation of deploying "an applet talk SSL to a server that has a CA signed certificate", but I have been in a similar situation of deploying a Java Webstart application requiring signing in order to allow operations out of the sandbox (write and read files on the client machine); we had to deploy it to dozens of customers.

If I remember correctly, the procedure is not difficult (you can google around). You can create your own certificate, but some people will get annoyed with warnings about a certificate signed by "unknown sources."

It is better to use a well know CA authority, for example, VeriSign or Thawte. The CA vary a lot in prices, even though they provide the same thing: certificates.

Verisign is the best known of all CA, and the most expensive. If you contact them, they will help you and guide you through the process, and provide excellent tech support. For example, they provide info about the appropriate strength of the encryption, how install in your applet, server, etc. Plus, you can put their logo on your site, and they send you a t-shirts, nice calendars, and other goodies every year :)

Other providers, such as Thawte, are much cheaper (sometimes half or less) than Verisign. I haven't worked with them, so I can't tell what is the quality of their service.

By the way: it's very important, that the domain and subdomain matches the certificate. If you requested a certificate for domain www.mydomain.com and you try to load the applet from www2.mydomain.com, it will not work. Verisign and other companies provides especial prices for multiple, or unlimited, subdomains.

I hope this helps. Take care,

Luis

0

精彩评论

暂无评论...
验证码 换一张
取 消

关注公众号