Как понять причину не коннекта к SMTP по SSL?

У одного, была проблема в пути к файлу сертификата: https://serverfault.com/questions/1147188/dovecot-ssl-not-working-no-suitable-signature-algorithm-other-daemons-work-j

Повесить openssl s_server -cert <CERTFILE> -key <KEYFILE> -port <MY_PORT> -trace, направить железяку туда и попробовать понять, что она умеет.

Ну есть же stunnel.

Где-то поднять сервер, который будет слушать 25 незащищенный, а при новом коннекте обращаться на нужный сервер с правильным tls.

Вот буржуины советуют

Коннект идет на 465 порт, а причем здесь довекот? Править надо конфиг постфикса.

Как ни странно, но -trace у меня нет такого параметра. Какой-то эдакий openssl, причём он в этом же выводе хелпа указан типа есть -msg для использования вместе с -trace, а самого -trace нет... странно...

# openssl version
OpenSSL 1.1.1w  11 Sep 2023


# openssl s_server -cert ./certs/cert.pem -key ./certs/key.pem -port 2525
Using default temp DH parameters
ACCEPT
-----BEGIN SSL SESSION PARAMETERS-----
MHUCAQECAgMDBAIAPAQgFhfwaXv463u5M948AwsQR+cv9avPCM99I1GmZKLaqKME
MP7+fW2EVx9RuFJJ8oGgi40HefUnQiqx/IG6MKbgqo8e5FBKY77C7dBqesshhoo6
naEGAgRoToOPogQCAhwgpAYEBAEAAAA=
-----END SSL SESSION PARAMETERS-----
Shared ciphers:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA
Signature Algorithms: RSA+SHA512:RSA+SHA384:RSA+SHA256:RSA+SHA224:RSA+SHA1:0x01+0x01
Shared Signature Algorithms: RSA+SHA512:RSA+SHA384:RSA+SHA256:RSA+SHA224
CIPHER is AES128-SHA256
Secure Renegotiation IS supported
220 mail.server.gov Dovecot ready.
HELO LocalHost
250 mail.server.gov
AUTH LOGIN
334 VXNlcm5hbWU6
YWRtaW5Ac2VydmVyLmdvdg==
^C

$netstat -lnp
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 0.0.0.0:465             0.0.0.0:*               LISTEN      16/dovecot
tcp        0      0 0.0.0.0:587             0.0.0.0:*               LISTEN      16/dovecot

проксит он через себя, я так понимаю для авторизации

То есть, эта железяка успешно поговорила с тем же openssl, который используется почтовиком?

А другие клиенты в него на 465 порт нормально ходят?

Выглядит как да... Поговорила. И да другие клиенты на 465 порт ходят...
Но что любопытно, на 587ой порт она не смогла зайти. Пробовал повесить openssl s_server на 587 порт, там сразу дисконнект. Пробовал mitmproxy на 587 порт для этой железки, и там тоже дисконнект. Нашёл какие-то упоминания в issue mitmproxy что какая то из реализаций uTLS (микроТЛС) библиотеки имеет такой косяк, возможно мой случай с TLS.

Взял stunnel в режиме SMTP:25 -> SSL/TLS 465/587 и всё прекрасно работает. Да, это костыль. Первопричина пока не понятна, неужели никто не пользовал TLS/SSL в этих DVR... Не верю...

неужели никто не пользовал TLS/SSL в этих DVR...

С учетом описания в виде «китайский DVR», не исключено что и никто. Во всяких непознанных железках не редкость, что заявленное != рабочее.

В этой стране с некоторых пор с SSL баальшие проблемы, не имеющие отношения к техническим вопросам.

В этой стране с некоторых пор с SSL баальшие проблемы

Если бы были баальшие проблемы, то это считайте почти весь вэб на север.

OFFTOPIC

Ну кстати, у меня пара очень старых (10+ лет как) серверов в Хецнере из разряда - работает не трожь, последнее время https (даже любопытно стало, что там SSL или TLS «уже») отдают через раз, а то и через 2 :(
При этом tunel на другой сервер на этот же Хецнер и с него эти сервера прекрасно всё отдают.

no shared cipher

по моему тут видно что не смогли согласовать протоколы…

Если это у вас постфикс, то там можно включить отладку tls/ssl в логах

smtpd_tls_loglevel = 1 # или больше 1
smtpd_tls_received_header = yes

Из моей деревни это выглядит так:

$ telnet 188.232.165.188 465
Trying 188.232.165.188...
telnet: connect to address 188.232.165.188: Connection refused

$ telnet 188.232.165.188 25
Trying 188.232.165.188...
telnet: connect to address 188.232.165.188: Connection refused

Правильно должно быть так:

#openssl

OpenSSL> s_client -connect 188.232.165.188:465

Там до ssl дело не доходит.
Там сразу приходит RST.

debug_peer_level = 3

Ну 188.232.165.188 это вообще то мой IP да ещё и динамический и с сотовой сети...
Что бы там что-то было то?

rip=188.232.165.188, rport=56714, lip=192.168.203.5, lport=465

rip=188.232.165.188, rport=56714, lip=192.168.203.5, lport=465,

Да, я не смог догадаться, что можной просто взять и зайти с внешнего ip на внутренний, хотя rport=56714 и lport=465 должен был насторожить.

Это так выглядит когда идёшь на сервис внутри докера. Уж не вдавался в подробности как так, но скорее всего DNAT

Привет! Исходя из твоих сообщений вижу, что у Вас установлен почтовик на базе mailu (судя по внутреннему дефолтному для его докера IP).

Источник проблемы: регистратор НЕ понимает современные ECDSA сертификаты, плюс у него устаревший допустимый набор шифров (ciphers).

Для решения проблемы с регистратором тебе нужно:

1. Перевыпустить сертификат, вместо ECDSA выпустить RSA. Каким образом - Вам виднее, смотря как его выпускали. Тот же LE позволяет выпускать как RSA, так и ECDSA сертификаты.
2. Подставить на своём сервере в mailu новые сертификаты, по-умолчанию они в /mailu/certs/
3. В папке с mailu (допустим, /mailu) нужно создать файл /mailu/overrides/nginx/dovecot/proxy.conf с таким содержимым:

ssl_cipher_list = ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:TLS_RSA_WITH_AES_128_CBC_SHA256:TLS_RSA_WITH_AES_256_CBC_SHA256:TLS_RSA_WITH_AES_128_CBC_SHA:TLS_RSA_WITH_AES_256_CBC_SHA

4. Перезапустить контейнер

docker compose restart front

5. В регистраторе в качестве SMTP выбрать порт 465, шифрование SSL.

После всех этих манипуляций регистратор с почтовиком смогут договориться и он сможет отправлять письма (будь он [вырезано цензурой] неладен).

Если не получится, то помогу. Телега Shturmn