Roundcube + Голубятня: ошибки SSL при попытке войти в систему

Я настраиваю mailserver использование Голубятни 2.2.13, Постфикса 2.11.3, и с Roundcube 1.1.1 соединения с ним. Roundcube работает на другом сервере в nginx/php-fpm. Оба сервера выполняют Debian Jessie с последними обновлениями и могут проверить с помощью ping-запросов друг друга. nmap от хоста Roundcube показывает порту 993 открытых и доступные. Кроме того, я, кажется, получаю соединение на правильных портах, но я, может казаться, не заставляю Roundcube соединяться с Голубятней успешно.

Голубятня настроена со следующей работой настроек SSL порта 993:

/etc/dovecot/conf.d/10-ssl.conf

ssl_protocols = TLSv1.2 TLSv1.1 TLSv1 !SSLv2 !SSLv3
ssl_cipher_list = ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES128:DH+AES:ECDH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5

/etc/dovecot/dovecot.conf

auth_verbose=yes
auth_debug=yes
auth_debug_passwords=yes
mail_debug=yes
verbose_ssl=yes
auth_verbose_passwords=plain

С этими настройками я могу получить соединение TLS из почтового приложения Android и получить письма, таким образом, я знаю, что Голубятня слушает и способная к передаче. Roundcube размещается на другом сервере от Голубятни и настроен со следующими настройками относительно IMAPS.

$config['default_host'] = 'tls://mail.domain.tld';
$config['imap_conn_options'] => array(
    'ssl' => array(
        'ciphers' => 'ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES128:DH+AES:ECDH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5',
    ),
);

Успешный вход в систему выглядит примерно так в mail.log:

dovecot: imap-login: Debug: SSL: elliptic curve secp384r1 will be used for ECDH and ECDHE key exchanges
dovecot: imap-login: Debug: SSL: elliptic curve secp384r1 will be used for ECDH and ECDHE key exchanges
dovecot: imap-login: Debug: SSL: where=0x10, ret=1: before/accept initialization [zzz.zzz.zzz.zzz]
dovecot: imap-login: Debug: SSL: where=0x2001, ret=1: before/accept initialization [zzz.zzz.zzz.zzz]
dovecot: imap-login: Debug: SSL: where=0x2001, ret=1: unknown state [zzz.zzz.zzz.zzz]
dovecot: imap-login: Debug: SSL: where=0x2001, ret=1: unknown state [zzz.zzz.zzz.zzz]
dovecot: imap-login: Debug: SSL: where=0x2001, ret=1: unknown state [zzz.zzz.zzz.zzz]
dovecot: imap-login: Debug: SSL: where=0x2001, ret=1: unknown state [zzz.zzz.zzz.zzz]
dovecot: imap-login: Debug: SSL: where=0x2001, ret=1: unknown state [zzz.zzz.zzz.zzz]
dovecot: imap-login: Debug: SSL: where=0x2001, ret=1: unknown state [zzz.zzz.zzz.zzz]
dovecot: imap-login: Debug: SSL: where=0x2002, ret=-1: unknown state [zzz.zzz.zzz.zzz]
dovecot: imap-login: Debug: SSL: where=0x2002, ret=-1: unknown state [zzz.zzz.zzz.zzz]
dovecot: auth: Debug: Loading modules from directory: /usr/lib/dovecot/modules/auth
dovecot: auth: Debug: Read auth token secret from /var/run/dovecot/auth-token-secret.dat
dovecot: auth: Debug: auth client connected (pid=5986)
dovecot: imap-login: Debug: SSL: where=0x2001, ret=1: unknown state [zzz.zzz.zzz.zzz]
dovecot: imap-login: Debug: SSL: where=0x2001, ret=1: unknown state [zzz.zzz.zzz.zzz]
dovecot: imap-login: Debug: SSL: where=0x2001, ret=1: unknown state [zzz.zzz.zzz.zzz]
dovecot: imap-login: Debug: SSL: where=0x20, ret=1: SSL negotiation finished successfully [zzz.zzz.zzz.zzz]
dovecot: imap-login: Debug: SSL: where=0x2002, ret=1: SSL negotiation finished successfully [zzz.zzz.zzz.zzz]

Принимая во внимание, что неудачный походит на это в mail.log:

dovecot: imap-login: Debug: SSL: elliptic curve secp384r1 will be used for ECDH and ECDHE key exchanges
dovecot: imap-login: Debug: SSL: elliptic curve secp384r1 will be used for ECDH and ECDHE key exchanges
dovecot: auth: Debug: auth client connected (pid=5993)
dovecot: imap-login: Debug: SSL: where=0x10, ret=1: before/accept initialization [xxx.xxx.xxx.xxx]
dovecot: imap-login: Debug: SSL: where=0x2001, ret=1: before/accept initialization [xxx.xxx.xxx.xxx]
dovecot: imap-login: Debug: SSL: where=0x202, ret=-1: SSLv2/v3 read client hello A [xxx.xxx.xxx.xxx]
dovecot: imap-login: Disconnected (no auth attempts in 60 secs): user=<> rip=xxx.xxx.xxx.xxx, lip=yyy.yyy.yyy.yyy, TLS handshaking: Disconnected, session=<xxxxxxxxxxxxxx>

Ошибка, которую регистрирует Roundcube:

<sj148mqa> IMAP Error: Login failed for firstname.lastname@domain.tld from xxx.xxx.xxx.xxx. Empty startup greeting (mail.domain.tld:993) in /var/www/roundcube/program/lib/Roundcube/rcube_imap.php on line 198 (POST /roundcube/?_task=login?_task=login&_action=login)

То, на что это походит, - то, что Roundcube игнорирует мой tls://директива и пытается соединиться с Dovecot, использующим SSLv2/v3, который Dovecot установлен проигнорировать. Таким образом, в то время как Dovecot ожидает Roundcube для запуска квитирования TLS, Roundcube ожидает сервера, приветствующего, который никогда не прибывает. Там какой-либо путь состоит в том, чтобы настроить Roundcube для соединения успешно? Я пропустил что-то очень простое в своей установке конфигурации?

Править:

В предложении Paul я попробовал вводный порт 143 и разрешение Roundcube использовать STARTTLS. Я смог получить соединение, но только если verify_peer был отключен. Изменение значений verify_peer_name и добавление пути и к цепочке CA, связанной с mailserver и к цепочечному mailserver сертификату, не позволили мне получать соединение с verify_peer=true.

Я полагаю, что это означает, что существует проблема с моим сертификатом SSL, соответствующим моему имени хоста. Существует две записи DNS для mailserver, указывающего на тот же адрес один для hostname.domain.tld и один для mail.domain.tld. Это могло заставлять проверку однорангового узла перестать работать?

2
задан 7 May 2015 в 17:20
1 ответ

Различное значение tls:// и ssl:// в $config['default_host'], к сожалению, не документировано.

  • tls:// означает использование STARTTLS, поэтому обычно порт 143
  • ssl:// означает использование TLS, поэтому обычно порт 993

  • То же самое относится и к $config['smtp_server'] и портам 25 и 587 для tls://, портам 465 для ssl://.

Не могу дать никаких источников для этой информации, так как я (и некоторые другие) получили ее эмпирическим путем.


А для вопроса verify_peer сначала посмотрите на cert, который подается. Например, используя эту команду с соединяющей машины:

echo | openssl s_client -connect mail.fizeau.net:143 -starttls imap -showcerts 2>&1 | openssl x509 -noout -text | egrep 'Subject: |DNS:'

Это покажет вам домены, для которых был выпущен cert.

.
6
ответ дан 3 December 2019 в 09:16

Теги

Похожие вопросы