Обновление Java Keystore и Truststores новыми сертификатами - PullRequest
0 голосов
/ 28 января 2020

У нас есть удаленное java клиентское приложение, которое использует двустороннюю проверку TLSv1.2. Это означает, что сервер аутентифицируется на клиенте, а затем клиент аутентифицируется на сервере.

Это достигается с помощью файлов .jks, которые содержат подписанные сертификаты от центра подписи сертификатов, и с использованием SSLSocketFactory.

Is Можно ли добавить новые сертификаты (из того же органа) в те же хранилища ключей и трастовые хранилища вместе с текущими сертификатами?

Будет ли Java "переключаться" на новые сертификаты после истечения срока действия текущих сертификатов?

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

Например, мы могли бы обновить серверную часть новыми хранилищами, содержащими как текущую, так и новые цепочки сертификатов. Тогда мы могли бы распределить развертывание хранилищ на стороне клиента, содержащее новые цепочки сертификатов, в течение нескольких дней.

Некоторые клиенты получают рукопожатие в текущей цепочке, а некоторые клиенты - в новой цепочке.

Достаточно ли умна реализация SSL, чтобы попробовать все цепочки, доступные в магазинах, и / или в день истечения срока действия текущих цепочек сертификатов Java просто «переключится» на использование новых цепочек сертификатов?

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

1 Ответ

2 голосов
/ 28 января 2020

Можно делать то, что вы хотите, но это требует, чтобы вы или тот, кто обслуживает ваш клиент Java, запрограммировали его. Хранилище ключей, в котором хранятся ваши ключи, может содержать столько пар ключей, сколько вы захотите. Когда TLS согласовывается между сервером и вашим клиентом, сервер может отправить список DN центров сертификации, которые он может принять. Затем ваш клиент решает, какой из них выбрать из вашего хранилища ключей. Реализация по умолчанию Java просматривает список DN, отправленных сервером, и проверяет, соответствуют ли они DN эмитента на сертификатах в хранилище ключей клиента. При обнаружении соответствующего сертификата он выбирается для отправки на сервер для аутентификации. Если два сертификата совпадают, то предпочтение отдается тому, срок действия которого не истек. См. JDK-8132108 для получения более подробной информации. Теперь это поведение по умолчанию. Если вы хотите больше контроля, вам нужно реализовать свой собственный X509KeyManager и реализовать любой лог c, который вы хотите для выбора сертификата клиента.

...