Created attachment 1472812 [details]
Set SNI to the server name
Description of problem:
Connecting to imap.gmail.com has started throwing the following errors:
fetchmail: 6.3.26 querying imap.gmail.com (protocol IMAP) at Wed 01 Aug 2018 03:40:22 PM EDT: poll started
Trying to connect to 2607:f8b0:400d:c0c::6c/993...connected.
fetchmail: Server certificate:
fetchmail: Unknown Organization
fetchmail: Issuer CommonName: invalid2.invalid
fetchmail: Subject CommonName: invalid2.invalid
fetchmail: Server CommonName mismatch: invalid2.invalid != imap.gmail.com
fetchmail: imap.gmail.com key fingerprint: 90:4A:C8:D5:44:5A:D0:6A:8A:10:FF:CD:8B:11:BE:16
fetchmail: Server certificate verification error: self signed certificate
fetchmail: Missing trust anchor certificate: /OU=No SNI provided; please fix your client./CN=invalid2.invalid
Yes, they passed back a self-signed cert.
From the OpenSSL project mailing list:
"In the world of SMTP, with SMTP server names determined indirectly
and generally insecurely from MX records, it is not generally clear
what name one would use in SNI, and many SMTP clients don't send it
at all. Some authenticate servers against the nexthop domain (the
envelope recipient domain), others might authenticate the MX host,
or just do unauthenticated opportunistic TLS. This has worked
acceptably well with TLS <= 1.2
Along comes 1.3, and suddenly some server operators have become
particularly keen on enforcing all sorts of constraints that at
first blush look rather aggressive. Specifically, the Google
SMTP servers serving millions of domains (including gmail.com),
now only do TLS 1.3 when SNI is presented, and when SNI is missing,
not only negotiate TLS 1.2, but use an unexpected self-signed cert
chain that validating senders will fail to authenticate, and others
may find perplexing in their logs. (Thanks to Phil Pennock, Bcc'd
for reporting this on the exim-dev list).
Full discussion here:
Fix? Set the SNI. Patch attached.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
The patch is inadequate, it lacks error checking. Please reopen the bug report and back out the patch.
The upstream Git repository has had a proper solution for a year now, https://gitlab.com/fetchmail/fetchmail/commit/9b8b634312f169fab872f3580c2febe5af031615
Thanks for heads-up. I've backported the upstream patch.
fetchmail-6.3.26-22.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2018-eb46a96c04
fetchmail-6.3.26-22.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-eb46a96c04
fetchmail-6.3.26-22.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report.
An Ubuntu bug report claims that downgrading to TLS v1.0 worked around the bug, but I do not recommend doing that.