Ошибка tls connection error

exim4: Проблемы с TLS при попытке получения писем с *.outbound.protection.outlook.com

Тарифы на хостинг в России, от 12 рублей: https://www.host-food.ru/tariffs/hosting/
Тарифы на виртуальные сервера (VPS/VDS/KVM) в РФ, от 189 руб.: https://www.host-food.ru/tariffs/virtualny-server-vps/
Выделенные сервера, Россия, Москва, от 2000 рублей (HP Proliant G5, Intel Xeon E5430 (2.66GHz, Quad-Core, 12Mb), 8Gb RAM, 2x300Gb SAS HDD, P400i, 512Mb, BBU):
https://www.host-food.ru/tariffs/vydelennyi-server-ds/
Недорогие домены в популярных зонах: https://www.host-food.ru/domains/

Попробуйте для начала обновить у себя корневые сертификаты.
Для FreeBSD это делается так

xM писал(а):Попробуйте для начала обновить у себя корневые сертификаты.
Для FreeBSD это делается так

Спасибо за отклик. Проверил корневые сертификаты у себя. В дебиане это пакет ca-certificates, на всякий случай переустановил его:

apt-get install --reinstall ca-certificates

Подключил неподключенные:

dpkg-reconfigure ca-certificates
update-ca-certificates -f
c_rehash /etc/ssl/certs

Рестартанул exim. Проверил ssl соединение:

openssl s_client -connect mta.medlife.perm.ru:465 -tls1 -servername mta.medlife.perm.ru

