[решено] Fetchmail не может сделать TLS на одном компьютере, на другом - работает

[El Scorpio]

Долгое время на одном компьютере с debian 10 программа fetchmail выполняла загрузку почты с внешнего сервера. Сейчас перестала

Попробовал установить и настроить fetchmail на другом компьютере - с Альт 9. При том же конфиге почему-то работает.


### Файл ~/.fetchmailrc
poll poll2
proto imap
via сервер.ru
port 143
user "логин"
pass "пароль"
keep
no fetchall
no ssl
sslcertpath /etc/ssl/certs
sslfingerprint "BF:F0:D0:57:E2:31:B7:EB:B6:BB:24:9C:B7:9E:45:F7"


Первый компьютер
fetchmail -c -v pool2
fetchmail: влючен режим --check, выборка почты не выполняется
fetchmail: 6.4.0.beta4 запрашивает poll2 (протокол IMAP) на Вт 27 июл 2021 14:16:30: опрос начат
Попытка подключения к IP/143...соединение установлено.
fetchmail: IMAP< * OK The Microsoft Exchange IMAP4 service is ready.
fetchmail: IMAP> A0001 CAPABILITY
fetchmail: IMAP< * CAPABILITY IMAP4 IMAP4rev1 LOGINDISABLED STARTTLS UIDPLUS MOVE ID CHILDREN IDLE NAMESPACE LITERAL+
fetchmail: IMAP< A0001 OK CAPABILITY completed.
fetchmail: IMAP> A0002 STARTTLS
fetchmail: IMAP< A0002 OK Begin TLS negotiation now.
fetchmail: сервер.ru: fetchmail: System error during SSL_connect(): handshake failed at protocol or connection level.
fetchmail: сервер.ru: сбой обновления до TLS.
fetchmail: Неизвестный логин или ошибка аутентификации для логин@сервер.ru
fetchmail: Ошибка сокет при выборке из логин@poll2
fetchmail: 6.4.0.beta4 запрашивает poll2 (протокол IMAP) на Вт 27 июл 2021 14:16:30: опрос завершен
fetchmail: нормальное завершение, статус 2


