Lorex DVR fails sending test email to a Synology MailPlus SMTP server using an ECC Let's Encrypt certificate

Question

My objective & issue

I want to have my Lorex DVR use my Synology NAS MailPlus Server to send email notifications, but there is a TLS connection failure, seemingly due to ciphers (tls_post_process_client_hello:no shared cipher).

What works

The MailPlus Server works just fine sending & receiving my regular emails with an Outlook client.
The DVR is able to send mail notifications via TLSv1.2 if I configure the DVR to send mail through the smtp server of mail.com.
The DVR is able to send notifications to my MailPlus Server on port 25 if I don't use SSL/TLS (as long as I Whitelist its IP in MailPlus).
The DVR is able to send notifications to my MailPlus Server on port 587 with TLS if the server uses a self-signed certificate (PKCS #1 SHA-256 With RSA Encryption) instead of a Let's Encrypt (ECDSA) certificate.

My investigation (kept for reference purpose since solution was found)

/volume1/@maillog/maillog

The important part is: "tls_post_process_client_hello:no shared cipher"

    postfix/smtpd[PID]: connect from DVR.mydomain.tld
    opendmarc[PID]: ignoring connection from DVR.mydomain.tld
    postfix/smtpd[PID]: connect from DVR.mydomain.tld[192.168.xxx.aaa]
    postfix/smtpd[PID]: SSL_accept error from DVR.mydomain.tld[192.168.xxx.aaa]: -1
    postfix/smtpd[PID]: warning: TLS library problem: error:1417A0C1:SSL routines:tls_post_process_client_hello:no shared cipher:ssl/statem/statem_srvr.c:2285:
    postfix/smtpd[PID]: lost connection after STARTTLS from DVR.mydomain.tld[192.168.xxx.aaa]
    postfix/smtpd[PID]: disconnect from DVR.mydomain.tld[192.168.xxx.aaa] ehlo=1 starttls=0/1 commands=1/2

I never investigated SSL connections before, but after some reading, I learned about the existence of ciphers.

tcpdump .pcap packet capture analyzed with Wireshark

DVR      SERVER TCP     74  38018 → 587 [SYN] Seq=0 Win=27200 Len=0 MSS=1360 SACK_PERM TSval=3847845792 TSecr=0 WS=128
SERVER   DVR    TCP     74  587 → 38120 [SYN, ACK] Seq=0 Ack=1 Win=14480 Len=0 MSS=1460 SACK_PERM TSval=685449855 TSecr=3859275362 WS=128
DVR      SERVER TCP     74  38120 → 587 [SYN] Seq=0 Win=27200 Len=0 MSS=1360 SACK_PERM TSval=3859275362 TSecr=0 WS=128
DVR      SERVER TCP     66  38120 → 587 [ACK] Seq=1 Ack=1 Win=27264 Len=0 TSval=3859275364 TSecr=685449855
SERVER   DVR    SMTP    94  S: 220 mydomain.tld ESMTP Postfix
DVR      SERVER TCP     66  38120 → 587 [ACK] Seq=1 Ack=29 Win=27264 Len=0 TSval=3859275732 TSecr=685450222
DVR      SERVER SMTP    82  C: EHLO localhost
SERVER   DVR    TCP     66  587 → 38120 [ACK] Seq=29 Ack=17 Win=14592 Len=0 TSval=685450225 TSecr=3859275732
SERVER   DVR    SMTP    215 S: 250-mydomain.tld | PIPELINING | SIZE 10485760 | ETRN | STARTTLS | ENHANCEDSTATUSCODES | 8BITMIME | DSN | SMTPUTF8 | CHUNKING
DVR      SERVER SMTP    76  C: STARTTLS
SERVER   DVR    SMTP    96  S: 220 2.0.0 Ready to start TLS
DVR      SERVER TLSv1.2 209 Client Hello
SERVER   DVR    TLSv1.2 73  Alert (Level: Fatal, Description: Handshake Failure)
DVR      SERVER TCP     66  38120 → 587 [FIN, ACK] Seq=170 Ack=215 Win=28288 Len=0 TSval=3859275742 TSecr=685450231
SERVER   DVR    TCP     66  587 → 38120 [FIN, ACK] Seq=215 Ack=171 Win=15616 Len=0 TSval=685450274 TSecr=3859275742
DVR      SERVER TCP     66  38120 → 587 [ACK] Seq=171 Ack=216 Win=28288 Len=0 TSval=3859275784 TSecr=685450274

Cipher suites proposed by DVR in Client Hello packet

Cipher Suites (31 suites)
    Cipher Suite: TLS_DH_DSS_WITH_AES_256_GCM_SHA384 (0x00a5)
    Cipher Suite: TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 (0x00a3)
    Cipher Suite: TLS_DH_RSA_WITH_AES_256_GCM_SHA384 (0x00a1)
    Cipher Suite: TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x009f)
    Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (0x006b)
    Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 (0x006a)
    Cipher Suite: TLS_DH_RSA_WITH_AES_256_CBC_SHA256 (0x0069)
    Cipher Suite: TLS_DH_DSS_WITH_AES_256_CBC_SHA256 (0x0068)
    Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039)
    Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x0038)
    Cipher Suite: TLS_DH_RSA_WITH_AES_256_CBC_SHA (0x0037)
    Cipher Suite: TLS_DH_DSS_WITH_AES_256_CBC_SHA (0x0036)
    Cipher Suite: TLS_RSA_WITH_AES_256_GCM_SHA384 (0x009d)
    Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA256 (0x003d)
    Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
    Cipher Suite: TLS_DH_DSS_WITH_AES_128_GCM_SHA256 (0x00a4)
    Cipher Suite: TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 (0x00a2)
    Cipher Suite: TLS_DH_RSA_WITH_AES_128_GCM_SHA256 (0x00a0)
    Cipher Suite: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x009e)
    Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (0x0067)
    Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 (0x0040)
    Cipher Suite: TLS_DH_RSA_WITH_AES_128_CBC_SHA256 (0x003f)
    Cipher Suite: TLS_DH_DSS_WITH_AES_128_CBC_SHA256 (0x003e)
    Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033)
    Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032)
    Cipher Suite: TLS_DH_RSA_WITH_AES_128_CBC_SHA (0x0031)
    Cipher Suite: TLS_DH_DSS_WITH_AES_128_CBC_SHA (0x0030)
    Cipher Suite: TLS_RSA_WITH_AES_128_GCM_SHA256 (0x009c)
    Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA256 (0x003c)
    Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
    Cipher Suite: TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00ff)

