Регистрация...

Eserv Forum / E3 / Eserv 3 Mail Server Support / Проверка сертификата

wikipost // (v1)
Продукты и услуги Скачать Документация Купить Поддержка Форумы Партнёрам Статьи О компании
Новости
12.10.2009
Переезд завершен
Доброго времени суток
Возникла у меня мысль соорудить pops, smtps, https с более серьезными правилами нежели по умолчанию.
Почитал на эту тему. Кое-что соорудил.
Создал Сертификат CA, новый сертификат сервера, и соответственно подписал с помощью CA.
Впихнул в клиента сертификат CA. Все вроде нормально. Yb Thunderbird ни Firefox более не жалуются на несоответствие сертификату. НО. Мне этого мало. Хочется вот чего:
  1. Что-бы сервер не принимал соединение, если клиент не предоставит еще и сертификат Клиента. Соответственно тоже подписанный моим CA.
  2. А в идеале было-бы весьма полезно, если-бы и аутентификация клиента производилась по Клиентскому сертификату.
  3. Я так понимаю,что п.1 — это даже не к ЕСерву вопрос, а к SSL. А именно к серверному сертификату. Это так или Есерв тут тоже задействуется? По п.2, как я понял, несколько сложнее т.к. в EServ не может использовать сертификат x509 как Источник аутентификации/авторизации. Я прав? Или все-же есть пути?
 
Комментарии к этой версии (11.11.2010 09:35) [~psSnowman] 2210e35e
АвторДатаТекстtags
psSnowman11.11.2010 10:02
Нашел в EServ.orig.ini параметр SslVerifyClient Это какраз по пункту 1?
wikipost
pig11.11.2010 10:52
Это да. А по пункту 2 — по-моему, вообще никак. В POP и SMTP такие способы авторизации не предусмотрены.
wikipost
ac11.11.2010 12:00
Это работает еще со времен Eserv/3:

  1. Управляется опцией SslVerifyClient соответствующего сервера. 0= не проверять клиента, 1 = проверять, 2 = отказываться соединяться, если нет клиентского сертификата или издатель сертификата клиента неизвестен.
  2. Тут придётся добавить одну строчку в конфиг...
Список сертификатов CA, сертификаты изданные которыми сервер должен принимать в п.1, добавляются в server.pem (кроме своих CA-сертификатов я в тестах добавлял Verisign (они выдают бесплатные сертификаты для почты — "Class1 digital ID") и WebMoney (тогда он принимает те же сертификаты, которые используются для light.webmoney.ru)).
wikipost
ac11.11.2010 12:04
Строчка для конфига:
SSL_CLIENT GetCertEmail SetLoggedUser

Добавить её после строки "SSL_CLIENT 250 LOG" в OnStartup.rules.txt.
wikipost
ac11.11.2010 12:06
Не обратил внимания, что вопрос про E3, ответил в контексте E4 Но вообще тут одинаково, только файл правил другой — в E3 это OnThreadConnect.rules.txt.
wikipost
psSnowman11.11.2010 12:11
ac пишет: Не обратил внимания, что вопрос про E3, ответил в контексте E4 Но вообще тут одинаково, только файл правил другой — в E3 это OnThreadConnect.rules.txt.

Понял. Мне, собственно, сейчас для E3 нужно. Ибо горит. А в дальнейшем для E4. т.к. он у нас также имеется. Но еще не введен в эксплуатацию. Кучу всякого надо из 3 в 4 переносить.
wikipost
psSnowman11.11.2010 17:14
Штука c SslVerifyClient=2 не прошла. Все равно пускает. Что acSMTP что acWeb.
Потер из Firefox и Thunderbird все свои сертификаты. И клиентские и CA.
Зашел Firefox'ом на сайт. Ругнулся лис, что сертификат не доверенный. Я нажал Принять сертификат и вошел на сайт.
Аналогичная ситуация с acSMTP. Отправляешь письмо, Thunderbird просит принять сертификат и отправляет письмо.
wikipost
pig11.11.2010 17:22
ред: 11.11.2010 17:32
DATA\log\stat\201011auth.txt надо смотреть.

В порядке бреда — а если код 3 попробовать?
wikipost
ac11.11.2010 17:56
pig пишет: DATA\log\stat\201011auth.txt надо смотреть.

