Fetchmail не может сделать TLS на одном компьютере, на другом - работает
Долгое время на одном компьютере с debian 10 программа fetchmail выполняла загрузку почты с внешнего сервера. Сейчас перестала
Попробовал установить и настроить fetchmail на другом компьютере - с Альт 9. При том же конфиге почему-то работает. Код:
### Файл ~/.fetchmailrc Цитата:
Цитата:
Получается, что на первом компьютере программа по какой-то причине не может начать сеанс TLS с сервером Конфиги программы ~/.fetchmailrc совпадают При этом на первом компьютере с сервера яндекс.почты fetchmail загружает письма без проблем. То есть проблема возникает только с одним сервером. |
Смотрите версии openssl и их поддерживаемые protocols and ciphers.
openssl version openssl ciphers -v openssl ciphers -v | grep ECDHE-RSA-AES256-SHA384 для проверки поддержки конкретного сайфера, который использует второй компьютер. Также можно просканировать сервер на тему поддерживаемых протоколов и сайферов при помощи sslscan или аналогов. Скорее всего вам просто нужно обновить версию openssl/libssl на первом компьютере. Или разрешить не сервере, если он под вашим управлением, доступные первому пк протоколы и сайферы. В общем, согласовать версии. |
Завтра напишу версию и параметры первого компьютера.
А пока вопрос - как добавить указанный cipher клиенту? |
Цитата:
Кстати вот команда в помощь для теста совместимости openssl s_client -starttls imap -connect server.ru:143 |
Нужный сайфер оказался в списке доступных. Для его использования достаточно было закомментировать в конфиге /etc/ssl/openssl.cnf одну строку
Код:
[system_default_sect] Теперь возникла вторая проблема Цитата:
Увы, в самом сертификате ссылка на родительский центр выдачи сертификатов выглядит так Цитата:
Или можно в настройках SSL отключить проверку цепочки? |
Цитата:
Что даёт openssl s_client -showcerts -starttls imap -connect server.ru:143 ? Если у последнего в цепочке subject и issuer совпадают, то достаточно просто проинсталить этот сертификат на клиенте. Админу того сервера пора пинка дать, серты стоят гроши или вообще ничего в случае летсенкрипт, за колхозинг с самоподписными сертами, которые не проинсталены сразу у клиентов нужно переводить в мойщики унитазов гг. Цитата:
Цитата:
man fetchmail
--sslcertck (Keyword: sslcertck, default enabled since v6.4.0) --sslcertck causes fetchmail to require that SSL/TLS be used and disconnect if it can not successfully negotiate SSL or TLS, or if it cannot successfully verify and validate the certificate and follow it to a trust anchor (or trusted root certificate). The trust anchors are given as a set of local trusted certificates (see the sslcertfile and sslcertpath options). If the server certificate cannot be obtained or is not signed by one of the trusted ones (directly or indirectly), fetchmail will disconnect, regardless of the sslfingerprint option. Note that CRL (certificate revocation lists) are only supported in OpenSSL 0.9.7 and newer! Your system clock should also be reasonably accurate when using this option. --nosslcertck (Keyword: no sslcertck, only in v6.4.X) The opposite of --sslcertck, this is a discouraged option. It permits fetchmail to continue connecting even if the server certificate failed the verification checks. Should only be used together with --sslfingerprint. |
Цитата:
Получается, что здесь достаточно проверки отпечатка (fingerprint) А debian - уже версию 6.4.0.beta4. Поэтому при одинаковых конфигах возникает ошибка проверки цепочки. Завтра добавлю в конфиг параметр nosslcertck и посмотрю, что получится. |
Цитата:
|
Спасибо. Всё заработало!
|
Время: 11:09. |
Время: 11:09.
© OSzone.net 2001-