Synology OpenSSL ciphers

I thought maybe none of those TLSv1.2 ciphers were available on Synology, so I tried to check with openssl:

me@my_server:~$ openssl ciphers -V | grep TLSv1.2 | sort
0x00,0x3C - AES128-SHA256           TLSv1.2 Kx=RSA      Au=RSA  Enc=AES(128)  Mac=SHA256
0x00,0x3D - AES256-SHA256           TLSv1.2 Kx=RSA      Au=RSA  Enc=AES(256)  Mac=SHA256
0x00,0x67 - DHE-RSA-AES128-SHA256   TLSv1.2 Kx=DH       Au=RSA  Enc=AES(128)  Mac=SHA256
0x00,0x6B - DHE-RSA-AES256-SHA256   TLSv1.2 Kx=DH       Au=RSA  Enc=AES(256)  Mac=SHA256
0x00,0x9C - AES128-GCM-SHA256       TLSv1.2 Kx=RSA      Au=RSA  Enc=AESGCM(128) Mac=AEAD
0x00,0x9D - AES256-GCM-SHA384       TLSv1.2 Kx=RSA      Au=RSA  Enc=AESGCM(256) Mac=AEAD
0x00,0x9E - DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH       Au=RSA  Enc=AESGCM(128) Mac=AEAD
0x00,0x9F - DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH       Au=RSA  Enc=AESGCM(256) Mac=AEAD
0x00,0xA8 - PSK-AES128-GCM-SHA256   TLSv1.2 Kx=PSK      Au=PSK  Enc=AESGCM(128) Mac=AEAD
0x00,0xA9 - PSK-AES256-GCM-SHA384   TLSv1.2 Kx=PSK      Au=PSK  Enc=AESGCM(256) Mac=AEAD
0x00,0xAA - DHE-PSK-AES128-GCM-SHA256 TLSv1.2 Kx=DHEPSK   Au=PSK  Enc=AESGCM(128) Mac=AEAD
0x00,0xAB - DHE-PSK-AES256-GCM-SHA384 TLSv1.2 Kx=DHEPSK   Au=PSK  Enc=AESGCM(256) Mac=AEAD
0x00,0xAC - RSA-PSK-AES128-GCM-SHA256 TLSv1.2 Kx=RSAPSK   Au=RSA  Enc=AESGCM(128) Mac=AEAD
0x00,0xAD - RSA-PSK-AES256-GCM-SHA384 TLSv1.2 Kx=RSAPSK   Au=RSA  Enc=AESGCM(256) Mac=AEAD
0xC0,0x23 - ECDHE-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AES(128)  Mac=SHA256
0xC0,0x24 - ECDHE-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AES(256)  Mac=SHA384
0xC0,0x27 - ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AES(128)  Mac=SHA256
0xC0,0x28 - ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AES(256)  Mac=SHA384
0xC0,0x2B - ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AESGCM(128) Mac=AEAD
0xC0,0x2C - ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AESGCM(256) Mac=AEAD
0xC0,0x2F - ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AESGCM(128) Mac=AEAD
0xC0,0x30 - ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AESGCM(256) Mac=AEAD
0xCC,0xA8 - ECDHE-RSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH     Au=RSA  Enc=CHACHA20/POLY1305(256) Mac=AEAD
0xCC,0xA9 - ECDHE-ECDSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=CHACHA20/POLY1305(256) Mac=AEAD
0xCC,0xAA - DHE-RSA-CHACHA20-POLY1305 TLSv1.2 Kx=DH       Au=RSA  Enc=CHACHA20/POLY1305(256) Mac=AEAD
0xCC,0xAB - PSK-CHACHA20-POLY1305   TLSv1.2 Kx=PSK      Au=PSK  Enc=CHACHA20/POLY1305(256) Mac=AEAD
0xCC,0xAC - ECDHE-PSK-CHACHA20-POLY1305 TLSv1.2 Kx=ECDHEPSK Au=PSK  Enc=CHACHA20/POLY1305(256) Mac=AEAD
0xCC,0xAD - DHE-PSK-CHACHA20-POLY1305 TLSv1.2 Kx=DHEPSK   Au=PSK  Enc=CHACHA20/POLY1305(256) Mac=AEAD
0xCC,0xAE - RSA-PSK-CHACHA20-POLY1305 TLSv1.2 Kx=RSAPSK   Au=RSA  Enc=CHACHA20/POLY1305(256) Mac=AEAD

