Используя Apache 2.4.
У нас есть два действительных сертификата CA, отличительные имена которых отличаются только регистром одного символа (скажем, CA1 с dn: cn = MyCA, O = myOrg и CA2 с dn: cn = MyCA, O = MyOrg).
Эти два сертификата находятся в файле, на который ссылается SSLCACertificateFile Директива Apache, поскольку нам необходимо аутентифицировать сертификаты клиентов, подписанные обоими центрами сертификации. Этого не происходит: доступ могут получить только браузеры с клиентскими сертификатами, подписанными CA1 или CA2, в зависимости от порядка сертификатов CA в файле. Итак, если только клиенты из CA1 могут аутентифицироваться, после переключения порядка в SSLCACertificateFile и перезагрузки Apache только клиенты из CA2 смогут аутентифицироваться.
Если мы выполним рукопожатие SSL openssl s_client -connect <server>:<port> -prexit, мы замечаем, что только одно из отличительных имен CA отправляется в списке принятых CA, а отправляемый dn зависит от порядка, в котором сертификаты CA находятся в SSLCACertificateFile. Это имеет смысл, поскольку вычисляемый хеш Openssl для двух выделенных имен одинаков, поскольку выделенные имена не должны быть чувствительны к регистру.
Но похоже, что браузер выполняет сопоставление с учетом регистра, вместо этого, поскольку в журналах Apache сертификат, установленный в браузере, не отправляется, когда «объявленный CA» - это CA1, а сертификат клиента подписан CA2, и наоборот. . Мы пробовали использовать Firefox в Windows и Linux, а также Internet Explorer и Chrome в Windows.
В противном случае браузер командной строки curl не имеет этой проблемы, когда мы вызываем URL-адрес https с сертификатом клиента и ключом в формате PEM.
Я бы сказал, что, не копаясь, вы не можете убедить браузеры выполнять здесь поиск без учета регистра. В случае простой веб-службы вы можете создать еще один VirtualHost, в котором распределены все клиенты (скажем, https://detect-cert.example.com).
Это будет означать, что клиент согласовывает TLS один раз, затем у него есть перенаправление, а затем еще одно согласование TLS.
VirtualHost detect-cert.example.com:
optional_no_ca сертификаты из браузеровSSLCACertificateFileSSL_CLIENT_I_DN или SSL_CLIENT_CERT_CHAIN_<n> переменная окруженияca1clients.example.com или ca2clients.example.comVirtualHost ca1clients.example.com:
require сертификаты из браузеровSSLCACertificateFile CA_lowercase.pemVirtualHost ca2clients.example.com:
requireSSLCACertificateFile CA_uppercase.pemНо ваше веб-приложение должно поддерживать два доменные имена в то же время (например, через X-Forwarded-Host заголовок). Он никогда не должен сообщать браузеру, который вошел через ca2clients.example.com повторно войти через ca1clients.example.com. Еще одна трудность заключается в том, что пользователи обмениваются ссылками между собой (например, отправляют по электронной почте ссылки на некоторый контент).