SSL: как обрабатывать несколько клиентов с отдельными ключами, подключающимися к одному и тому же порту?

Еще одна устаревшая проблема поддержки здесь!
У нас есть серверная сеть с несколькими клиентами, где каждый компонент имеет самозаверяющий сертификат и добавляется в хранилище доверенных сертификатов сервера/клиента. Мы не используем центр сертификации.
Теперь наша проблема заключается в том, что нам нужно обновить все сертификаты для большей безопасности. Новые клиенты будут поставляться с более новыми сертификатами, и даже сервер будет иметь новые сертификаты.
Наша проблема заключается в том, как обращаться со старыми клиентами. Обновление хранилищ ключей наших старых клиентов — это последнее средство.

Вещи, которые не будут работать:

  1. Добавление нового и старого сертификатов в хранилище доверенных сертификатов сервера: даже клиенты аутентифицируют серверы, и сертификат сервера не будет присутствовать в хранилище доверенных сертификатов клиента.

  2. Использование нового порта для новых клиентов: мы рассматривали возможность использования новых портов для новых клиентов и сохранения старых портов для старых клиентов, но проблема в том, что существует несколько приложений, которые сталкиваются с этой проблемой, поэтому нам придется искать несколько новых портов, которые не используется другими продуктами.

FWIW: серверы на Java, а клиенты на C++.

ИЗМЕНИТЬ после ответа EJP
Вероятно, я задаю здесь очень глупый вопрос, но просто хотел убедиться. Нет абсолютно никакого способа редактировать SSL-контекст сокета после его привязки. Верно?
Кроме того, можем ли мы выбрать сертификат сервера, который будет использоваться во время рукопожатия? Я знаю о методах chooseClientAlias() и chooseServerAlias(), но здесь мы не знаем, какой сертификат использовать, пока не будет отправлено приветственное сообщение клиента.


java ssl x509certificate certificate-store
person Limit    schedule 10.06.2016    source источник

Ответы (1)


arrow_upward
2
arrow_downward

Оставляя в стороне использование разных портов:

  1. (1) будет работать, поскольку сервер связан с клиентскими сертификатами.
  2. Ничто не поможет старым клиентам распознавать новый сертификат сервера, кроме обновления клиентских доверенных хранилищ.

Вот почему вы должны были использовать центр сертификации, даже внутренний, и почему вы не должны ни в коем случае совершать ту же ошибку снова. Если бы клиенты доверяли ЦС, а не самозаверяющему сертификату сервера напрямую, у вас не было бы этой проблемы сейчас и не будет в будущем, сколько бы раз вы ни обновляли сертификаты, пока не истечет срок действия сертификата ЦС, что должно пройти 20 лет.

И пока вы это делаете, убедитесь, что вы создали способ обновления клиентских доверенных хранилищ.

Нет абсолютно никакого способа редактировать SSL-контекст сокета после его привязки. Правильный?

Невозможно изменить SSLContext после его инициализации, что предшествует созданию сокетов, не говоря уже о их привязке. Хм, может быть, вы могли бы перезагрузить KeyManager и TrustManager и просто не говорить SSLContext, но я не говорю, что это сработает (или не сработает).

Кроме того, можем ли мы выбрать сертификат сервера, который будет использоваться во время рукопожатия?

Да, для этого и нужен интерфейс KeyManager, а именно chooseServerAlias().

Я знаю о методах chooseClientAlias() и chooseServerAlias(), но здесь мы не знаем, какой сертификат использовать, пока не будет отправлено приветственное сообщение клиента.

chooseServerAlias не вызывается до тех пор, пока не будет получено ClientHello.

person user207421    schedule 10.06.2016
comment
Я согласен с вашей точкой зрения на использование ЦС. Я обновил вопрос еще одной обсуждаемой темой. Можете ли вы ответить и на это? - person Limit; 10.06.2016
comment
Я попробую метод ChooseServerAlias(). Думаю, это должно решить нашу проблему. Используйте старые ключи для старых агентов и новые ключи для новых серверов. По крайней мере, пока у нас не будет архитектуры CA. - person Limit; 10.06.2016