The following ciphers are common to the Synology and the Lorex DVR

(0x003c) RSA_WITH_AES_128_CBC_SHA256
(0x003d) RSA_WITH_AES_256_CBC_SHA256
(0x0067) DHE_RSA_WITH_AES_128_CBC_SHA256
(0x006b) DHE_RSA_WITH_AES_256_CBC_SHA256
(0x009c) RSA_WITH_AES_128_GCM_SHA256
(0x009d) RSA_WITH_AES_256_GCM_SHA384
(0x009e) DHE_RSA_WITH_AES_128_GCM_SHA256
(0x009f) DHE_RSA_WITH_AES_256_GCM_SHA384

Doing a packet capture when the DVR successfully sends a notification using mail.com SMTP server shows that the mail.com SSL connection uses cipher RSA_WITH_AES_256_GCM_SHA384 (0x009d). So why is it not used with Synology MailPlus Server?

I checked with openssl that a starttls connection could be established with this cipher for both my server and mail.com's, with the following commands

openssl s_client -tls1_2 -starttls smtp -crlf -connect smtp.mail.com:587 -ciphersuites 'TLS_RSA_WITH_AES_256_GCM_SHA384'
openssl s_client -tls1_2 -starttls smtp -crlf -connect smtp.mydomain.tld:587 -ciphersuites 'TLS_RSA_WITH_AES_256_GCM_SHA384'

I noticed that the output of connection to mail.com ends with "250 STARTTLS", while connection to my domain ends "250 CHUNKING". I have no idea what this could mean, if it's normal or not.

Synology MailPlus Postfix

So, my attention turned to the mail server. I tried in Synology's GUI to set the TLS/SSL profile level to "Old backward compatibility" (Control Panel->Security->Advanced), but no change in behaviour. Then I learned about postconf which spews 1,000+ values...

Trying to get cipher-related Postfix settings gave me this:

me@my_server:/volume1/@appstore/MailPlus-Server/sbin$ ./postconf | grep -i cipher
lmtp_tls_ciphers = medium
lmtp_tls_exclude_ciphers =
lmtp_tls_mandatory_ciphers = medium
lmtp_tls_mandatory_exclude_ciphers =
milter_helo_macros = {tls_version} {cipher} {cipher_bits} {cert_subject} {cert_issuer}
smtp_tls_ciphers = medium
smtp_tls_exclude_ciphers =
smtp_tls_mandatory_ciphers = medium
smtp_tls_mandatory_exclude_ciphers =
smtpd_tls_ciphers = low
smtpd_tls_exclude_ciphers =
smtpd_tls_mandatory_ciphers = low
smtpd_tls_mandatory_exclude_ciphers =
smtpd_tls_no_renegotiate_ciphers = yes
tls_export_cipherlist = aNULL:-aNULL:HIGH:MEDIUM:LOW:EXPORT:+RC4:@STRENGTH
tls_high_cipherlist = aNULL:-aNULL:HIGH:@STRENGTH
tls_low_cipherlist = 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:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA
tls_medium_cipherlist = aNULL:-aNULL:HIGH:MEDIUM:+RC4:@STRENGTH
tls_null_cipherlist = eNULL:!aNULL
tls_preempt_cipherlist = no
tls_session_ticket_cipher = aes-256-cbc
tlsproxy_tls_ciphers = $smtpd_tls_ciphers
tlsproxy_tls_exclude_ciphers = $smtpd_tls_exclude_ciphers
tlsproxy_tls_mandatory_ciphers = $smtpd_tls_mandatory_ciphers
tlsproxy_tls_mandatory_exclude_ciphers = $smtpd_tls_mandatory_exclude_ciphers

