вадяно FF может сделать исключение безопасности и администратор идет лесом.
т.е. любой может получить сертификат. и иметь подключение.
атака «человек посередине» в данном случае не интересует - затраты и квалификация должны быть слишком большие.
наличие сертификата не даёт никакой защиты, идентификации.
или нужен специфический сертификат?HTTPS обеспечивает шифрацию или/и подписание трафика.
Очень грубо:
Основная шифрация идёт на обычном симметричном алгоритме. Для каждого подключения сервер создаёт временный (эфемерный) сеансовый ключ и, соответственно, возникает задача защищённой передачи ключа клиенту.
Вокруг этого и "наверчен" протокол.
Клиент подключается к серверу и "узнаёт" его возможности и требования. Если сервер не требует аутенификации клиента, то клиент создаёт эфемерную (и "самопальную") пару "открытый-закрытый ключи" с согласованными параметрами. Открытый ключ сервера у него уже есть.
Клиент передаёт серверу свой открытый ключ, сервер шифрует сеансовый ключ своим закрытым ключом на открытом ключе клиента.
Клиент расшифровывает сеансовый ключ своим закрытым ключом на открытом ключе сервера и начинается шифрование данных на сеансовом ключе, который есть у обоих сторон и не передавался по каналу связи в открытом виде.
Теперь о "диверсанте-в-цепочке".
Любой, кто включает в своём антивирусе проверку HTTPS-трафика - использует эту уязвимость. Всё, что требуется - контроль канала между клиентом и сервером.
Простейший способ борьбы - априорное знание сертификатов, используемых тем или иным сервером. Например, "mozilla-based" браузеры "знают", какие сертификаты использует сеть обновления Mozilla Foundation.
При двусторонней аутенификации можно представить ситуацию, когда сервер доверяет "самопальным" сертификатам, но сложно представить ситуацию, когда у него нет связки "клиент-сертификат". Т.е. man-in-middle - идёт лесом.

вадято в браузере нельзя получить двустороннюю аутентификацию ?Если у сервера нет списка клиентских сертфикатов - конечно нельзя.
Чтобы это список появился, а у сервера была возможность с ним работать, простого "clientAuth=true" - недостаточно.вадятаким образом - чтоб произошла верификация клиента необходима "двусторонняя аутентификация", тогда нет необходимости вводить логин и пароль (как в mail.ru), логин и пароль вшиты в сертификат, сертификат генерится для каждого клиента свой?Нет.
Есть P(ublic)K(ey)I(nfrastructure), которая опирается на доверие к корневым центрам сертификации.
У каждого центра есть самоподписанный сертификат, который как-то публикуется и как-то добавляется в хранилище доверенных корневых центров каждого, кто желает работать с сертификатами этого центра. "Как-то" - ключевое и принципиальное свойство
Более-менее публичные корневые центры не работают с конечными клиентами напрямую - они создают сеть промежуточных центров сертификации, которые уже и работают с клиентами. Или напрямую или через свою сеть промежуточных центров сертификации.
Каждый клиент обращается к какому-то "конечному" центру сертификации, предоставляет ему документы, требуемые регламентом этого центра и получает клиентский сертификат. В таком сертификате может быть прописано много чего. Например, ФИО с электронной почтой человека или список доменных имён, используемых веб-сервером.
В "технической части" сертификата есть "цепочка доверия", где указана иерархия сертификатов удостоверяющих центров.
Целостность цепочки может быть проверена вне зависимости от наличия или отсутствия корневого сертификата в том или ином хранилище доверенных корневых сертификатов.
Доверие клиентскому сертификату определяется каждым индивидуально, на основании имеющихся в его распоряжении хранилищ доверенных корневых сертификатов.
Таким образом, чтобы работала клиентская аутенификация требуется, как минимум, чтобы у сервера был надёжный канал получения клиентских сертификатов. Чтобы, грубо говоря, не мог Барак Обама предоставить сертификат Ангелы Меркель. Ну и наоборот

вадяочень краткое описание.
но в инете я не нашел подробного . можешь дать ссылку?Так чтобы одну - нет. Так, чтобы пачку - вряд ли подберу. Тем более, что кое-что читалось в книжках, доках и хелпах
Тем не менее, в статье из вики есть ссылка на SSL где, среди прочего, описан и (анонимный) обмен ключами и протокол рукопожатия.
автори об этом тоже. Importing the Certificate и, заметьте - описывается импорт в конкретное хранилище.
Ну и на этой же страничке - Realms and AAA .

В Крипто Про JCP есть целый каталог с примерами и тестами, один из которых (кроме прочего) поднимает (локальный) https-сервер, к которому обращается клиент.
При знакомстве с Крипто Про JCP надо учитывать следующее:
1. Временная лицензия действует месяц от первой установки;
2. Временная лицензия не годится, если у вашей системы более четырёх ядер;
3. Серверный TLS требует лицензии на серверный JCP, что, мягко говоря, не дёшево, если закончился льготный период или у вашего процессора более четырёх ядер.
По всем этим причинам рекомендую "для посмотреть" Крипто Про JCP использовать (исключительно) пробирку - Virtual Box или то, что вам больше нравится.

Basil A. Sidorov1. Временная лицензия действует месяц от первой установки;Три месяца, но это не принципиально - время летит быстро