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: https://mta.openssl.org/pipermail/openssl-project/2018-April/000623.html Fix? Set the SNI. Patch attached. Version-Release number of selected component (if applicable): fetchmail-6.3.26-20.fc29.x86_64 How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Applied, thanks!
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. https://bugs.launchpad.net/ubuntu/+source/fetchmail/+bug/1798786