Your message dated Sun, 03 May 2026 16:32:06 +0000
with message-id <[email protected]>
and subject line Bug#1134984: fixed in exim4 4.98.2-1+deb13u1
has caused the Debian Bug report #1134984,
regarding GNUTLS certificate validation incompatible with certificates lacking
a commonName attribute
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
1134984: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1134984
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Source: exim4
Version: 4.96-15+
Severity: normal
Forwarded: https://code.exim.org/exim/exim/issues/3215
This is a tracking bug, we want to fix this for stable and perhaps for
oldstable, too
Excerot from the mesages on exim-dev follows
https://lists.exim.org/lurker/message/20260413.184322.ecbabb9e.en.html
----- Forwarded message from adsbarratt via Exim-dev <[email protected]>
-----
We discovered that TLS connections to some hosts were failing.
After some investigation, the common factor appears to be that the
certificate provided by the destination server is lacking a commonName
attribute. This causes verify_certificate() to return e.g.:
DANE attempt failed; TLS connection to [HOST]: (certificate verification
failed): certificate not supplied
Such certificates may be generated by e.g. the use of LetsEncrypt's
"tlsserver" profile - https://letsencrypt.org/docs/profiles/#tlsserver
The CAB Forum now recommends not including commonName, as per
https://github.com/cabforum/servercert/blob/main/docs/BR.md#71272-domain-validated
[...]
16:02:59 702757 gethostbyname2 looked up these IP addresses:
16:02:59 702757 name=pf.adam-barratt.org.uk address=2a03:9800:10:246::2
16:02:59 702757 name=pf.adam-barratt.org.uk address=188.246.206.241
16:02:59 702757 2a03:9800:10:246::2 in tls_verify_hosts? yes (matched
"pf.adam-barratt.org.uk")
16:02:59 702757 2a03:9800:10:246::2 in tls_verify_cert_hostnames? yes (matched
"*")
16:02:59 702757 TLS: server cert verification includes hostname:
"pf.adam-barratt.org.uk"
16:02:59 702757 TLS: server certificate verification required
16:02:59 702757 TLS: will request OCSP stapling
16:02:59 702757 2a03:9800:10:246::2 in tls_resumption_hosts? no (option unset)
16:02:59 702757 about to gnutls_handshake
16:02:59 702757
(TLS1.3)-(ECDHE-SECP256R1)-(ECDSA-SECP384R1-SHA384)-(AES-256-GCM)
16:02:59 702757 To get keying info for TLS1.3 is hard:
16:02:59 702757 Set environment variable SSLKEYLOGFILE to a filename relative
to the spool directory,
16:02:59 702757 and make sure it is writable by the Exim runtime user.
16:02:59 702757 Add SSLKEYLOGFILE to keep_environment in the exim config.
16:02:59 702757 Start Exim as root.
16:02:59 702757 If using sudo, add SSLKEYLOGFILE to env_keep in /etc/sudoers
16:02:59 702757 (works for TLS1.2 also, and saves cut-paste into file).
16:02:59 702757 Trying to use add_environment for this will not work
16:02:59 702757 TLS: checking peer certificate
16:02:59 702757 TLS: peer cert problem: getting size for cert DN failed: The
requested data were not available.
16:02:59 702757 TLS certificate verification failed (certificate not supplied):
peerdn="<unset>"
16:02:59 702757 TLS session fail: (certificate verification failed):
certificate not supplied
16:02:59 702757 SMTP(close)>>
16:02:59 702757 cmdlog: '220:EHLO:250-:STARTTLS:220'
16:02:59 702757 set_process_info: 702757 delivering 1wCfI2-002woi-2Z: just
tried pf.adam-barratt.org.uk [2a03:9800:10:246::2] for
[email protected]: result DEFER
16:02:59 702757 added retry item for
T:pf.adam-barratt.org.uk:2a03:9800:10:246::2: errno=-37 more_errno=0,A flags=2
--- End Message ---
--- Begin Message ---
Source: exim4
Source-Version: 4.98.2-1+deb13u1
Done: Andreas Metzler <[email protected]>
We believe that the bug you reported is fixed in the latest version of
exim4, which is due to be installed in the Debian FTP archive.
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to [email protected],
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Andreas Metzler <[email protected]> (supplier of updated exim4 package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing [email protected])
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Format: 1.8
Date: Sat, 02 May 2026 11:31:20 +0200
Source: exim4
Architecture: source
Version: 4.98.2-1+deb13u1
Distribution: trixie
Urgency: medium
Maintainer: Exim4 Maintainers <[email protected]>
Changed-By: Andreas Metzler <[email protected]>
Closes: 1134984
Changes:
exim4 (4.98.2-1+deb13u1) trixie; urgency=medium
.
* Fix GnuTLS hostname verify of a server certificate with a zero-length
Subject. Patch from upstream GIT master (Closes: #1134984)
* Pull CVE-fixes from 4.99.2
+CVE-2026-40684 Possible crash with malicious DNS data when using musl
libc On systems using musl libc (not glibc) due to an oddity in octal
printing it is possible to crash the connection instance when malformed
DNS data is present in PTR records.
+CVE-2026-40685 Possible OOB read/write on corrupt JSON in header
configurations using json operators on invalid externally-provided input
could trigger heap corruption.
+CVE-2026-40686 Possible OOB read with large UTF8 trailing characters
configurations using utf8 operators on malformed utf8 in headers could
trigger OOB reads and might trigger some data leak if error messages are
required for subsequent emails in the current connection and similar
malformed headers are present.
+CVE-2026-40687 Possible OOB read/write with SPA authenticator in
configurations using the SPA authentication driver to a
hostile/compromised external SPA/NTLM connection it is possible to
trigger an OOB read/write and crash the connection instance or possibly
leak heap data to the instance.
Checksums-Sha1:
7c7ed3e5a10ef5de08f0dfff8e5972a79caff163 2929 exim4_4.98.2-1+deb13u1.dsc
67aec85babe34388344c3725a84bf2e08ebdd63a 489460
exim4_4.98.2-1+deb13u1.debian.tar.xz
Checksums-Sha256:
dfc63bb64d022e9f0282033f9523ef84b7e30e4f1adaed9b774b2ee041a50d0b 2929
exim4_4.98.2-1+deb13u1.dsc
d27da3d7fa1dd1b0c57f96b045c8709ce9d245bd6cce3e4adb520a3bfbf5d302 489460
exim4_4.98.2-1+deb13u1.debian.tar.xz
Files:
02e87a0a40b6b7af9c1f1d2ce97645ea 2929 mail standard exim4_4.98.2-1+deb13u1.dsc
7d03630deaf880609248c00b0426ec97 489460 mail standard
exim4_4.98.2-1+deb13u1.debian.tar.xz
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEE0uCSA5741Jbt9PpepU8BhUOCFIQFAmn3L7QACgkQpU8BhUOC
FIQtEw/+O/mGpPwZN32br2j0SulXZjWNOAsvuyv4q23ptud3oDqaCZkF9sZkOkid
ECX6040xGlaVif425nuT0KvofQxTuufIoAikr53KMEwE6X90We5qswv4GFFMV6g8
v3KYR1u+loU8MhYnlfeNmN9Plb26AZ9xp/T7W11TdavpmW47u8/zbkZJmzM3H+dv
CYY8jnaS6n8fMq3kdfD54QmfDYsY4vH49RYSVRcni8uiBZOanrmUsr9F49UtsFuX
z+nEl+Vq35oH7/tP/PdaL1qSOENDltac4pGfctPtdEp45vi0JVqLY73ISV+d/peD
HT+zB19FtrxNEPW4eIVnFQ8vOY9Dn5RldyW4H66wdiodDmcn/XGJCZjNtJjHzZEE
LP0VXjMh4HrXJ8ZHrc/4R/KFnNxCECg1YnjY4lCoYfUoBerqt0AAod0pStznj9Yf
NtooogZrZR5Oqa11WH3TQyOPCFdg73fNmJdw1qrHzLgEXfkpauozzSMnMqeJiA7K
jYt754WzL7PFF9uSyxig7j8aXmzwUH2jGSMtc2JSAz6uLVlRSK5YHEIlMlHISUc/
iTtHEBai99UTmA7RtczSuq60TfKgsKkD5G6Qm/wLkVqhyk3CIZzY7VZjnKouis8D
dyQIVXdx/d3ANv9bZo2Z/9HQ+a0HOUwKg28nmJ4Onhwuk7Mw3m4=
=v4Me
-----END PGP SIGNATURE-----
pgpdlwMQxvQIN.pgp
Description: PGP signature
--- End Message ---
