FS#60038 - [fetchmail] cannot fetch mail: Server CommonName mismatch

Attached to Project: Arch Linux
Opened by Sergey Senozhatsky (bend3r) - Thursday, 13 September 2018, 02:32 GMT
Last edited by Jelle van der Waa (jelly) - Sunday, 28 April 2019, 10:40 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Pierre Schmitz (Pierre)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 2
Private No

Details

Description:
Unable to fetch from Gmail

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

RedHat's bugzilla:
https://bugzilla.redhat.com/show_bug.cgi?id=1611815

This patch fixes the issue on my side:
https://bugzilla.redhat.com/attachment.cgi?id=1472812&action=diff

Additional info:
fetchmail-6.3.26-6
This task depends upon

Closed by  Jelle van der Waa (jelly)
Sunday, 28 April 2019, 10:40 GMT
Reason for closing:  Deferred
Additional comments about closing:  fetchmail is removed from the repositories
Comment by Sergey Senozhatsky (bend3r) - Thursday, 13 September 2018, 02:42 GMT
D'oh... I just noticed " FS#60038  - [fetchmail] PLEASE ENTER SUMMARY". Sorry about that. Should have been something like "fetchmail: Server CommonName mismatch"
Comment by Eli Schwartz (eschwartz) - Thursday, 13 September 2018, 03:09 GMT
  • Field changed: Summary ([fetchmail] PLEASE ENTER SUMMARY → [fetchmail] cannot fetch mail: Server CommonName mismatch)
  • Field changed: Category (Packages: Extra → Upstream Bugs)
Has anyone thought to submit an upstream bug report? This fedora patch does not appear to be in the upstream git repository: https://gitlab.com/fetchmail/fetchmail

Nor is it on the sourceforge mailing list archives
Comment by Sergey Senozhatsky (bend3r) - Thursday, 13 September 2018, 08:19 GMT
The code from the master branch does

/* This data is for the verify callback */
mydata.ssl_server_cname = servercname;
mydata.server_label = label;
mydata.check_fp = 1;
mydata.check_digest = fingerprint;
mydata.depth0ck = 0;
mydata.firstrun = 1;
mydata.verify_ok = 1;
mydata.prev_err = -1;
mydata.strict_mode = certck;

...

SSL_set_ex_data(_ssl_context[sock], global_mydata_index, &mydata);

This porbably can look like a fix [but I didn't test yet].
But I'm not sure if SSL_set_ex_data() and SSL_set_tlsext_host_name() do the same thing.
I'll ask upstream fetchmail people.

-ss
Comment by Eli Schwartz (eschwartz) - Thursday, 13 September 2018, 12:03 GMT
Lol, it looks like they may have already fixed this upstream via https://gitlab.com/fetchmail/fetchmail/commit/9b8b634312f169fab872f3580c2febe5af031615
Comment by Eli Schwartz (eschwartz) - Thursday, 13 September 2018, 12:06 GMT
  • Field changed: Status (Unconfirmed → Assigned)
  • Field changed: Category (Upstream Bugs → Packages: Extra)
  • Task assigned to Pierre Schmitz (Pierre)
I guess it probably makes sense to backport this upstream commit.
Comment by Sergey Senozhatsky (bend3r) - Thursday, 13 September 2018, 14:15 GMT
Oh... Good catch. Thanks.
"authored 1 year ago by Matthias Andree" lol

-ss
Comment by Matthias Andree (mandree) - Friday, 19 October 2018, 16:52 GMT
The referenced patch in RedHat's Bugzilla does not contain error checking code and must not be used.
Use the Gitlab link in Eli Schwartz's comment.
Comment by Matthias Andree (mandree) - Friday, 19 October 2018, 16:54 GMT
Re bend3r's comment https://bugs.archlinux.org/task/60038#comment173004 - the SSL_set_ex_data is to provide data between the calling function and the called OpenSSL library code so it does not do the same thing. I have cherry-picked the SSL_set_tlsext_host_name() to the master branch only on 2018-09-17, https://gitlab.com/fetchmail/fetchmail/commit/0cdc4caa940b8a1e36ff72caeb4c4487700bebb1 .
Comment by Sergey Senozhatsky (bend3r) - Tuesday, 13 November 2018, 02:05 GMT
$ sudo pacman -Q | grep fetchmail
fetchmail 6.3.26-7

Still can't fetch:

fetchmail: Server CommonName mismatch: invalid2.invalid != pop.gmail.com
fetchmail: Server certificate verification error: self signed certificate
fetchmail: Missing trust anchor certificate: /OU=No SNI provided; please fix your client./CN=invalid2.invalid
fetchmail: This could mean that the root CA's signing certificate is not in the trusted CA certificate location, or that c_rehash needs to be run on the certificate directory. For details, please see the documentation of --sslcertpath and --sslcertfile in the manual page.
fetchmail: OpenSSL reported: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed
fetchmail: SSL connection failed.
fetchmail: socket error while fetching from XXXXX@pop.gmail.com
fetchmail: Query status=2 (SOCKET)

-ss
Comment by Sergey Senozhatsky (bend3r) - Friday, 22 February 2019, 06:57 GMT
Might be helpful,

Connection fails with the recommended sslproto option: "ssl sslproto 'auto'". It seems that only "sslproto 'tls1'"
works (which is awful) [see https://bugs.launchpad.net/ubuntu/+source/fetchmail/+bug/1798786 ].

However, if I build fetchmail from the master branch "https://gitlab.com/fetchmail/fetchmail/-/archive/master/fetchmail-master.zip"
then "sslproto 'auto'" is working just fine and fetchmail is happy to use ssl23 (which is much better than tls1):

fetchmail -v

fetchmail: 6.3.26 querying pop.gmail.com (protocol POP3) at Fri 22 Feb 2019 03:49:32 PM KST: poll started
Trying to connect to 64.233.188.108/995...connected.
fetchmail: Invalid SSL protocol 'auto' specified, using default (SSLv23).
fetchmail: Server certificate:
fetchmail: Issuer Organization: Google Trust Services
fetchmail: Issuer CommonName: Google Internet Authority G3
[..]

-ss

Loading...