Я в тупике по этому поводу. У меня еще используется Exchange Server 2003. Я создал действительный сертификат LetsEncrypt SSL и успешно импортировал pfx в свойства виртуального SMTP-сервера по умолчанию на вкладке «Доступ». Теперь клиентам, отправляющим EHLO, сообщается, что STARTTLS доступен. Но некоторые из моих почтовых клиентов (которые должны быть настроены на использование STARTTLS, если они доступны) перестали отправлять почту. Я использовал Wireshark, чтобы наблюдать успешные электронные письма перед добавлением сертификата (выполняется аутентификация) и снова после добавления сертификата. После добавления сертификата EHLO указывает, что STARTTLS доступен. Клиент отправляет STARTLS. Сервер отвечает: «Сервер SMTP 2.0.0 готов». Клиент отправляет SSL-клиент Hello, и через 10 мс SMTP-сервер закрывает соединение (FIN, пакет ACK отправляется обратно клиенту). Это конец.
Не знаю, как это диагностировать. В журнале событий ничего нет. У меня есть журнал в папке Windows LogFIles SMTPSvc1. Вот что он показывает, когда указан STARTTLS и сервер вешает трубку:
2017-10-28 14:20:01 192.168.5.80 localhost 250 0 110
2017-10-28 14:20:01 192.168.5.80 localhost 220 0 0
2017-10-28 14:20:01 192.168.5.80 localhost 220 0 0
2017-10-28 14:20:01 192.168.5.80 localhost 503 2148074248 31
2017-10-28 14:20:01 192.168.5.80 localhost 240 203 31
Для справки, когда я удаляю сертификат, поэтому STARTTLS не отправляется, клиент аутентифицируется, а затем успешно отправляет, и вот записи журнала:
2017-10-28 13:43:26 192.168.5.80 localhost 250 0 0
2017-10-28 13:43:26 192.168.5.80 localhost 250 0 0
2017-10-28 13:43:26 192.168.5.80 localhost 250 0 0
2017-10-28 13:43:26 192.168.5.80 localhost 250 0 281
2017-10-28 13:43:26 192.168.5.80 localhost 240 703 0
И если кто-то знает, что здесь, и это может быть полезно, вот два последних отслеживаемых пакета - Client Hello и зависание RST ...
No. Time Source Destination Protocol Length Info
17 2017-10-28 09:41:05.669172000 192.168.5.80 192.168.1.11 SSL 583 Client Hello
Frame 17: 583 bytes on wire (4664 bits), 583 bytes captured (4664 bits) on interface 0
Internet Protocol Version 4, Src: 192.168.5.80 (192.168.5.80), Dst: 192.168.1.11 (192.168.1.11)
Transmission Control Protocol, Src Port: 48022 (48022), Dst Port: 25 (25), Seq: 27, Ack: 485, Len: 517
Source Port: 48022 (48022)
Destination Port: 25 (25)
[Stream index: 1]
[TCP Segment Len: 517]
Sequence number: 27 (relative sequence number)
[Next sequence number: 544 (relative sequence number)]
Acknowledgment number: 485 (relative ack number)
Header Length: 32 bytes
.... 0000 0001 1000 = Flags: 0x018 (PSH, ACK)
Window size value: 237
[Calculated window size: 30336]
[Window size scaling factor: 128]
Checksum: 0x87d7 [validation disabled]
Urgent pointer: 0
Options: (12 bytes), No-Operation (NOP), No-Operation (NOP), Timestamps
[SEQ/ACK analysis]
Secure Sockets Layer
SSL Record Layer: Handshake Protocol: Client Hello
Content Type: Handshake (22)
Version: TLS 1.0 (0x0301)
Length: 512
Handshake Protocol: Client Hello
Handshake Type: Client Hello (1)
Length: 508
Version: TLS 1.2 (0x0303)
Random
Session ID Length: 0
Cipher Suites Length: 124
Cipher Suites (62 suites)
Compression Methods Length: 1
Compression Methods (1 method)
Extensions Length: 343
Extension: server_name
Type: server_name (0x0000)
Length: 17
Server Name Indication extension
Server Name list length: 15
Server Name Type: host_name (0)
Server Name length: 12
Server Name: 192.168.1.11
Extension: ec_point_formats
Type: ec_point_formats (0x000b)
Length: 4
EC point formats Length: 3
Elliptic curves point formats (3)
Extension: elliptic_curves
Type: elliptic_curves (0x000a)
Length: 10
Elliptic Curves Length: 8
Elliptic curves (4 curves)
Extension: SessionTicket TLS
Type: SessionTicket TLS (0x0023)
Length: 0
Data (0 bytes)
Extension: signature_algorithms
Type: signature_algorithms (0x000d)
Length: 32
Signature Hash Algorithms Length: 30
Signature Hash Algorithms (15 algorithms)
Extension: Unknown 22
Type: Unknown (0x0016)
Length: 0
Data (0 bytes)
Extension: Unknown 23
Type: Unknown (0x0017)
Length: 0
Data (0 bytes)
Extension: Padding
Type: Padding (0x0015)
Length: 248
Padding Data: 000000000000000000000000000000000000000000000000...
No. Time Source Destination Protocol Length Info
18 2017-10-28 09:41:05.675195000 192.168.1.11 192.168.5.80 TCP 66 25→48022 [FIN, ACK] Seq=485 Ack=544 Win=64992 Len=0 TSval=52648030 TSecr=1233339601
Frame 18: 66 bytes on wire (528 bits), 66 bytes captured (528 bits) on interface 0
Internet Protocol Version 4, Src: 192.168.1.11 (192.168.1.11), Dst: 192.168.5.80 (192.168.5.80)
Transmission Control Protocol, Src Port: 25 (25), Dst Port: 48022 (48022), Seq: 485, Ack: 544, Len: 0
Source Port: 25 (25)
Destination Port: 48022 (48022)
[Stream index: 1]
[TCP Segment Len: 0]
Sequence number: 485 (relative sequence number)
Acknowledgment number: 544 (relative ack number)
Header Length: 32 bytes
.... 0000 0001 0001 = Flags: 0x011 (FIN, ACK)
Window size value: 64992
[Calculated window size: 64992]
[Window size scaling factor: 1]
Checksum: 0x9699 [validation disabled]
Urgent pointer: 0
Options: (12 bytes), No-Operation (NOP), No-Operation (NOP), Timestamps
[SEQ/ACK analysis]
Я почти уверен, что проблема в том, что старый SMTP-сервер Exchange Server 2003 поддерживает только TLS 1.0, который больше не считается таким безопасным. И очевидно, что он не поддержит ни одного из новых шифров. Итак, опять же без доказательств, я почти уверен, что другой конец зависал, потому что сообщение STARTTLS / Client Hello указывало, что протоколы и / или шифры, предлагаемые сервером и доступные на клиенте, не перекрываются. Я решил свою проблему, установив более современный SMTP-сервер (от hMailServer) между Exchange Server 2003 и остальным миром. И это решило мою проблему. Еще более удачным долгосрочным подходом будет удаление Exchange 2003 Server из среды.