Верно, там в последнем поле будет информация из клиентского сертификата (если он был).

pig пишет: В порядке бреда — а если код 3 попробовать?

Да, надо попробовать. Там "1" = SSL_VERIFY_PEER, а "2" = "SSL_VERIFY_FAIL_IF_NO_PEER_CERT", их можно по OR объединять.

Для чистоты эксперимента начните вообще с "1". При подключении браузером должно выскочить окошко с запросом клиентского сертификата, а не с предложением принять серверный (если вы его уже принимали, или если устанавливали свой CA в доверенные, то браузер сам примет серверный сертификат без лишних запросов).
wikipost
ac11.11.2010 18:08
pig пишет: В порядке бреда

Не бред, а требование документации — "This flag must be used together with SSL_VERIFY_PEER".
wikipost
psSnowman11.11.2010 18:20
Уже что-то подобное делал. Просто решил попробовать вообще без своих сертификатов на клиенте. И смутило, что пустил.
Сейчас попробую 3.
wikipost
pig11.11.2010 18:28
ред: 11.11.2010 18:29
ac пишет: Не бред, а требование документации

Значит, я правильную книжку читал
Только не помню, где. Наверное, на самом openssl.org.
wikipost
psSnowman11.11.2010 19:02
ред: 11.11.2010 19:11
О! Поставил 3. В клиенте сертификатов не устанавливал. Не пускал acWeb. Firefox пишет "Соединение сброшено" и в DATA\log\stat\201011auth.txt SSL Failed:1
Кстати, а где можно глянуть описание кодов ошибок? На openSSL.org вроде не видно. С документацией там вообще что-то туго.
Добавил в FF CA и клиентский сертификаты. Пустил!
Потом удалил сертификат CA из Firefox. Снова свободно зашел на сервер. FireFox и слова не сказал. Только клиентский сертификат выбрать предложил. Это как-то настораживает. Как тогда FireFox проверяет сертификат сервера? Неужели открытый ключ CA и в клиентском сертификате есть?
wikipost
ac11.11.2010 19:12
В клиентском сертификате подпись CA и хэш открытого ключа CA. По этим параметрам сервер может найти у себя (в server.pem в нашем случае) подходящий CA-сертификат (открытый ключ) и проверить подпись. В принципе клиент мог бы и CA-сертификат предоставлять, но сервер не обязан ему доверять, точнее обязан не доверять , поэтому список доверенных CA он хранит на сервере.

psSnowman пишет: Снова свободно зашел на сервер.

Свободно он зашел или нет — надо смотреть по упомянутому логу auth.txt. В принципе он мог использовать уже установленное ранее SSL-соединение, даже если сам сертификат уже удален (все ключи есть в контексте соединения — служебной структуре браузера, заполняемой во время подключения).
wikipost
ac11.11.2010 19:17
И еще, если "настороженность" сохраняется из-за слишком прозрачного входа, можно ведь добавить дополнительный контроль к той строчке в конфиге — просто проверять там, а был ли [валидный] клиентский сертификат вообще, и самостоятельно закрывать соединение, если не было (т.е. без помощи флага SSL_VERIFY_FAIL_IF_NO_PEER_CERT обойтийсь вообще).
wikipost
ac11.11.2010 19:24
psSnowman пишет: SSL Failed:1
Кстати, а где можно глянуть описание кодов ошибок? На openSSL.org вроде не видно. С документацией там вообще что-то туго.

Да, диагностика там намного менее подробна, чем в WinSock. Коды ошибок Eserv получает по SSL_get_error, и все варианты перечислены здесь: http://www.openssl.org/docs/ssl/SSL_get_error.html
wikipost
psSnowman11.11.2010 19:42
ac пишет: В клиентском сертификате подпись CA и хэш открытого ключа CA. По этим параметрам сервер может найти у себя (в server.pem в нашем случае) подходящий CA-сертификат (открытый ключ) и проверить подпись. В принципе клиент мог бы и CA-сертификат предоставлять, но сервер не обязан ему доверять, точнее обязан не доверять , поэтому список доверенных CA он хранит на сервере.

