Hello,
we are having issues when we try to configure email sending with a postfix email relay. This is the detailed report created with Devolutions Server 202.1.16.0:
================================================================================
BUG REPORT — DEVOLUTIONS SERVER FREE 2026.1.16.0
SMTP / TLS — SSL ALERT 42 (bad_certificate) AFTER SUCCESSFUL TLS HANDSHAKE
================================================================================
Date: 2026-05-21
Reported by: Alessio Gennari — Senior Systems Engineer, Trigano Servizi S.r.l.
Product: Devolutions Server Free 2026.1.16.0
Component: Administration > Server Settings > Email (SMTP client)
Severity: Critical — email functionality completely non-functional
--------------------------------------------------------------------------------
1. ENVIRONMENT
--------------------------------------------------------------------------------
Devolutions Server host:
Hostname : TGRP-SRVDVLS.domain.local
IP address : X.X.200.57
OS : Windows Server 2019
Domain : domain.local (Active Directory domain-joined)
SMTP relay host:
Hostname : testsmtp.domain.local
IP address : X.X.201.162
OS : Debian GNU/Linux 12
MTA : Postfix 3.7.x
Port : 587 (submission / STARTTLS)
Devolutions SMTP configuration (Administration > Server Settings > Email):
Host : testsmtp.domain.local
Port : 587
Username : devolution
Password : (configured)
Connection security: Automatic based on port number
Send email as : devolution@trigano.it
--------------------------------------------------------------------------------
2. CERTIFICATE DETAILS
--------------------------------------------------------------------------------
The SMTP relay presents an X.509 certificate issued by an internal Active
Directory Certificate Services Enterprise CA (caravansinternational-CA).
Subject CN : testsmtp.domain.local
Issuer : caravansinternational-CA
SANs : DNS:testsmtp.domain.local, DNS:testsmtp,
IP:X.X.201.162
Key usage : Digital Signature, Non Repudiation, Key Encipherment,
Data Encipherment
EKU : TLS Web Server Authentication (1.3.6.1.5.5.7.3.1)
Valid from : 2026-05-21
Valid to : 2036-05-18
Key size : RSA 4096-bit
The issuing CA certificate is automatically deployed to all domain-joined
machines via Group Policy (Trusted Root Certification Authorities store).
TGRP-SRVDVLS is domain-joined and has the CA in its trusted root store.
--------------------------------------------------------------------------------
3. OBSERVED BEHAVIOR
--------------------------------------------------------------------------------
When Devolutions Server attempts to send email via the configured SMTP relay,
the connection always fails with:
"Error sending email — Unexpected exception. Please see server logs for details."
The Postfix server logs show the following sequence on every attempt:
1. TCP connection established from X.X.200.57:ephemeral to X.X.201.162:587
2. EHLO command sent by Devolutions — acknowledged by Postfix
3. STARTTLS command sent by Devolutions — acknowledged by Postfix ("220 Ready")
4. Full TLS 1.2 handshake completes successfully
(Postfix logs: "Anonymous TLS connection established ... TLSv1.2 with
cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)")
5. Immediately after the handshake, Devolutions sends TLS alert 42
(fatal: bad_certificate) WITHOUT reading any post-STARTTLS SMTP data
6. Connection is dropped
Postfix log excerpt (representative, from a clean full handshake):
postfix/submission/smtpd[12109]: connect from TGRP-SRVDVLS...[X.X.200.57]
postfix/submission/smtpd[12109]: SSL_accept:SSLv3/TLS write certificate
postfix/submission/smtpd[12109]: SSL_accept:SSLv3/TLS write key exchange
postfix/submission/smtpd[12109]: SSL_accept:SSLv3/TLS write server done
postfix/submission/smtpd[12109]: SSL_accept:SSLv3/TLS read client key exchange
postfix/submission/smtpd[12109]: SSL_accept:SSLv3/TLS read change cipher spec
postfix/submission/smtpd[12109]: SSL_accept:SSLv3/TLS read finished
postfix/submission/smtpd[12109]: Issuing session ticket, key expiration: ...
postfix/submission/smtpd[12109]: SSL_accept:SSLv3/TLS write finished
postfix/submission/smtpd[12109]: Anonymous TLS connection established from
tgrp-srvdvls.domain.local[X.X.200.57]: TLSv1.2 with cipher
ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
postfix/submission/smtpd[12109]: SSL3 alert read:fatal:bad certificate
postfix/submission/smtpd[12109]: warning: TLS library problem:
error:0A000412:SSL routines::sslv3 alert bad certificate:
../ssl/record/rec_layer_s3.c:1601:SSL alert number 42:
postfix/submission/smtpd[12109]: lost connection after STARTTLS from
TGRP-SRVDVLS.domain.local[X.X.200.57]
postfix/submission/smtpd[12109]: disconnect from TGRP-SRVDVLS...[X.X.200.57]
ehlo=1 starttls=1 commands=2
Note: "commands=2" confirms only EHLO and STARTTLS were sent — Devolutions
aborts before sending any SMTP commands after TLS is established.
--------------------------------------------------------------------------------
4. PROOF THAT THE ISSUE IS NOT A CERTIFICATE TRUST PROBLEM
--------------------------------------------------------------------------------
A PowerShell SslStream test was executed directly on TGRP-SRVDVLS to verify
whether Windows SChannel trusts the server certificate. The test manually
performed the SMTP STARTTLS upgrade and authenticated via SslStream with the
same hostname Devolutions uses.
PowerShell script executed on TGRP-SRVDVLS:
$tcp = New-Object System.Net.Sockets.TcpClient("testsmtp.domain.local", 587)
$stream = $tcp.GetStream()
# [EHLO / STARTTLS exchange omitted for brevity]
$ssl = New-Object System.Net.Security.SslStream($stream, $false, { ... return $true })
$ssl.AuthenticateAsClient("testsmtp.domain.local")
Result:
Certificate errors : None
Cert subject : CN=testsmtp.domain.local, ...
TLS OK : Tls12 / Aes256
Windows SChannel successfully validates the certificate with zero errors.
The CA is trusted, the hostname matches the SAN, and TLS 1.2 negotiates
correctly. This conclusively rules out any certificate trust issue on the
Windows side.
--------------------------------------------------------------------------------
5. WHAT HAS BEEN RULED OUT
--------------------------------------------------------------------------------
The following have been investigated and eliminated as root causes:
- Certificate not trusted by Windows : RULED OUT (see Section 4)
- Certificate chain incomplete : RULED OUT (chain verified OK
by both openssl and SChannel)
- Hostname mismatch (SAN) : RULED OUT (SAN contains the
exact hostname Devolutions uses)
- TLS version mismatch : RULED OUT (TLS 1.2 negotiated
successfully by both sides)
- TLS downgrade sentinel (DOWNGRD) : RULED OUT (TLS 1.3 disabled on
submission port; no sentinel
present in server hello)
- Postfix requesting client certificate : RULED OUT (no smtpd_tls_req_ccert
or smtpd_tls_ask_ccert configured;
Postfix logs show "Anonymous TLS")
- SASL user missing : RULED OUT (devolution user added
to sasldb after investigation;
failure unchanged)
- IP not in mynetworks : RULED OUT (X.X.200.57 added;
failure unchanged)
- AUTH advertised before STARTTLS : RULED OUT (smtpd_sasl_auth_enable
disabled globally, enabled only
in submission override; failure
unchanged)
- Postfix misconfiguration : RULED OUT (identical Postfix setup
works correctly with other SMTP
clients on the same network)
--------------------------------------------------------------------------------
6. ROOT CAUSE ASSESSMENT
--------------------------------------------------------------------------------
The evidence indicates a bug in Devolutions Server's SMTP client implementation.
After a fully successful TLS 1.2 handshake (confirmed by both Postfix logs and
independent SChannel verification), Devolutions sends TLS alert 42
(bad_certificate) to the server without reading any post-STARTTLS SMTP response.
Alert 42 (bad_certificate) in this context is being generated by Devolutions'
application-layer SMTP/TLS code, not by Windows SChannel — SChannel itself
reports no errors when performing the identical handshake independently.
The pattern suggests that Devolutions' SMTP client performs an additional
certificate validation step after the TLS handshake (possibly using a different
certificate store, trust policy, or validation API than SslStream) and aborts
when that secondary check fails, before the application has read any data.
Possible areas to investigate in the Devolutions codebase:
- Custom certificate validation callback rejecting the cert despite SChannel
accepting it
- Use of a different trust store or certificate pinning mechanism
- An exception thrown during post-handshake processing that causes the
connection to be closed with alert 42 rather than a clean error
- Difference in behavior between .NET SslStream and the SMTP client library
Devolutions uses internally (e.g. MailKit, SmtpClient, or custom)
--------------------------------------------------------------------------------
7. SUGGESTED DIAGNOSTIC STEPS FOR DEVOLUTIONS TEAM
--------------------------------------------------------------------------------
1. Enable verbose SMTP/TLS logging in Devolutions Server and capture the
full exception stack trace at the point where alert 42 is sent.
2. Identify which certificate validation API is used in the SMTP client
(e.g. RemoteCertificateValidationCallback, X509Chain.Build, etc.) and
compare its behavior against SslStream with the same certificate.
3. Test against an SMTP relay using a publicly trusted certificate (e.g.
Let's Encrypt) to determine if the issue is specific to internal/private
CA certificates.
4. Test with Connection Security set to "No encryption" to confirm the
SMTP client itself functions correctly when TLS is not involved.
5. Test with Connection Security set to "Use SSL or TLS immediately (SMTPS)"
on port 465 to determine if implicit TLS (no STARTTLS negotiation) works
where STARTTLS does not.
--------------------------------------------------------------------------------
8. CONTACT
--------------------------------------------------------------------------------
Reported by : Alessio Gennari
================================================================================
END OF REPORT
================================================================================
Anyway there is the same error also with version 2026.2.4.0 just installed. Can you please help us?
Very kind regards.
Alessio
Special Q&A