CONNECTED(00000003)
depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
verify return:1
depth=1 C = US, O = Let’s Encrypt, CN = Let’s Encrypt Authority X3
verify return:1
depth=0 CN = mta.medlife.perm.ru
verify return:1
—
Certificate chain
0 s:/CN=mta.medlife.perm.ru
i:/C=US/O=Let’s Encrypt/CN=Let’s Encrypt Authority X3
1 s:/C=US/O=Let’s Encrypt/CN=Let’s Encrypt Authority X3
i:/O=Digital Signature Trust Co./CN=DST Root CA X3
—
Server certificate
——BEGIN CERTIFICATE——
MIIFCTCCA/GgAwIBAgISA9KGM+pM6hoO5Vr11qAROOHDMA0GCSqGSIb3DQEBCwUA
MEoxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MSMwIQYDVQQD
ExpMZXQncyBFbmNyeXB0IEF1dGhvcml0eSBYMzAeFw0xODAxMTkxMTEzMjlaFw0x
ODA0MTkxMTEzMjlaMB4xHDAaBgNVBAMTE210YS5tZWRsaWZlLnBlcm0ucnUwggEi
MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4VcgN1c5xf568S1B+9xvP5JX7
jTIVjAHBMy8gIiuHSdkmC+wrSXL4kY0mbQ3mF1ewtH+4akbE5SEybrm8WqyDxYhN
oCrDnyzMi/Dlo2JLpGLpFbLl2j3tPfqbo7UsomhUAZ+k0LNQAVzoIX0KtUrDiQTK
dqJNPcjrXunsxBGKWJW/LBx9/KCnmZWALmezvV1z2Q4F72oXjvaqfXcfcU6VuP2u
byFxCwaVQbSIfaYyPUooIZJnAyZLwlctIuFP57miY/xdJ+MbPkYzCUygkdlM6xnY
5GiszUMCiTaYh5UBAN9Na1LHofNh++Ets72hGbaNTCkutanyvRCn3Sp98tZhAgMB
AAGjggITMIICDzAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwEG
CCsGAQUFBwMCMAwGA1UdEwEB/wQCMAAwHQYDVR0OBBYEFGBJEfSpWaNg0rDMRAKC
wH/3CsQjMB8GA1UdIwQYMBaAFKhKamMEfd265tE5t6ZFZe/zqOyhMG8GCCsGAQUF
BwEBBGMwYTAuBggrBgEFBQcwAYYiaHR0cDovL29jc3AuaW50LXgzLmxldHNlbmNy
eXB0Lm9yZzAvBggrBgEFBQcwAoYjaHR0cDovL2NlcnQuaW50LXgzLmxldHNlbmNy
eXB0Lm9yZy8wHgYDVR0RBBcwFYITbXRhLm1lZGxpZmUucGVybS5ydTCB/gYDVR0g
BIH2MIHzMAgGBmeBDAECATCB5gYLKwYBBAGC3xMBAQEwgdYwJgYIKwYBBQUHAgEW
Gmh0dHA6Ly9jcHMubGV0c2VuY3J5cHQub3JnMIGrBggrBgEFBQcCAjCBngyBm1Ro
aXMgQ2VydGlmaWNhdGUgbWF5IG9ubHkgYmUgcmVsaWVkIHVwb24gYnkgUmVseWlu
ZyBQYXJ0aWVzIGFuZCBvbmx5IGluIGFjY29yZGFuY2Ugd2l0aCB0aGUgQ2VydGlm
aWNhdGUgUG9saWN5IGZvdW5kIGF0IGh0dHBzOi8vbGV0c2VuY3J5cHQub3JnL3Jl
cG9zaXRvcnkvMA0GCSqGSIb3DQEBCwUAA4IBAQCQPkqrjIs5uDazD+cPXew18tMv
63pJqRoqzx5Sj3Wtl3AlCkK7TyU0yN2Z0mTWFRmRKUoQkktu/PncwwR7gCpxO5Jv
DgHs6ulZH4vSyipL6+SrMQHJ7drE3DQRrDAC+aeB+T0zbxwO1i/8nYxArz6GN8eb
QlPouHerW32ftV6aFFrsKzu6H5JbfXqufCzduXrqx8iP8PekEtm5yTXLLY0V7soY
wh1jmm4PVV7d5oVOiQFg7hkWGWdL6iFJGEhUX1UPg/V30ytew58+pk2Eq8nwwKan
PDj/V4jjHKeybV0a7K3G09o7NXhkXWxoQmtIenrZQcMqP44yvuAJxahWZVR3
——END CERTIFICATE——
subject=/CN=mta.medlife.perm.ru
issuer=/C=US/O=Let’s Encrypt/CN=Let’s Encrypt Authority X3
—
No client certificate CA names sent
Server Temp Key: ECDH, P-256, 256 bits
—
SSL handshake has read 2993 bytes and written 268 bytes
Verification: OK
—
New, TLSv1.0, Cipher is ECDHE-RSA-AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1
Cipher : ECDHE-RSA-AES256-SHA
Session-ID: BF9624F0AE5BDFA317F7A6F624114F8EDDA0F5BA36EACAC451D51AADE944A563
Session-ID-ctx:
Master-Key: D3F861250549EECB0E4A5955F95BAEAB84658FA45751186483F8D630A07D4C9A76C6FE8574E0A8A623E542C9720AFAB1
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1516794076
Timeout : 7200 (sec)
Verify return code: 0 (ok)
Extended master secret: yes
—
220 mta.medlife.perm.ru ESMTP Exim 4.89 Wed, 24 Jan 2018 16:41:16 +0500
ehlo mta.medlife.perm.ru
250-mta.medlife.perm.ru Hello localhost [127.0.0.1]
250-SIZE 27262976
250-8BITMIME
250-PIPELINING
250 HELP
QUIT
DONE

Проверил STARTTLS:

swaks -a -tls -q HELO -s mta.medlife.perm.ru -au test -ap '<>'