Это верно. И в принципе понятно. Сервер вроде-как отрабатывает нормально. А вызывает подозрение именно клиент. Складывается впечатление, что FF не проверяет сертификат сервера.

ac пишет: Свободно он зашел или нет — надо смотреть по упомянутому логу auth.txt. В принципе он мог использовать уже установленное ранее SSL-соединение, даже если сам сертификат уже удален (все ключи есть в контексте соединения — служебной структуре браузера, заполняемой во время подключения).

FF перезапускал. И в auth.txt имеется запись что соединение свежее.

Кстати. Интересный момент. IE не может зайти даже с установленными сертификатами. EServ выдает ошибку 5 в auth.txt
wikipost
ac11.11.2010 23:56
psSnowman пишет: Складывается впечатление, что FF не проверяет сертификат сервера.

В FF и других браузерах при работе по httpS результат проверки всегда хорошо виден — по иконке "замОк", цвету адресной строки и т.п. Там можно щелкнуть мышкой и посмотреть всю информацию о сертификате сервера.

psSnowman пишет: IE не может зайти даже с установленными сертификатами.

Клиентскими? Или CA?
wikipost
ac11.11.2010 23:57
Вот сайт на Eserv'е с SSL — https://secure.snop.ru/ — нормально у вас открывается?
wikipost
psSnowman12.11.2010 09:38
ac пишет: Вот сайт на Eserv'е с SSL — https://secure.snop.ru/ — нормально у вас открывается?

FF, Opera, IE открывают без каких-либо вопросов.

ac пишет: В FF и других браузерах при работе по httpS результат проверки всегда хорошо виден — по иконке "замОк", цвету адресной строки и т.п. Там можно щелкнуть мышкой и посмотреть всю информацию о сертификате сервера.

Ну да. подозрения подтвердились, когда щелкнул на замочек. "Информация о владельце этого веб-сайта отсутствует". А ведь в FF установлены и клиентский и CA. FF проигнорировал проблемы с CA. Явно я что-то накосячил с генерацией сертификатов. Но FF этот факт игнорирует. IE ни с клиентским, ни с CA, ни с обоими одновременно не работает. Опера, клиентский сертификат вообще не принимает.
Честно говоря, возникают сомнения, проверяет-ли EServ подленность клиентского сертификата (т.е. подпись CA на клиентском Серт-те)
wikipost
ac12.11.2010 13:51
psSnowman пишет: Ну да. подозрения подтвердились, когда щелкнул на замочек. "Информация о владельце этого веб-сайта отсутствует". А ведь в FF установлены и клиентский и CA.

А ведь ни тот и ни другой не имеют отношения к владельцу сайта