Второй компьютер
fetchmail -c -v poll2
fetchmail: --check mode enabled, not fetching mail
fetchmail: 6.3.26 querying poll2 (protocol IMAP) at Вт 27 июл 2021 14:22:14: poll started
Trying to connect to IP/143...connected.
fetchmail: IMAP< * OK The Microsoft Exchange IMAP4 service is ready.
fetchmail: IMAP> A0001 CAPABILITY
fetchmail: IMAP< * CAPABILITY IMAP4 IMAP4rev1 LOGINDISABLED STARTTLS UIDPLUS MOVE ID CHILDREN IDLE NAMESPACE LITERAL+
fetchmail: IMAP< A0001 OK CAPABILITY completed.
fetchmail: IMAP> A0002 STARTTLS
fetchmail: IMAP< A0002 OK Begin TLS negotiation now.
fetchmail: Server certificate:
fetchmail: Unknown Organization
fetchmail: Issuer CommonName: XXXXX
fetchmail: Subject CommonName: XXXXXXXXXX
fetchmail: Subject Alternative Name: mail.XXXXXXX.ru
fetchmail: poll2 key fingerprint: BF:F0:D0:57:E2:31:B7:EB:B6:BB:24:9C:B7:9E:45:F7
fetchmail: poll2 fingerprints match.
fetchmail: SSL/TLS: using protocol TLSv1.2, cipher ECDHE-RSA-AES256-SHA384, 256/256 secret/processed bits
fetchmail: IMAP> A0003 CAPABILITY
fetchmail: IMAP< * CAPABILITY IMAP4 IMAP4rev1 AUTH=PLAIN AUTH=NTLM AUTH=GSSAPI UIDPLUS MOVE ID CHILDREN IDLE NAMESPACE LITERAL+
fetchmail: IMAP< A0003 OK CAPABILITY completed.
fetchmail: сервер.ru: upgrade to TLS succeeded.
fetchmail: IMAP> A0004 AUTHENTICATE NTLM
fetchmail: IMAP< +
fetchmail: IMAP> TlRMTVNTUAABAAAAB7IAAAcABwAgAAAAAAAAAAcAAABhcmt0aWth
fetchmail: IMAP< + TlRMTVNTUAACAAAABgAGADgAAAAFgoECNeBWhaeRm1YAAAAAAAAAAHgAeAA+AAAABgLwIwAAAA9JAFIAUgACAAYASQBSAFIAAQAU AFYAUwAtAEkALQBNAEIAWAAwADEABAAMAEkAUgBSAC4AUgBVAAMAIgBWAFMALQBJAC0ATQBCAFgAMAAxAC4ASQBSAFIALgBSAFUA BQAMAEkAUgBSAC4AUgBVAAcACADX+uT6noLXAQAAAAA=
fetchmail: IMAP> TlRMTVNTUAADAAAAGAAYAEAAAAAYABgAWAAAAAYABgBwAAAADgAOAHYAAAAOAA4AhAAAAAAAAABSAAAABYKBAvLDPYf02mf7ws0U O2eJmuXkZnunh68iTfFH9c7sqNxwaM9DT13FHYaisdG/j0Yr4EkAUgBSAGEAcgBrAHQAaQBrAGEAYQByAGsAdABpAGsAYQA=
fetchmail: IMAP< A0004 OK AUTHENTICATE completed.
fetchmail: IMAP> A0005 EXAMINE "INBOX"
fetchmail: IMAP< * 793 EXISTS
fetchmail: IMAP< * 0 RECENT
fetchmail: IMAP< * FLAGS (\Seen \Answered \Flagged \Deleted \Draft $MDNSent)
fetchmail: IMAP< * OK [PERMANENTFLAGS ()] Permanent flags
fetchmail: IMAP< * OK [UNSEEN 733] Is the first unseen message
fetchmail: IMAP< * OK [UIDVALIDITY 14] UIDVALIDITY value
fetchmail: IMAP< * OK [UIDNEXT 57199] The next unique identifier value
fetchmail: IMAP< A0005 OK [READ-ONLY] EXAMINE completed.
fetchmail: IMAP> A0006 SEARCH UNSEEN UNDELETED
fetchmail: IMAP< * SEARCH 733 734 735 736 737 738 739 740 741 742 743 744 745 746 747 748 749 750 751 752 753 754 755 756 757 758 759 760 761 762 763 764 765 770 771 772 773 774 776 777 778 779 780 781 782 783 784 785 786 787 788 789 790 791 792 793
fetchmail: IMAP< A0006 OK SEARCH completed.
793 messages (737 seen) for логин at poll2.
fetchmail: IMAP> A0007 LOGOUT
fetchmail: IMAP< * BYE Microsoft Exchange Server 2013 IMAP4 server signing off.
fetchmail: IMAP< A0007 OK LOGOUT completed.
fetchmail: 6.3.26 querying poll2 (protocol IMAP) at Вт 27 июл 2021 14:22:16: poll completed
fetchmail: normal termination, status 0



Получается, что на первом компьютере программа по какой-то причине не может начать сеанс TLS с сервером
Конфиги программы ~/.fetchmailrc совпадают
При этом на первом компьютере с сервера яндекс.почты fetchmail загружает письма без проблем. То есть проблема возникает только с одним сервером.

[Jula0071]