=== Trying mta.medlife.perm.ru:25…
=== Connected to mta.medlife.perm.ru.
<- 220 mta.medlife.perm.ru ESMTP Exim 4.89 Wed, 24 Jan 2018 16:44:04 +0500
-> EHLO mta.medlife.perm.ru
<- 250-mta.medlife.perm.ru Hello localhost [127.0.0.1]
<- 250-SIZE 27262976
<- 250-8BITMIME
<- 250-PIPELINING
<- 250-STARTTLS
<- 250 HELP
-> STARTTLS
<- 220 TLS go ahead
=== TLS started with cipher TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256
=== TLS no local certificate set
=== TLS peer DN=»/CN=mta.medlife.perm.ru»
~> EHLO mta.medlife.perm.ru
<~ 250-mta.medlife.perm.ru Hello localhost [127.0.0.1]
<~ 250-SIZE 27262976
<~ 250-8BITMIME
<~ 250-PIPELINING
<~ 250 HELP
~> QUIT
<~ 221 mta.medlife.perm.ru closing connection
=== Connection closed with remote host.

И всё равно коннекты с *.outbound.protection.outlook.com висят подолгу, плодятся, затем отваливаются с вышеописанными ошибками

Кстати, а в EXIM есть возможность журналировать SMTP сеанс, в смысле какие команды и сообщения в сеансе посылаются? Судя по логам сама сессия начинается, происходит проверка SPF письма, конверт письма передаётся, и на сём сессия зависает. У меня есть подозрение что с шифрованием что то не так. При чём от гугла письма приходят.
Самое обидное, что в письмах этих шлётся код верификации для входа в кабинет с лицензиями и дистрибутивами.

Может подскажет кто, как заставить именно эти сервера без не стартовать TLS?

Отправлено спустя 10 минут 23 секунды:
Упс, кажется добился от них любви и ласки. Установил правило кое пропускает все проверки для их писем и письма стали ходить. Завтра поразбираюсь на каком правиле у меня виснет.

Нашел я правило, на коем подвисает коннект и валится сессия:

# Проверка существования адреса отправителя
warn
        hosts           = !+relay_from_hosts
        !verify         = sender/callout=3m,defer_ok
        logwrite        = [WARN][ACCC] Sender callout verify is invalid 
                          H=$sender_helo_name[$sender_host_address] F=$sender_address T:$local_part@$domain
        set acl_c_spamscore     = ${eval:$acl_c_spamscore+20}
        set acl_c_spamlog       = $acl_c_spamlog Callout error;

Теперь осталось выяснить какое решение принять по этому поводу. Похоже ряд других почтовых серверов, чьи письма так же нужны, тоже не проходят проверку на существование почтового ящика.

ladserg писал(а): !verify = sender/callout=3m,defer_ok

Это очень плохая практика. Рекомендую отказаться от callouts совершенно.

Отправлено спустя 1 минуту :
Чтобы долго не писать, вот вам статья где умный дядя всё по полочкам раскладывает
https://bsdly.blogspot.lt/2017/08/twent … s-are.html

xM писал(а):

ladserg писал(а): !verify = sender/callout=3m,defer_ok

Это очень плохая практика. Рекомендую отказаться от callouts совершенно.

Отправлено спустя 1 минуту :
Чтобы долго не писать, вот вам статья где умный дядя всё по полочкам раскладывает
https://bsdly.blogspot.lt/2017/08/twent … s-are.html

Понятно. Похоже я научился на собственной ошибке. За ссылку спасибо, хоть с англицким у меня плохо, но гугл-переводчик помог понять из статьи, что проверка сия не столь актуальна и может быть даже чревата. Вернее она стала чревата в моём случае.

Я правильно понял, что при обратной проверке на проверяемом сервере так же запускаются проверки на мою проверку, на которые мой сервер так же может запустить свои проверки?

Да, грубо говоря, callout мало что даёт и, тем более гарантирует, создаёт нагрузку на обе системы, более того, если спамер использует несуществующий адрес в чужом домене, то callout с вашего сервера выглядит как попытка отправить туда спам, и, таким образом, вы можете попасть в spam trap с последующим баном вашего IP.

Отправлено спустя 38 секунд:

ladserg писал(а):
Я правильно понял, что при обратной проверке на проверяемом сервере так же запускаются проверки на мою проверку, на которые мой сервер так же может запустить свои проверки?

Смотря что там настроено, но, обычно, маловероятно.

Please try regenerating certificates manually by:

