Вопрос # 1: Могу ли я хранить несколько сертификатов (приватных ключей) в хранилище ключей, которое я буду загружать позже в моем механизме FIX?
Что касается Java, вы определенноможет иметь несколько записей privateKey, каждая из которых содержит приватный ключ плюс сертификат или (обычно) цепочку, в одном файле хранилища ключей или другом объекте хранения. (Обратите внимание, что если вы используете PKCS12 для обмена с другим программным обеспечением , то другое программное обеспечение может не поддерживать несколько записей в одном PKCS12. Если вы используете PKCS12 только для большей безопасности в Java или для отключения предупреждений в j9 +, этоэто не проблема.)
Я не знаю, какой механизм FIX вы используете, или как он обрабатывает информацию о ключах и сертификатах для TLS-ранее-SSL (или вообще, как он вообще обрабатывает TLS). ). Если он просто загружает файл хранилища ключей (или поток) в качестве объекта хранилища ключей, применяется вышеописанная возможность Java. Если он делает что-то еще, то, что он может сделать, зависит от этого чего-то другого.
Вопрос № 2: Если ответ на вопрос № 1 - да, то как контекст SSL выберет сертификат клиента во время рукопожатия SSLкогда он устанавливает SSL-соединение с сервером?
В протоколе TLS, когда сервер запрашивает у клиента использование сертификата, он определяет ограничения алгоритма (алгоритмы конечного ключа через 1.2 и / илиалгоритмы подписи цепочки в 1.2 и 1.3) и могут указывать список требуемых центров сертификации (CA) (которые могли выдать любой сертификат в цепочке).
Если ваш клиент (механизм FIX) использует стандартную реализацию Java TLS (JSSE) со своим стандартным (и по умолчанию) KeyManager SunX509, который выберет из хранилища ключей запись, удовлетворяющую вышеуказанным ограничениям изсервер;если вы выбираете или конфигурируете KeyManager 'NewSunX509' или 'PKIX', он также проверяет все ограничения алгоритма, определенные для вашей JVM (например, Oracle JVM, начиная с приблизительно 2017 года, запрещает сертификаты с использованием сигнатур на основе MD5 или SHA1 или ключей RSA менее 1024). биты) и отдает предпочтение записям, для которых срок действия сертификата не истек и у него нет неподходящих расширений KeyUsage или ExtendedKeyUsage. Среди множества приемлемых или предпочтительных записей выбор является произвольным - однако реализация хранилища ключей перечислила их. Большинство серверов поддерживают все стандартные (возможно, и не устаревшие) алгоритмы и, как правило, этим не различаются. Если сервер принимает сертификаты от «общедоступных» CA, таких как Digicert, GoDaddy, LetsEncrypt, они также вряд ли различаются, но если он использует CA (или, возможно, несколько), специфичные для этого сервера или его оператора, такие имена CA будутчасто являются уникальными, и поэтому ключ и сертификат будут выбраны только для этого сервера.
Если ваш клиент использует пользовательский KeyManager - либо явно в вашем приложении, либо через промежуточное ПО (например, Apache HttpClient) -это может сделать что-то другое. Он может даже выбрать использование ключа и сертификата, который сервер отклонит, хотя это обычно не считается полезным.
Если ваш клиент использует другую реализацию TLS, он может использовать стандартную структуру KeyManager, возможно, с указанными выше параметрами, или может делать что-то еще.