Sohin Vyacheslav -> debian-russian@lists.debian.org @ Wed, 3 Feb 2016 19:54:48 +0200:
>> Начать с того, что если это реально telnet, а не специальный telnet с >> функцией TLS, то такая ошибка и должна быть. На 465 порту ожидается >> TLS-хендшейк, а вовсе не протокол telnet или SMTP. SV> нужен пакет telnet-ssl? Для отладки лучше взять openssl s_client, он как раз отладочный механизм. А так хоть браузером можно. HTTP, конечно, не получится, но TLS-то пройдет. >> Собственно, по идее, если проблема с сертификатами сервера, то ругаться >> должен клиент. Если клиент не ругается, а ругается сервер, то проблема, >> скорее всего, не в сертификатах. >> >> SV> пробовал объединить сертификаты >> SV> # cat /etc/ssl/domain.com.certificate /etc/ssl/intermediate.certificate >> >>> /etc/exim4/exim.crt >> >> А они при этом в формате PEM (Base64) или DER (бинарный)? Впрочем, >> такое сливание понимает openssl, за gnutls уверенности нет. >> SV> PEM >> И еще: а корневой сертификат, которым подписан intermediate, на клиенте >> точно есть и установлен как доверенный? >> SV> имеется в виду на почтовом клиенте? На клиенте, которым ты тестируешь TLS. Если ты тестируешь telnet-ssl, то про него должен знать openssl или сам telnet-ssl. Если openssl c_client - то openssl (он, впрочем, с недоверенным и сам соединится, просто пожалуется на недоверенность). Если gnutls-cli - то gnutls. Ну и разумеется, потом, когда ты будешь пытаться отдать туда почту почтовым клиентом, на почтовом клиенте или на общесистемном уровне для той библиотеки, которой пользуется этот клиент.