"Информация о владельце этого веб-сайта отсутствует" пишется о сертификатах большинства сайтов, в т.ч. известных (см. например https://bugzilla.mozilla.org/ , https://light.webmoney.ru/). Потому что на большинстве сайтов используются дешевые сертификаты, в которых CA удостоверяет только контроль владельца сайта (указанного в сертификате email'а) над сайтом, и более ничего. Они не проводят личных встреч для проверки документов личности, учредительных документов предприятия и т.п. (такие сертификаты стоят на порядки дороже).

Т.е. такая надпись не говорит о том, что браузер не принял сертификат. Если браузер не хочет принимать сертификат, то он пишет что-нибудь паническое, и соединение не устанавливает. Вот например, https://forum.eserv.ru — там сертификат, который не соответствует доменному имени, браузер должен об этом предупредить.

psSnowman пишет: Опера, клиентский сертификат вообще не принимает.

Браузер и не должен "принимать" клиентский сертификат. Браузер проверяет серверный сертификат. Потом, если сервер требует идентификацию клиента (если есть флажок "1" в нашем случае), он запрашивает у клиента клиентский сертификат. При этом он выдает клиенту список CA, чью подпись на сертификате он согласен принять (этот список он берет в нашем случае из server.pem). Если в браузере есть клиентский сертификат (и соответствующий закрытый ключ, т.е. "персональный сертификат" или "личный сертификат"), подписанный CA из списка, то браузер выводит пользователю окошко со списком клиентских сертификатов и предложнием представиться этим сертификатом. Либо автоматически передает подходящий сертификат, если ранее в этой сессии он уже выбирался. (т.е. это работает как с http-паролями) Если в списке сертификатов браузера подходящего персонального сертификата не установлено (у FF и IE списки разные, т.е. нужно устанавливать в каждый из браузеров), то он представиться не может. Дальнейшее поведение сервера зависит от второго флага (SSL_VERIFY_FAIL_IF_NO_PEER_CERT=2) — он либо согласится работать с неизвестным клиентом, либо не согласится (как было на деле, был ли клиентский сертификат — вы видите в логе auth.txt).
wikipost
ac12.11.2010 13:53
psSnowman пишет: Честно говоря, возникают сомнения, проверяет-ли EServ подленность клиентского сертификата (т.е. подпись CA на клиентском Серт-те)

Если в auth.txt есть информация из клиентского сертификата, значит всё проверено. Если клиентский сертификат был, но подпись на нем не соответствует доверенным CA, то Eserv даже не узнает (от openssl), что этот сертификат был, соответственно и в логе это поле будет пусто.
wikipost
psSnowman12.11.2010 15:57
ac пишет: Т.е. такая надпись не говорит о том, что браузер не принял сертификат. Если браузер не хочет принимать сертификат, то он пишет что-нибудь паническое, и соединение не устанавливает. Вот например, https://forum.eserv.ru — там сертификат, который не соответствует доменному имени, браузер должен об этом предупредить.

По моему мы немного друг-друга не поняли. Я имел ввиду вот что:
Как я понимаю, SSL сессию с флагом Verify=3:
  1. Клиент коннектится к серверу
  2. Клиент отправляет серверу свой Личный сертификат (назовем его client.pem), в котором содержится открытый ключ клиента (назовем его client.key). Соответственно этот Личный сертификат подписан с помощью закрытого ключа CA (CApriv.key) и сертификата CA (CA.pem). В моем случае это CA собственного изготовления.
  3. Сервер проверяет сертификат Client.pem с помощью CA.pem. Если подпись CA на client.key верна, сервер считает, что клиент прошел проверку.
  4. Сервер отсылает свой, серверный сертификат (server.pem) также подписанный с помощью того-же CA.
  5. Клиент, с помощью CA.pem проверяет подпись в Server.pem. Если она верна, клиент считает, что соединился именно с тем сервером, с которым хотел. И это не "человек в середине".
  6. Другие проверки, типа соответствие URL адреса и др. реквизитов сертификата я не упомянул т.к. они не столь актуальны сейчас.
Исходя из этого алгоритма. У сервера и у клиента, помимо собственных сертификатов, должен быть установлен сертификат CA (CA.pem)
Так вот, смущало меня то, что FF и без CA.pem совершенно спокойно заходил на сайт. Без всяких нервных сообщений. Но причину отсутствия ругани я нашел. FF без CA.pem ругаться стал. Но если принять исключение, все равно пускает. Но это вопрос уже не к Вам. Но если Вы что-то знаете на этоу тему...
Когда я говорил про то, что Опера не принимает клиентский сертификат, я имел ввиду, что он не устанавливается в Оперу.
Кстати. Попробовал заменить EServ stunnel'ом. Собственно, эффект тот-же. FF работает нормально, IE 8 отказывается работать. Ну с Оперой понятно. Даже сертификат установить не дает.
Тут, в общем-то вопросы не к Вам т.к. проблема явно не в EServ'е. Но если есть какие-нибудь зацепки, то буду рад информации, ссылочкам на тему и т.п.
wikipost
ac12.11.2010 17:08
Пункты 2-3 и 4-5 надо поменять местами, т.к. сначала всегда идентификация сервера.

psSnowman пишет: FF без CA.pem ругаться стал. Но если принять исключение, все равно пускает.

Да, так и должно быть. Точнее, быть может как угодно, как решат разработчики клиентского софта, но для удобства они обычно решают действовать именно так — предупредить клиента о том, что "что-то здесь не так" (сертификат истёк, домен не тот, издатель неизвестен, флаги использования не те, и т.д.), но предоставить ему возможность проигнорировать все предупреждения и работать-таки с этим сервером (т.к. техническая-то возможность работать с таким сервером есть, даже если все политики нарушены).
wikipost
ac12.11.2010 17:15
psSnowman пишет: Когда я говорил про то, что Опера не принимает клиентский сертификат, я имел ввиду, что он не устанавливается в Оперу.

Если сертификат создавался не в Опере, то его надо туда импортировать через "Безопасность/Управление сертификатами/Импорт", экспортировав предварительно оттуда, где он у вас есть (из FF, например). Общепринятый формат для переноса персональных сертификатов (с закрытым ключем) — PKCS#12 (*.pfx или, что то же самое, *.p12).

psSnowman пишет: FF работает нормально, IE 8 отказывается работать.

IE8 отказывается как именно? Что пишет на странице отказа, и что предлагает делать?
wikipost
psSnowman12.11.2010 19:53
ac пишет: Да, так и должно быть. Точнее, быть может как угодно, как решат разработчики клиентского софта, но для удобства они обычно решают действовать именно так — предупредить клиента о том, что "что-то здесь не так" (сертификат истёк, домен не тот, издатель неизвестен, флаги использования не те, и т.д.), но предоставить ему возможность проигнорировать все предупреждения и работать-таки с этим сервером (т.к. техническая-то возможность работать с таким сервером есть, даже если все политики нарушены).

Да. Собственно оно и понятно. Меня изначально настораживало отсутствие ругани FF. Я и добивался, чтобы он ругался, если чего-то не хватает. Но вот то, что он дает потом зайти — это не радует.
IE я победил. Вот его поведение мне понравилось. Он пускает только если импортируешь и клиентский и CA. А FF пускает без CA т.е. даже без возможности проверить сертификат. Хоть и ругается.
wikipost
psSnowman12.11.2010 20:01
ac пишет: Если сертификат создавался не в Опере, то его надо туда импортировать через "Безопасность/Управление сертификатами/Импорт", экспортировав предварительно оттуда, где он у вас есть (из FF, например). Общепринятый формат для переноса персональных сертификатов (с закрытым ключем) — PKCS#12 (*.pfx или, что то же самое, *.p12).

Сам собой. Сначала сгенерировал его с помощью OpenSSL, подписал с помощью CA, конвертнул в PKCS#12. FF принимает, IE тоже. А Opera почему-то нет. Беде дальше экспериментировать.
wikipost
pig12.11.2010 22:14
psSnowman пишет: Opera почему-то нет

Молча или таки ругается на что-то?
wikipost
psSnowman12.11.2010 22:29
pig пишет: Молча или таки ругается на что-то?

Говорит что-то типа "Не удалось импортировать сертификат"
wikipost
pig12.11.2010 23:59
А если в консоли ошибок посмотреть?
wikipost
ac13.11.2010 01:18
psSnowman пишет: А Opera почему-то нет.

Сейчас потестировал — у меня Opera 10.63 нормально импортировала мои pfx'ы, включая экспортированный из FF webmoney'вый сертификат для авторизации на light.webmoney.ru. Да и раньше проблем с сертификатами в Опере не замечал, если не считать несовместимой с IE кодировки кириллицы.

Новые клиентские сертификаты можно и прямо в Опере создавать. Специально восстановил сейчас старый триальный кейген для Eservhttps://secure.snop.ru/e4a/x509.html — попробуйте. Он кроме триального сертификата (высылаемого на Email) создает и персональный сертификат, устанавливаемый в браузер — и его тоже можно будет использовать для SSL-авторизации клиента, если в server.pem добавите наш "Eserv users CA".

FF не ругается на ваш самодельный сертификат при отсутствии CA в списке доверенных, т.к. возможно вы уже однажды добавили его в исключения безопасности. Попробуйте заменить основной сертификат (с ключем) в server.pem.
wikipost
psSnowman13.11.2010 07:45
ac пишет: FF не ругается на ваш самодельный сертификат при отсутствии CA в списке доверенных, т.к. возможно вы уже однажды добавили его в исключения безопасности. Попробуйте заменить основной сертификат (с ключем) в server.pem.

Да.Это я уже решил. Удалил исключение из FF.
wikipost
psSnowman30.03.2011 10:25
ред: 30.03.2011 10:29
ac пишет: SSL_CLIENT GetCertEmail SetLoggedUser

Вписал в OnThreadConnect.rules.txt строку SSL_CLIENT GetCertEmail SetLoggedUser

Port= {POP[SslPort]} [IF] POP[Certificate] DUP 0= | 2DROP Server[Certificate] POP[SslVerifyClient] >NUM vClientSocket SslServerSocket SetPeerCert SetSslClient SSL_CLIENT 250 LOG SSL_CLIENT GetCertEmail SetLoggedUser \ Аутентификация по сертификату uSSL_SOCKET @ 0= | \EOF [THEN]


Собственно, thunderbird все равно ругается, что серверу пароль не понравился. А пароль я в TB и не пытался вписывать
wikipost
pig30.03.2011 10:56
По уму эту строчку надо ниже передвинуть — доставать что-либо из параметров клиента можно только после успешного установления соединения.

А ругань будет, конечно — протокол POP3 в принципе предусматривает авторизацию, поэтому логин и пароль передаются TB независимо от ваших правок в конфиге сервера. Даже если это получится обойти на стороне клиента, нужны дополнительные правки в конфиге, потому что почтовый ящик сейчас устанавливается только при выполнении явной протокольной авторизации.

Авторизация по сертификату возможна там, где она не обязательна по устройству протокола — в SMTP, HTTP, Socks.
wikipost
psSnowman30.03.2011 13:40
pig пишет: По уму эту строчку надо ниже передвинуть — доставать что-либо из параметров клиента можно только после успешного установления соединения.

Насчет SMTP еще не могу точно сказать, получилось или нет. Надо потестить. А вот pop3 говорит invalid user:Pass, что свидетельствует о ругани сервера.
wikipost
psSnowman30.03.2011 14:10
Решил проверить, что там да как. Написал так:
Port= {POP[SslPort]} [IF] POP[Certificate] DUP 0= | 2DROP Server[Certificate] POP[SslVerifyClient] >NUM vClientSocket SslServerSocket SetPeerCert SetSslClient SSL_CLIENT 250 LOG SSL_CLIENT GetCertEmail SetLoggedUser \ Аутентификация по сертификату SSL_CLIENT GetCertEmail TYPE CR User TYPE CR uSSL_SOCKET @ 0= | \EOF [THEN]

Переменная User принимает нужное значение, но это не спасает "Отца русской демократии"

SMTP тоже не работает. Даже GetCertEmail пустую строку выдает. Ну и соответственно User остается пустым.
wikipost
pig30.03.2011 14:36
Ещё раз: протоколы POP и IMAP предусматривают явную протокольную авторизацию. В настройках TB нет метода авторизации "по сертификату" — поэтому он тупо передаёт логин и пароль, которые вы не настроили, и, естественно, получает отбой.

А в SMTP, похоже, не связалось что-то.
wikipost
psSnowman30.03.2011 18:15
ред: 30.03.2011 18:17
pig пишет: Ещё раз: протоколы POP и IMAP предусматривают явную протокольную авторизацию. В настройках TB нет метода авторизации "по сертификату" — поэтому он тупо передаёт логин и пароль, которые вы не настроили, и, естественно, получает отбой.

Спасибо. Работу протоколов я представляю. И понимаю почему TB меня пароль просит ввести. Но мне не понятно, вот чего. Если в данной сессии аутентификация уже выполнена по сертификату (или по IP, MAC), то почему-бы не выдавать OK на любой пароль от клиента? Ведь по сути пароль уже не нужен. Пользователь определен по сертификату (IP, MAC и т.п.) А сервер выдает invalid:Pass... Не логично... И соответственно вся эта аутентификация по сертификатам (также как по IP и MAC) становится не актуальной. Все равно нужен пароль...
pig пишет:
А в SMTP, похоже, не связалось что-то.

А что? И где?
wikipost
ac30.03.2011 18:39
Раз вы все равно уже начали править конфиги, то можете подкрутить еще один, чтобы реализовать
psSnowman пишет: почему-бы не выдавать OK на любой пароль


Для этого в файле acIMAP\conf\pop\OnLogin.rules.txt замените строку "LOGIN" на
UID @ 0= | LOGIN
wikipost
ac30.03.2011 18:41
psSnowman пишет: pig пишет: А в SMTP, похоже, не связалось что-то.
А что? И где?

Если SSL_CLIENT пуст, значит клиент не предъявил сертификат или предъявил негодный (при данных опциях).
wikipost
pig30.03.2011 18:51
psSnowman пишет: Если в данной сессии аутентификация уже выполнена по сертификату (или по IP, MAC), то почему-бы не выдавать OK на любой пароль от клиента?

И на любой логин?
Я не знаю, реализовано ли это где-нибудь. Теоретически возможно, конечно — но тогда вам нужна очень строгая проверка клиентских сертификатов. Я ведь могу сгенерировать сертификат с вашим адресом, подписать его имеющимся EservRootCA и таким образом получить доступ к вашей почте.

А что до SMTP — давайте смотреть в DATA\log\stat\201103auth.txt за соответствующий момент времени. По идее — раз для POP SSL включается, то и для SMTP должен, разницы быть не должно при одинаковых настройках.
wikipost
ac30.03.2011 18:59
pig пишет: тогда вам нужна очень строгая проверка клиентских сертификатов

Она проводится, если включена опция SslVerifyClient=2 (клиентский сертификат проверяется на предмет подписанности той цепочкой сертификатов, которые положены в server.pem вместе с сертификатом и ключем сервера).

pig пишет: Я ведь могу сгенерировать сертификат с вашим адресом, подписать его имеющимся EservRootCA и таким образом получить доступ к вашей почте.

Закрытого ключа от EservRootCA у вас наверное нет ( ? ). Кроме того владелец сервера, работающего на Eserv, не обязан доверять EservRootCA. И я думаю, что по умолчанию и не доверяет (не кладёт этот сертификат в server.pem).
wikipost
psSnowman05.04.2011 15:24
ред: 05.04.2011 15:27
Собственно, описываю, что я соорудил и какие возникли проблемы. server.pem у меня свой. Так, что никто кроме выданных мною сертификатов не прокатят
Вписал в OnThreadConnect.rules строчку
EvalRules: customrules\SSL_ThreadConnect

А в OnLogin.rules вписал
EvalRules: customrules\SSL_LOGIN 0= | LOGIN

Собственно файлики прилагаю.

Файл: описание файла 2 [291 bytes]
Файл: описание файла 1 [353 bytes]
wikipost
ac05.04.2011 15:47
Не видно описания "какие возникли проблемы".

Из второго файла:
LoggedAs: "{SSL_CLIENT GetCertEmail GetUserFromEmail}" 0= | TRUE \EOF

Нужен ли там "0="? Ведь тогда при совпадении логина получим FALSE...
wikipost
psSnowman05.04.2011 16:41
Т.к. в моей системе есть ошибки, вернул все к самому простому варианту. Так сказать, для чистоты эксперимента.
В конец OnThreadConnect.rules добавил SSL_CLIENT GetCertEmail SetLoggedUser
В OnLogin добавил UID @ 0= | LOGIN
Далее эксперимент с TB.
Отсылаю себе письмо и пытаюсь принять. Если в поле "Имя пользователя" стоит логин и домен (например Ivanov@domain.ru), то все работает как надо. А вот если без домена (просто Ivanov), TB не ругается, но и ничего не принимает. При обычной авторизации такой проблемы не возникает.
Собственно, я нашел решение. Но оно годится только для одного домена. А у меня в будущем их будет больше одного.
wikipost
psSnowman05.04.2011 16:43
p.s. подобная проблема возникает только при аутентификации с сертификатом. Просто по логину и паролю все проходит нормально.
wikipost
psSnowman05.04.2011 17:04
ред: 05.04.2011 17:05
Тем не менее не понял, почему SetLoggedUser, будучи запущенной в OnThreadConnect, игнорирует имя домена
wikipost
ac05.04.2011 17:31
Потому что вы там (в удаленном фрагменте кода) сравниваете с "User", а надо с "UserEmail" (раз вам надо с доменом). SetLoggedUser не игнорирует домен, а сохраняет его в Domain. Как и SetUser (см. http://acweb.cvs.sourceforge.net/viewvc/acweb/src/auth.f?revision=1.16&view=markup )
wikipost
Работает на Eserv/5.05555 (05.06.2016)