Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

dh key too small

305 views
Skip to first unread message

None

unread,
Oct 31, 2022, 10:27:46 AM10/31/22
to
I have recently upgraded to centos9stream and removed the

LOCAL_CONFIG
O CipherList=HIGH
O ServerSSLOptions=+SSL_OP_NO_SSLv2 +SSL_OP_NO_SSLv3
+SSL_OP_CIPHER_SERVER_PREFERENCE

Assuming that the 8.16 has a better default configuration, yet I am
seeing still a few "dh key too small" errors in the logs.

The key has been generated with

openssl dhparam -out dhparams.pem 2048

Should I still force ciphers, or is there something wrong with a key of
2048?

Claus Aßmann

unread,
Oct 31, 2022, 12:26:28 PM10/31/22
to
None wrote:

> Assuming that the 8.16 has a better default configuration, yet I am
> seeing still a few "dh key too small" errors in the logs.

Please post a log entry: is it your system or the other side
that's complaining?

AFAIR some Linux distributions use ... "uncommon" settings
in the OpenSSL compilation -- check the archive for other
postings about this problem.

--
Note: please read the netiquette before posting. I will almost never
reply to top-postings which include a full copy of the previous
article(s) at the end because it's annoying, shows that the poster
is too lazy to trim his article, and it's wasting the time of all readers.

None

unread,
Oct 31, 2022, 3:44:39 PM10/31/22
to

>> Assuming that the 8.16 has a better default configuration, yet I am
>> seeing still a few "dh key too small" errors in the logs.
>
> Please post a log entry: is it your system or the other side
> that's complaining?

It is theirs, this is an outgoing, mostly this trendmicro, but also some
facebook smtpin

sendmail[95017]: STARTTLS=client, error: connect failed=-1, reason=dh
key too small, SSL_error=1, errno=0, retry=-1
sendmail[95017]: ruleset=tls_server, arg1=SOFTWARE,
relay=in.hes.trendmicro.eu, reject=403 4.7.0 TLS handshake failed.
sendmail[95017]: 29RFGr81082301: to=<xxxxxxx>, delay=2+11:17:23,
xdelay=00:00:00, mailer=esmtp, pri=5613815, relay=in.hes.trendmicro.eu.
[52.58.62.239], dsn=4.0.0, stat=Deferred: 403 4.7.0 TLS handshake failed.


> AFAIR some Linux distributions use ... "uncommon" settings
> in the OpenSSL compilation -- check the archive for other
> postings about this problem.
>

I did not expect that in 2022 there still can't be some cipher
successfully negotiated.

Claus Aßmann

unread,
Nov 1, 2022, 2:32:06 AM11/1/22
to
None wrote:
> I have recently upgraded to centos9stream and removed the

Which sendmail version and which openssl version?
sendmail -bt -d0.14 </dev/null

> Should I still force ciphers, or is there something wrong with a key of
> 2048?

No, but it depends on the versions of sendmail, the library, and
compile time options - hence the request for more info.

Moreover, check whether your cf file actually references
the generated data.

None

unread,
Nov 1, 2022, 7:19:09 AM11/1/22
to

> Which sendmail version and which openssl version?
> sendmail -bt -d0.14 </dev/null
>


> [@~]# sendmail -bt -d0.14 -bt < /dev/null
Version 8.16.1
Compiled with: DANE DNSMAP HES_GETMAILHOST IPV6_FULL LDAPMAP
LDAP_NETWORK_TIMEOUT LOG MAP_REGEX MATCHGECOS MILTER MIME7TO8
MIME8TO7 NAMED_BIND NETINET NETINET6 NETUNIX NEWDB=5.3 CDB=1
PIPELINING SASLv2 SCANF SOCKETMAP STARTTLS TLS_EC
TLS_VRFY_PER_CTX USERDB USE_LDAP_INIT
OS Defines: ADDRCONFIG_IS_BROKEN HASFCHOWN HASFCHMOD
HASGETDTABLESIZE HAS_GETHOSTBYNAME2 HASINITGROUPS HASLSTAT
HASNICE HASRANDOM HASRRESVPORT HASSETREGID HASSETREUID
HASSETRLIMIT HASSETSID HASSETVBUF HASURANDOMDEV HASSTRERROR
HASUNAME HASUNSETENV HASWAITPID IDENTPROTO NEEDSGETIPNODE
REQUIRES_DIR_FSYNC SFS_VFS USE_DOUBLE_FORK USE_SIGLONGJMP
Kernel symbols: /boot/vmlinux
Conf file: /etc/mail/submit.cf (default for MSP)
Conf file: /etc/mail/sendmail.cf (default for MTA)
Pid file: /var/run/sendmail.pid (default)
libsm Defines: SM_CONF_LDAP_INITIALIZE SM_CONF_LDAP_MEMFREE
SM_CONF_LONGLONG SM_CONF_MEMCHR SM_CONF_MSG SM_CONF_SEM
SM_CONF_SIGSETJMP SM_CONF_SHM SM_CONF_SSIZE_T SM_CONF_STDBOOL_H
SM_CONF_STDDEF_H SM_CONF_SYS_CDEFS_H SM_CONF_UID_GID
DO_NOT_USE_STRCPY SM_HEAP_CHECK SM_OS=sm_os_linux SM_VA_STD
FFR Defines: _FFR_MILTER_CHECK_REJECTIONS_TOO _FFR_QOS
_FFR_TLS_USE_CERTIFICATE_CHAIN_FILE
OpenSSL: compiled 0x30000000
OpenSSL: linked 0x30000010