docker-machine --debug regenerate-certs -f default

and check for any errors to fix, then try again:

docker-machine --debug env default

If it’s failing on ssh, copy and paste that command into terminal to see what’s the problem by adding extra -vv.

If you’ve got:

debug1: connect to address 127.0.0.1 port 64368: Connection refused

then your machine isn’t running (check by docker-machine ls), so try:

docker-machine start

Then try to ssh to it via:

docker-machine -D ssh default

answered Mar 11, 2016 at 12:34

After doing some research I found out that following workaround may solve the issue for now:

1. Open Network And Sharing Center

2. Click on Change Adapter Setting

3. See if you have any enabled adapters such as VPN or VM Ware network adapters.

4. Try to disable them and try to connect to your container one more time

5. If it didn’t work while you have other adapters disabled, Restart your PC — in my case this worked for me.

What worked for me is this answer from the docker-machine repo:

docker-machine regenerate-certs --client-certs [name]

Basically, what expired is client certificates. The error message I get from docker-machine is similar to yours (i.e., no indication it’s the client certs that need to be regenerated).

answered Sep 7, 2020 at 1:31

Pablo BianchiPablo Bianchi

1,6361 gold badge23 silver badges30 bronze badges

jaycodejaycode

2,9164 gold badges34 silver badges71 bronze badges

invzhiinvzhi

361 silver badge2 bronze badges

Just start the docker machine and then regenerate certificates

docker-machine start <machine-name>

docker-machine regenerate-certs <machine-name>

It works like a charm for me.

answered Mar 12, 2019 at 8:42

The way I ensure being able to connect to my docker machines is by assigning them a fixed IP (and regenerating the certs only once) (no reboot needed)

After that, docker-machine ls always work.

My current script:
(replace %PRGS%dmlatest by the path where docker-machine.exe is on your machine)
(make sure PATH include the latest /path/to/git/usr/bin, for commands like ssh to be available)

> more dmvbf.bat
@echo off
setlocal enabledelayedexpansion
set machine=%1
if "%machine%" == "" (
        echo dmvbf expects a machine name
        exit /b 1
)
set ipx=%2
if "%ipx%" == "" (
        echo dmvbf x missing ^(for 192.168.x.y^)
        exit /b 2
)
set ipy=%3
if "%ipy%" == "" (
        echo dmvbf y missing ^(for 192.168.x.y^)
        exit /b 3
)

%PRGS%dmlatestdocker-machine.exe ssh %machine% "sudo sh -c 'echo "kill $(more /var/run/udhcpc.eth1.pid)" | sudo tee /var/lib/boot2docker/bootsync.sh >/dev/null'"
%PRGS%dmlatestdocker-machine ssh %machine% "sudo sh -c 'echo "ifconfig eth1 192.168.%ipx%.%ipy% netmask 255.255.255.0 broadcast 192.168.%ipx%.255 up" | sudo tee -a /var/lib/boot2docker/bootsync.sh >/dev/null'"

%PRGS%dmlatestdocker-machine ssh %machine% "sudo chmod 755 /var/lib/boot2docker/bootsync.sh"

%PRGS%dmlatestdocker-machine ssh %machine% "sudo cat /var/run/udhcpc.eth1.pid | xargs sudo kill"

%PRGS%dmlatestdocker-machine ssh %machine% "sudo ifconfig eth1 192.168.%ipx%.%ipy% netmask 255.255.255.0 broadcast 192.168.%ipx%.255 up"

For instance:

dmvbf default 99 100
docker-machine regenerate-certs -f default

That will assign 192.168.99.100 to the docker machine ‘default‘, and regenerate the certs once.
Then each time docker-machine ls is called, it will display the same IP for ‘default‘.

GusterGuster

1,5841 gold badge15 silver badges18 bronze badges

aureliusaurelius

3,8866 gold badges40 silver badges73 bronze badges

answered Nov 26, 2019 at 0:13

VimNingVimNing

1,7544 gold badges27 silver badges56 bronze badges