Работа с клиентом, у которого возникли проблемы с настройкой взаимного TLS (клиентских сертификатов). По моему опыту, аутентификация клиента TLS работает, когда сервер имеет сертификат и сообщает клиенту о необходимости отправить сертификат, подписанный этим первым сертификатом. Клиент отправляет один (что-то подписывает), и сервер это проверяет.
Клиент пытается использовать сертификат CA в хранилище доверенных сертификатов сервера. В их случае любой может запросить сертификат у этого центра сертификации. Таким образом, это не будет работать с вышеперечисленным - поскольку любой может получить сертификат идентификации от CA и подключиться.
Такое поведение кажется стандартным для Java. Раньше я применял именно такой подход - использовать промежуточный сертификат или другой центр сертификации, которым можно управлять.
Я знаю, что пользовательский Java TrustManager может быть реализован на клиенте для отправки любого сертификата, независимо от его происхождения. Я также знаю, что curl сделает это (игнорируя центр сертификации в CertificateRequest). При таком подходе вы можете использовать удостоверение личности, а не ЦС, поэтому клиент и сервер могут использовать один и тот же сертификат независимо от его происхождения.
Какая здесь лучшая практика? Делает ли клиент разумный запрос? У нас также есть сервер Windows, который нужно настроить дальше, и я не знаю, как он справится с этим.
Редактировать: RFC, похоже, делает такое поведение необязательным.
certificate_authorities: список отличительных имен [X501] допустимых сертификатов_authorities, представленных в формате DER. Эти отличительные имена могут указывать желаемое отличительное имя для корневого CA или для подчиненного CA; таким образом, это сообщение можно использовать для описания известных корней, а также желаемого пространства авторизации. Если список certificate_authorities пуст, то клиент МОЖЕТ отправить любой сертификат соответствующего ClientCertificateType, если только не существует противоположной внешней договоренности. https://tools.ietf.org/html/rfc5246#section-7.4.4
Нет никаких технических причин, по которым ЦС, используемый для сертификата сервера, должен быть тем же ЦС, который используется для клиентских сертификатов.
Может быть какая-то причина, по которой вы желаете и требуете через конфигурацию это для конкретной среды, но технически это не требуется.
Клиент определяет центры сертификации, которым доверяет клиент (или они используют хранилище сертификатов из операционной системы / браузера). Сервер обычно может делать то же самое. Используйте все центры сертификации, которым доверяет ОС, или доверяйте определенным центрам сертификации.
Если вам нужно потребовать, чтобы все клиентские сертификаты были подписаны определенным центром сертификации, вы, безусловно, можете это сделать.
Специфика того, как вы устанавливаете центры сертификации, которым доверяет ваш сервер, полностью зависит от вашего серверного программного обеспечения, о котором вы не упомянули, кроме «Windows».
В их случае любой может запросить сертификат у этого центра сертификации. Таким образом, это не будет работать с вышеперечисленным - поскольку любой может получить сертификат идентификации от CA и подключиться.
Это будет зависеть от серверного программного обеспечения, которое вы используете, и от того, доверяете ли вы центру сертификации. Но для некоторых серверов вы можете установить ограничения на основе данных, включенных в сертификат клиента. Например, вы можете потребовать, чтобы пользователи получали сертификат от определенного центра сертификации, а также требовать, чтобы сертификат содержал электронное письмо в теме, которая соответствует @example.org. Если CA выполняет свою работу должным образом, он подтвердит, что данные, включенные в сертификат, действительно верны как часть подписи.