So I see that cipher 0x009d (AES256-GCM-SHA384) is in tls_low_cipherlist, and smtpd_tls_ciphers = low and smtpd_tls_mandatory_ciphers = low.

So, I'm at my wits' end, and figured I should ask to see if anyone could help me before I start digging to learn how postfix works, or maybe tell me I'm on the wrong track.

To recap, why is the TLS connection not established? Why is there no shared cipher?

my environment:

Synology DSM 7.1.1
MailPlus Server 3.1.6-11332 (Postfix 3.6.2)

Postfix reload messages:

postfix[PID]: Postfix is running with backwards-compatible default settings
postfix[PID]: See http://www.postfix.org/COMPATIBILITY_README.html for details
postfix[PID]: To disable backwards compatibility use "postconf compatibility_level=3.6" and "postfix reload"
postfix/postfix-script[PID]: refreshing the Postfix mail system
postfix/master[PID]: reload -- version 3.6.2, configuration /var/packages/MailPlus-Server/target/etc

2025-03-16 Additional info & tests following grawity's comment

NAS Server Certificate is ECDSA.

Testing openssl connection with the following DHE ciphers seems to work, end of openssl output is 250 STARTTLS (DVR does not have ECDHE ciphers)

(0x0067) TLS_DHE_RSA_WITH_AES_128_CBC_SHA256  
(0x006b) TLS_DHE_RSA_WITH_AES_256_CBC_SHA256  
(0x009e) TLS_DHE_RSA_WITH_AES_128_GCM_SHA256  
(0x009f) TLS_DHE_RSA_WITH_AES_256_GCM_SHA384

However, none of these are in Postfix' tls_low_cipherlist.

How can we add at least one of those ciphers to Synology MailPlus' Postfix configuration?

score 2 · Answer 1 · answered Mar 16 '25 at 20:09

I noticed that the output of connection to mail.com ends with "250 STARTTLS", while connection to my domain ends "250 CHUNKING". I have no idea what this could mean, if it's normal or not.

openssl s_client automatically issues a second EHLO after the TLS handshake, and only shows the last line received. (Use gnutls-cli --starttls to see the entire thing.) The order of EHLO capability lines is irrelevant, and has no effect on the TLS connection.

Doing a packet capture when the DVR successfully sends a notification using mail.com SMTP server shows that the mail.com SSL connection uses cipher RSA_WITH_AES_256_GCM_SHA384 (0x009d). So why is it not used with Synology MailPlus Server?

The (obsolete) TLS_RSA_* ciphersuites require an RSA certificate as they use the certificate's keypair for encrypting the session key, so they can't work if you have an ECDSA certificate.

or am I better off just having both self-signed and Lets encrypt certificates, and use the self-signed for mail server and let's encrypt for everything else

Your ciphersuite selection should not depend on the certificate. All of the certificate-dependent ciphersuites (TLS_RSA_ and TLS_DH_) have long been considered obsolete and shouldn't be used unless you're trying to interoperate with Windows XP or something of that vintage. TLSv1.3 only keeps the ECDHE (ephemeral ECDH) ciphersuites; ephemeral FFDH (TLS_DHE_*) is also deprecated but mostly Okay to use.

How can we add at least one of those ciphers to Synology MailPlus' Postfix configuration?

Set the cipher list to DEFAULT:!kRSA. With modern OpenSSL it really does give a reasonable default (though DEFAULT:!kRSA:!kDHE would be preferred, but in your case you do want 'DHE').

Additionally, for DHE, you need to manually provide a "DH parameters" file through the smtpd_tls_dh512_param_file option. Don't actually make it 512 bits though – these days it's 1536 bits minimum, but the default should be at least a 2048-bit group, so create the file using openssl dhparam 2048. (ECDHE uses built-in groups.)

score 1 · Accepted Answer · answered Mar 17 '25 at 05:22

The comment and answer by @grawity shows that a TLS connection cannot be established between DVR and NAS when the NAS certificate uses an ECDSA signature (shown as ECC in Synology), which is the default certificate type from let's encrypt.

Solution I found was to request another certificate from let's encrypt specifically for SMTP operations (domain name smtp.mydomain.tld) using RSA encryption. The acme.sh --issue command should include --keylength 2048 for this. @dave_thompson also mentioned using an RSA certificate and that the argument for certbot is --key-type rsa