Unexpected TCP/IP error func: 001Dh error Notes: 1C5B, NTI: 1000h, Stack: 00000000h


**Domino/Notes Version:Domino 14.0 FP4
Add-on Product (if appropriate, e.g. Verse / Traveler / Nomad / Domino REST API):
Its Version:
**Operating System: linux Alma 9.6
**Client (Notes, Nomad Web, Nomad Mobile, Android/iOS, browser version): Notes


Problem/Query:

Issue sending to messagelabs

13/06/2025 12:53:59 Router: Transferred 1 messages to sxxxxxxxxxx (host cluster8a.eu.messagelabs.COM) via SMTP
13/06/2025 12:53:59 Unexpected TCP/IP error func: 001Dh error Notes: 1C5B, NTI: 1000h, Stack: 00000000h
13/06/2025 12:53:59 [009597:000016-00007F823826C640] SMTPClient: SSL handshake error: 1C5Bh
13/06/2025 12:53:59 …
13/06/2025 12:53:59 Router: No messages transferred to MESSAGELABS.COM (host cluster6a.eu.MESSAGELABS.COM) via SMTP: Unexpected TCP error. See the Notes log file on this system for error code.

We recently upgraded to 14FP4 and started to use the certstore.nsf to generate letsencrypt certificates. Prior to that we used MidPoints LetsEncrypt without issue.

This only appears to be an issue with messagelabs.com or domains that use their mail platform.

The certificate using a tls checker is good.

[000.235] We can use this server
[000.235] TLS is an option on this server
[000.235] ‑‑> STARTTLS
[000.309] <‑‑ 220 Ready to start TLS
[000.309] STARTTLS command works on this server
[000.310] SSL_ocsp_mode = SSL_OCSP_FULL_CHAIN
[000.688] Connection converted to SSL
SSLVersion in use: TLSv1_2
Cipher in use: ECDHE-ECDSA-AES256-GCM-SHA384
Perfect Forward Secrecy: yes
Session Algorithm in use: Curve X25519 DHE(253 bits)
Certificate #1 of 3 (sent by MX):
Cert VALIDATED: ok
Cert Hostname VERIFIED (xxxxxxxxxxx = xxxxxxxxxx | DNS:xxxxxxxxxx | DNS:xxxxxxx)
Not Valid Before: Apr 26 09:20:16 2025 GMT
Not Valid After: Jul 25 09:20:15 2025 GMT
Seconds Until Expired: 3618030
subject: /CN=xxxxxxxxxxxx
issuer: /C=US/O=Let’s Encrypt/CN=E5
Certificate #2 of 3 (sent by MX):
Cert VALIDATED: ok
Not Valid Before: Mar 13 00:00:00 2024 GMT
Not Valid After: Mar 12 23:59:59 2027 GMT
Seconds Until Expired: 55078814
subject: /C=US/O=Let’s Encrypt/CN=E5
issuer: /C=US/O=Internet Security Research Group/CN=ISRG Root X1
Certificate #3 of 3 (sent by MX, also in CA Root Store):
Cert VALIDATED: ok
Not Valid Before: Jun 4 11:04:38 2015 GMT
Not Valid After: Jun 4 11:04:38 2035 GMT
Seconds Until Expired: 314750693
subject: /C=US/O=Internet Security Research Group/CN=ISRG Root X1
issuer: /C=US/O=Internet Security Research Group/CN=ISRG Root X1
[000.726] > EHLO xxxxxxxxxxxxxxxxxxx
[000.802] <
250-xxxxxxxxxxxxHello xxxxxxxxxx ([142.93.73.156]), pleased to meet you
250-HELP
250-SIZE
250 PIPELINING
[000.802] TLS successfully started on this server

Hello.
It may be that the receiving server does not support the encryption used by the sending server.
For example, debugging with the following parameters may provide more detailed information.

DEBUG_SSL_HANDSHAKE=1

Regards,
Shigemitsu

There’s a possibility of different protocol version being used for handshake activity.

Was this working fine before or is it a new setup?

What are the recent changes?

Does the issue occur always or is it intermittent?

You may raise a case with HCL Support to troubleshoot this further.

Thanks and Regards
Niraj V Jani