Conf file: /etc/mail/sendmail.cf (selected)
Pid file: /var/run/sendmail.pid (selected)




>> Should I still force ciphers, or is there something wrong with a key of
>> 2048?
>
> No, but it depends on the versions of sendmail, the library, and
> compile time options - hence the request for more info.
>
> Moreover, check whether your cf file actually references
> the generated data.
>

Yes I have even the complete path in sendmail.mc
define(`confDH_PARAMETERS',`/etc/mail/dhparams.pem')dnl

Claus Aßmann

unread,
Nov 7, 2022, 11:13:49 AM11/7/22
to
None wrote:

> sendmail[95017]: STARTTLS=client, error: connect failed=-1, reason=dh
> key too small, SSL_error=1, errno=0, retry=-1

Do you know how to use openssl s_client to test this?

H=in.hes.trendmicro.eu
openssl s_client -connect $H -state -debug -crlf -starttls smtp

My guess is this might trigger the same error
which points to the openssl version/setup on your host,
it rejects the dh key offered by the server.

Please post the result(s)!

None

unread,
Nov 8, 2022, 5:20:44 PM11/8/22
to

>> sendmail[95017]: STARTTLS=client, error: connect failed=-1, reason=dh
>> key too small, SSL_error=1, errno=0, retry=-1
>
> Do you know how to use openssl s_client to test this?
>
> H=in.hes.trendmicro.eu
> openssl s_client -connect $H -state -debug -crlf -starttls smtp


[@]# openssl s_client -connect in.hes.trendmicro.eu -state -debug -crlf
-starttls smtp


809BD080237F0000:error:8000006E:system library:BIO_connect:Connection
timed out:crypto/bio/bio_sock2.c:125:calling connect()
809BD080237F0000:error:10000067:BIO routines:BIO_connect:connect
error:crypto/bio/bio_sock2.c:127:
809BD080237F0000:error:8000006E:system library:BIO_connect:Connection
timed out:crypto/bio/bio_sock2.c:125:calling connect()
809BD080237F0000:error:10000067:BIO routines:BIO_connect:connect
error:crypto/bio/bio_sock2.c:127:



Claus Aßmann

unread,
Nov 8, 2022, 11:34:27 PM11/8/22
to
Sorry, you need to add the port:
openssl s_client -connect in.hes.trendmicro.eu:25 -state -debug -crlf -starttls smtp
see also the man page for info.

None

unread,
Nov 9, 2022, 7:35:35 AM11/9/22
to

> openssl s_client -connect in.hes.trendmicro.eu:25 -state -debug -crlf -starttls smtp
> see also the man page for info.
>

This is the output, but I am not really sure how this is comparable as
the dhparams.pem file is only in the /etc/mail/ folder and sendmail is
configured for this.


01c0 - e9 d4 fc df 15 09 ab 9d-0c 82 b6 f0 1a cd 99 3f ...............?
01d0 - c3 e3 c6 bd 0b 1d 5d 2f-f3 4c e2 44 40 1d 58 54 ......]/.L.D@.XT
01e0 - 7b f5 cd 31 aa 93 5f 09-31 ac d1 b3 09 4e e0 15 {..1.._.1....N..
01f0 - 83 a9 5c b2 c9 07 98 0e-a4 0a 6f 9c c7 45 63 05 ..\.......o..Ec.
0200 - d3 7c 07 70 fd 83 70 60-6b 28 d7 b6 03 05 b4 .|.p..p`k(.....
write to 0x560e17932310 [0x560e17a1b480] (7 bytes => 7 (0x7))
0000 - 15 03 03 00 02 02 28 ......(
---
Certificate chain
0 s:C = US, ST = California, L = Cupertino, OU = BU, O = TREND MICRO
INCORPORATED, CN = *.hes.trendmicro.eu
i:C = BE, O = GlobalSign nv-sa, CN = GlobalSign RSA OV SSL CA 2018
a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
v:NotBefore: Jan 6 12:59:48 2022 GMT; NotAfter: Feb 7 12:59:48
2023 GMT
1 s:C = BE, O = GlobalSign nv-sa, CN = GlobalSign RSA OV SSL CA 2018
i:OU = GlobalSign Root CA - R3, O = GlobalSign, CN = GlobalSign
a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
v:NotBefore: Nov 21 00:00:00 2018 GMT; NotAfter: Nov 21 00:00:00
2028 GMT
2 s:OU = GlobalSign Root CA - R3, O = GlobalSign, CN = GlobalSign
i:OU = GlobalSign Root CA - R3, O = GlobalSign, CN = GlobalSign
a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
v:NotBefore: Mar 18 10:00:00 2009 GMT; NotAfter: Mar 18 10:00:00
2029 GMT
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIHcDCCBligAwIBAgIMbm7K6bCG3F4C+uZbMA0GCSqGSIb3DQEBCwUAMFAxCzAJ
BgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSYwJAYDVQQDEx1H
bG9iYWxTaWduIFJTQSBPViBTU0wgQ0EgMjAxODAeFw0yMjAxMDYxMjU5NDhaFw0y
MzAyMDcxMjU5NDhaMIGEMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5p
YTESMBAGA1UEBxMJQ3VwZXJ0aW5vMQswCQYDVQQLEwJCVTEhMB8GA1UEChMYVFJF



RoLweUxaHa8hEDQS1rJJn1hIhh2FTuiXoVLSiZ+GBlSqJo5WyQw9S5X9iQ1n/zN
WBhLVb91a20XHBcn3eIDxG4b2ps5t6IURVrX1fN6tX+lL74RttpC4G/SahpIaPgD
dCdDIzhmaxGRMz8cxtWTxhmeJnlqCABVbiqOk3wvDZ5IX698pGrPjpWINeRbTOFu
JsFRbZp4ISOf8CZpykGXXexXKGw5O2Q6Ue3k2CbV0H/7x6hGfhuiC+E8OINAaKJ+
tdlr8OIYpGk4RsrTbwD80DZEATMf2agb4CVfL1rwPAfhFSl8
-----END CERTIFICATE-----
subject=C = US, ST = California, L = Cupertino, OU = BU, O = TREND MICRO
INCORPORATED, CN = *.hes.trendmicro.eu
issuer=C = BE, O = GlobalSign nv-sa, CN = GlobalSign RSA OV SSL CA 2018
---
No client certificate CA names sent
---
SSL handshake has read 4727 bytes and written 364 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : 0000
Session-ID:
Session-ID-ctx:
Master-Key:
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1667996876
Timeout : 7200 (sec)
Verify return code: 0 (ok)
Extended master secret: no
---
read from 0x560e17932310 [0x560e17891260] (8192 bytes => 9 (0x9))
0000 - 16 03 03 00 04 0e 00 00-00 .........
read from 0x560e17932310 [0x560e17891260] (8192 bytes => 0)


Claus Aßmann

unread,
Nov 10, 2022, 5:16:33 AM11/10/22
to
None wrote:

> This is the output, but I am not really sure how this is comparable as
> the dhparams.pem file is only in the /etc/mail/ folder and sendmail is
> configured for this.

Because my guess is that it's a problem with the server key --
I get this from in.hes.trendmicro.eu:

Server Temp Key: DH, 1024 bits

which could be considered "too small" by some OpenSSL versions.

So the easiest is to keep the workarounds :-(

None

unread,
Aug 28, 2023, 6:14:32 AM8/28/23
to

>
>> This is the output, but I am not really sure how this is comparable as
>> the dhparams.pem file is only in the /etc/mail/ folder and sendmail is
>> configured for this.
>
> Because my guess is that it's a problem with the server key --
> I get this from in.hes.trendmicro.eu:
>
> Server Temp Key: DH, 1024 bits
>
> which could be considered "too small" by some OpenSSL versions.
>

How do you get this dh key? If I do this on my server I get this

[]# openssl s_client -connect xxxxxxxxxx:25 -starttls smtp | grep -i 'key'
..
verify return:1
a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA384
Server Temp Key: ECDH, prime256v1, 256 bits
Server public key is 2048 bit
250 HELP

and on

openssl s_client -connect in.hes.trendmicro.eu:25 -starttls smtp | grep
-i 'key'

verify return:1
807B24935D7F0000:error:0A00018A:SSL routines:tls_process_ske_dhe:dh key
too small:ssl/statem/statem_clnt.c:2092:
a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
Server public key is 2048 bit
Master-Key:

Claus Aßmann

unread,
Aug 28, 2023, 6:43:50 AM8/28/23
to
None wrote:

> > Server Temp Key: DH, 1024 bits

> How do you get this dh key? If I do this on my server I get this

> []# openssl s_client -connect xxxxxxxxxx:25 -starttls smtp | grep -i 'key'

Maybe you are using a different openssl version (or .cnf file)
or maybe the server configuration has been changed?

Does the original problem still exist?

None

unread,
Aug 28, 2023, 7:09:52 AM8/28/23
to

>
>>> Server Temp Key: DH, 1024 bits
>
>> How do you get this dh key? If I do this on my server I get this
>
>> []# openssl s_client -connect xxxxxxxxxx:25 -starttls smtp | grep -i
'key'
>
> Maybe you are using a different openssl version (or .cnf file)
> or maybe the server configuration has been changed?

Indeed! old centos6 gives me the "Server Temp Key: DH, 1024 bits", while
new centos9 just presents me only with the error.

> Does the original problem still exist?
>

yes currently running with try_tls no
0 new messages