Предположительно, под двойной аутентификацией вы подразумеваете, что используете аутентификацию сертификата клиента в дополнение к аутентификации сертификата сервера (что более распространено).
Было бы полезно узнать, какие версии платформ используются с обеих сторон и какие исправления были применены.
Возможно, что часть проблемы связана с исправлением повторного согласования до CVE-2009-3555 (или без исправления).
Проблема заключается в недостатке первоначального проекта повторного согласования в TLS, который использовался для повторного согласования сертификата клиента. Существует два способа получения клиентского сертификата: либо сервер запрашивает его во время первоначального рукопожатия TLS, либо он запрашивает его во время последующего рукопожатия (например, когда он выяснил, на что был направлен запрос и / или при попытке доступа к определенной запретной зоне). Второй метод - это повторные переговоры. К сожалению, в этом отношении был обнаружен недостаток безопасности при разработке протокола TLS, который с тех пор был исправлен благодаря расширению TLS, описанному в RFC 5746 .
Когда недостаток был впервые обнаружен (примерно в ноябре 2009 года), некоторые платформы и библиотеки, такие как Sun Java или OpenSSL, развернули быстрое исправление, которое просто запретило любое повторное согласование (поэтому сработало бы только первоначальное согласование сертификата клиента) , Позже, после написания RFC 5746, эти библиотеки начали внедрять реализации, поддерживающие это расширение.
Насколько я знаю, по умолчанию Microsoft в IIS и ее веб-инфраструктуре использовала повторное согласование, а не первоначальное согласование. Кроме того, не было развернуто первоначальное исправление, чтобы отключить повторное согласование (эффективно сохраняя известную уязвимость). Он только выпустил патч (по-прежнему допускающий старые реализации по умолчанию) совсем недавно: Бюллетень по безопасности Microsoft MS10-049 - критический .
Существует также объяснение проблемы в этом блоге безопасности Microsoft:
http://blogs.technet.com/b/srd/archive/2010/08/10/ms10-049-an-inside-look-at-cve-2009-3555-the-tls-renegotiation-vulnerability.aspx
По сути, если вы пытаетесь установить связь с сервером, который поддерживает только старый стиль согласования из стека, который имеет только новый стиль повторного согласования или вообще не повторяет согласование, это не сработает.
Если ваш сервер работает с использованием IIS или аналогичной среды, возможно, вы сможете включить начальное согласование сертификата клиента с помощью netsh и его опции clientcertnegotiation=enable.