Смотрите версии openssl и их поддерживаемые protocols and ciphers.
openssl version
openssl ciphers -v
openssl ciphers -v | grep ECDHE-RSA-AES256-SHA384 для проверки поддержки конкретного сайфера, который использует второй компьютер.
Также можно просканировать сервер на тему поддерживаемых протоколов и сайферов при помощи sslscan (https://github.com/rbsec/sslscan) или аналогов.

Скорее всего вам просто нужно обновить версию openssl/libssl на первом компьютере. Или разрешить не сервере, если он под вашим управлением, доступные первому пк протоколы и сайферы. В общем, согласовать версии.

[El Scorpio]

Завтра напишу версию и параметры первого компьютера.

А пока вопрос - как добавить указанный cipher клиенту?

[Jula0071]

как добавить указанный cipher клиенту? »
Ну не обязательно конкретно этот. Обычно и сервер, и клиент поддерживают десятки сайферов, как раз чтоб не было проблем с хендшейками у разных клиентов с разными серверами на разных системах разной свежести. Нужно чтоб совпал хотя бы один. Если в дебиановской версии openssl/libssl по каким-то причинам вырезали все сайферы, предлагаемые данным сервером, то способ только один - пересобрать их вручную с поддержкой этих сайферов.

Кстати вот команда в помощь для теста совместимости openssl s_client -starttls imap -connect server.ru:143

[El Scorpio]

Нужный сайфер оказался в списке доступных. Для его использования достаточно было закомментировать в конфиге /etc/ssl/openssl.cnf одну строку


[system_default_sect]
MinProtocol = TLSv1.2
### CipherString = DEFAULT@SECLEVEL=2




Теперь возникла вторая проблема

fetchmail: Ошибка проверки сертификата сервера: unable to get local issuer certificate
fetchmail: Broken certification chain at: /DC=RU/DC=IRR/CN=IRR-CA-Root
fetchmail: This could mean that the server did not provide the intermediate CA's certificate(s), which is nothing fetchmail could do anything about. For details, please see the README.SSL-SERVER document that ships with fetchmail.
fetchmail: This could mean that the root CA's signing certificate is not in the trusted CA certificate location, or that c_rehash needs to be run on the certificate directory. For details, please see the documentation of --sslcertpath and --sslcertfile in the manual page.
fetchmail: OpenSSL reported: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed

Как я понимаю, клиент не может проверить цепочку центров выдачи сертификатов из-за отсутствия промежуточных
Увы, в самом сертификате ссылка на родительский центр выдачи сертификатов выглядит так

openssl x509 -in ./test.pem -noout -text | grep -i uri
URI:ldap:///CN=IRR-CA-Root,CN=VS-I-DC01,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=IRR,DC=RU?certificateRevocati onList?base?objectClass=cRLDistributionPoint
CA Issuers - URI:ldap:///CN=IRR-CA-Root,CN=AIA,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=IRR,DC=RU?cACertificate?base? objectClass=certificationAuthority

Как я понимаю, цепочка центров выдачи сертификатов скрыта в внутри домена. Просто скачать их не получится. Почему же тогда второй компьютер открывает почтовый ящик?
Или можно в настройках SSL отключить проверку цепочки?

[Jula0071]

Как я понимаю, цепочка центров выдачи сертификатов скрыта в внутри домена. »
Просто CN=IRR-CA-Root не является trusted root CA. А так-то сервер должен отдавать всю цепочку (кроме необязательного "настоящего" root CA). Хотя конечно мало ли что там нарукожоплено, при таком-то подходе.
Что даёт openssl s_client -showcerts -starttls imap -connect server.ru:143 ?
Если у последнего в цепочке subject и issuer совпадают, то достаточно просто проинсталить этот сертификат на клиенте.
Админу того сервера пора пинка дать, серты стоят гроши или вообще ничего в случае летсенкрипт, за колхозинг с самоподписными сертами, которые не проинсталены сразу у клиентов нужно переводить в мойщики унитазов гг.
Почему же тогда второй компьютер открывает почтовый ящик? »
Насколько понял, у фетчмайла проверка сертификатов по умолчанию включена начиная с версии 6.4.
Или можно в настройках SSL отключить проверку цепочки? »
Можно, в настройках фетчмайла.

--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.

[El Scorpio]

Насколько понял, у фетчмайла проверка сертификатов по умолчанию включена начиная с версии 6.4. »
АльтЛинукс пока использует версию 6.3.26+GSS+RPA+NTLM+SDPS+SSL-SSLv2-SSLv3+NLS+KRB5.
Получается, что здесь достаточно проверки отпечатка (fingerprint)

А debian - уже версию 6.4.0.beta4. Поэтому при одинаковых конфигах возникает ошибка проверки цепочки.
Завтра добавлю в конфиг параметр nosslcertck и посмотрю, что получится.

[Jula0071]

параметр nosslcertck »
Только no sslcertck раздельно, судя по ману.

[El Scorpio]

Спасибо. Всё заработало!