Может ли неподписанный апплет общаться с сертифицированным CA сервером SSL?

Question

У нас есть неподписанный апплет, который общается с потоковым сервером (не HTTPS, просто сокет-сокет, но это не важно).Все нормально, используя обычный TCP / IP, но когда я пытаюсь использовать SSL обычным образом:

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

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

, я получаю исключение во время рукопожатия.Для простоты разработки и тестирования я работаю как приложение, но все еще получаю исключение.

Добавление сертификата в хранилище ключей исправляет это, но мы хотим развернуть его на тысячах клиентов без ручного вмешательства.

Проводил поиск в сети в течение нескольких дней - каждое упоминание заканчивается «добавить сертификат в хранилище ключей», но обычно относится к самозаверяющему сертификату.В этом случае у нас есть сертификат pukka (пробный, но он есть в списке CA в Java - точнее, digicert).

Короче говоря, может ли апплет передать SSL серверу, подписанному CAсертификат, без необходимости добавления этого сертификата в хранилище ключей?

Одна идея, которая приходит на ум, - это добавление сертификатов или хранилища ключей в JAR-файл, содержащий апплет.Может ли неподписанный апплет прочитать и установить такое хранилище сертификатов / ключей?

спасибо,

Answer 1

Идея использования SSL с сертификатами заключается в том, что я (в данном случае апплет) могу быть уверен в том, с кем я разговариваю, и ни один посредник не пытается меня перехватить.Для этого необходимо, чтобы у меня уже был сертификат кого-то, кому я доверяю, который, в свою очередь, сертифицирует сервер на его идентичность.

Этот сертификат может находиться либо в хранилище ключей плагина Java (или в JRE или хранилище ключей пользователя), или вы можете предоставить собственное хранилище ключей с доверенными ключами для SSL-движка, например так (копия источника из моего проекта , то есть с комментариями на немецком языке):

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Кстати, клиент SSL может сравнивать отправленные сертификаты с сертификатами в данном хранилище ключей, и, если некоторые из них совпадают, соединение принимается.(Мы отправляем здесь самозаверяющий сертификат нашего частного ЦС, который также подписывает ключи сервера.)

Конечно, это только меняет основную проблему: теперь вы должны убедиться, что ваш апплет (т.е.хранилище ключей в банке) не изменяется каким-либо посредником перед выполнением, вместо того, чтобы убедиться, что у всех уже установлен правильный сертификат.Таким образом, вы должны доставлять свой апплет только с HTTPS (и со страницы HTTPS) для максимальной безопасности.

Answer 2

Я не был в ситуации развертывания «SSL для апплета» на сервере, у которого есть сертификат, подписанный ЦС », но я был в подобной ситуации, когда развертывалось приложение Java Webstart, требующее подписи, чтобы разрешить операции вне песочницы (запись и чтение файлов на клиентском компьютере); нам пришлось развернуть его для десятков клиентов.

Если я правильно помню, процедура не сложная (можно погуглить). Вы можете создать свой собственный сертификат, но некоторые люди будут раздражены предупреждениями о сертификате, подписанном «неизвестными источниками».

Лучше использовать хорошо известные полномочия CA, например, VeriSign или Thawte. ЦС сильно различаются по ценам, хотя они предоставляют одно и то же: сертификаты.

Verisign является самым известным из всех CA и самым дорогим. Если вы обратитесь к ним, они помогут вам, проведут вас через весь процесс и предоставят отличную техническую поддержку. Например, они предоставляют информацию о соответствующем уровне шифрования, о том, как установить ваш апплет, сервер и т. Д. Кроме того, вы можете разместить их логотип на своем сайте, и они отправят вам футболки, красивые календари и другие вкусности. каждый год :) 1007 *

Другие поставщики, такие как Thawte, намного дешевле (иногда вдвое меньше), чем Verisign. Я не работал с ними, поэтому я не могу сказать, каково качество их обслуживания.

Кстати: очень важно, чтобы домен и поддомен соответствовали сертификату. Если вы запросили сертификат для домена www.mydomain.com и пытаетесь загрузить апплет с www2.mydomain.com, он не будет работать. Verisign и другие компании предоставляют специальные цены для нескольких или неограниченных поддоменов.

Надеюсь, это поможет. Береги себя,

Луис