can't retrieve gmail emails. fetchmail: OU=No SNI provided; please fix your client./CN=invalid2.invalid

fetchmail: 6.3.26 querying pop.gmail.com (protocol POP3) at Fri Oct 19 11:58:36 2018: poll started
fetchmail: Trying to connect to 108.177.119.109/995...connected.
fetchmail: Server certificate:
fetchmail: Unknown Organization
fetchmail: Issuer CommonName: invalid2.invalid
fetchmail: Subject CommonName: invalid2.invalid
fetchmail: Server CommonName mismatch: invalid2.invalid != pop.gmail.com
fetchmail: pop.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
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: Server certificate:
fetchmail: Unknown Organization
fetchmail: Issuer CommonName: invalid2.invalid
fetchmail: Subject CommonName: invalid2.invalid
fetchmail: Server CommonName mismatch: invalid2.invalid != pop.gmail.com
fetchmail: SSL/TLS: using protocol TLSv1.2, cipher ECDHE-RSA-CHACHA20-POLY1305, 256/256 secret/processed bits
fetchmail: Warning: the connection is insecure, continuing anyways. (Better use --sslcertck!)

using [sslproto "TLS1"] instead of [sslproto "TLS1.2+"] seems to bypass the issue.

Fetchmail 6.3.26 indeed does not set the SNI. The original fetchmail 6.3.26 also does not support TLS1.2+ or thereabouts, see https://gitlab.com/fetchmail/fetchmail/blob/legacy_63/socket.c#L906 - if Ubuntu's shipped version does, it is not the original authentic fetchmail 6.3.26.

Hi Matthias,

You're right, the [sslproto "TLS1.2+"] was commented on my fetchmailrc, but forcing the value to TLS1 solved my issue with SNI/TLS1.2.

I have found some old logs where fetchmail was working perfectly before the upgrade to cosmic

fetchmail: 6.3.26 interroge pop.sunrise.ch (protocole POP3) à dim 14 oct 2018 00:10:02 CEST : récupération en cours
fetchmail: Essai de connexion avec 195.141.178.72/995...connecté.
fetchmail: Certificat du serveur:
fetchmail: Organisation de l'expéditeur: DigiCert Inc
fetchmail: Nom commun de l'émetteur : Thawte RSA CA 2018
fetchmail: Nom commun du sujet: pop.sunrise.ch
fetchmail: Nom Alternatif du Sujet : pop.sunrise.ch
fetchmail: signature de la clé pop.sunrise.ch : 9B:38:AB:E6:D2:DF:D9:EB:CE:12:CB:8D:5F:46:72:DD
fetchmail: SSL/TLS: using protocol TLSv1.2, cipher ECDHE-RSA-AES256-GCM-SHA384, 256/256 secret/processed bits
fetchmail: POP3< +OK Dovecot ready.
fetchmail: POP3> CAPA

fetchmail: 6.3.26 interroge pop.gmail.com (protocole POP3) à dim 07 oct 2018 00:30:08 CEST : récupération en cours
fetchmail: Essai de connexion avec 173.194.76.108/995...connecté.
fetchmail: Certificat du serveur:
fetchmail: Organisation de l'expéditeur: Google Trust Services
fetchmail: Nom commun de l'émetteur : Google Internet Authority G3
fetchmail: Nom commun du sujet: pop.gmail.com
fetchmail: Nom Alternatif du Sujet : pop.gmail.com
fetchmail: signature de la clé pop.gmail.com : 7B:19:5D:79:4A:8C:5A:A7:BA:05:99:D7:DB:39:F4:7D
fetchmail: SSL/TLS: using protocol TLSv1.2, cipher ECDHE-RSA-CHACHA20-POLY1305, 256/256 secret/processed bits
fetchmail: POP3< +OK Gpop ready for requests from xxxx
fetchmail: POP3> CAPA
fetchmail: POP3< +OK Capability list follows

Thanks for filing this bug in Ubuntu.

The fetchmail package in Ubuntu is a sync from the Debian package, with no further changes.

Do you have a sample config (minus usernames and passwords, of course) that shows the problem? Just the sslproto setting with gmail is enough to reproduce it?

Ah, I see the other bug reports now.

upstream patch: https://gitlab.com/fetchmail/fetchmail/commit/9b8b634312f169fab872f3580c2febe5af031615

Cannot confirm that this affects bionic. This may be due to openssl 1.1.0 (in bionic) sending a default SNI when none is provided, whereas 1.1.1 (in cosmic) sends nothing.

I got the problem just after updating my Raspberry PI3

OpenSSL> version
OpenSSL 1.1.1 11 Sep 2018
OpenSSL>

fetchmail, version 6.3.26+GSS+NTLM+SDPS+SSL-SSLv3+NLS+KRB5.

cat /etc/issue
Raspbian GNU/Linux 9 \n \l

I confirm that sslproto "TLS1" seems to be a workaround

fetchmail: Chaîne de certification, depuis la racine jusqu'au correspondant, débutant à la profondeur 2:
fetchmail: Organisation de l'expéditeur: GlobalSign
fetchmail: Nom commun de l'émetteur : GlobalSign
fetchmail: Nom commun du sujet: GlobalSign
fetchmail: Certificat à la profondeur 1:
fetchmail: Organisation de l'expéditeur: GlobalSign
fetchmail: Nom commun de l'émetteur : GlobalSign
fetchmail: Nom commun du sujet: Google Internet Authority G3
fetchmail: Certificat du serveur:
fetchmail: Organisation de l'expéditeur: Google Trust Services
fetchmail: Nom commun de l'émetteur : Google Internet Authority G3
fetchmail: Nom commun du sujet: pop.gmail.com
fetchmail: Nom Alternatif du Sujet : pop.gmail.com
fetchmail: signature de la clé pop.gmail.com : 4E:C6:82:2E:F7:D7:40:F3:E1:7B:89:4F:D4:F7:CF:E4
fetchmail: SSL/TLS: using protocol TLSv1, cipher ECDHE-RSA-AES128-SHA, 128/128 secret/processed bits

Whithout this setting, I get
fetchmail: Erreur de vérification du certificat du serveur : self signed certificate
fetchmail: Certificat approuvé manquant : /OU=No SNI provided; please fix your client./CN=invalid2.invalid
fetchmail: Ceci pourrait signifier que le certificat de signature du CA racine n'est pas dans la liste des certificats des CA de confiance ou que c_rehash doit être exécuté sur le répertoire des certificats. Pour plus de détails, consultez la documentation de --sslcertpath et --sslcertfile dans la page de manuel.

The upload of this fix is just waiting for the ubuntu Disco archive to reopen after the cosmic release, as the fix needs to be applied there first.

This bug was fixed in the package fetchmail - 6.3.26-3ubuntu1

---------------
fetchmail (6.3.26-3ubuntu1) disco; urgency=medium

  * d/p/sni-support.patch: TLS: set hostname for SNI. Thanks to Matthias
    Andree <email address hidden> (LP: #1798786)

 -- Karl Stenerud <email address hidden> Wed, 24 Oct 2018 05:12:24 -0700

Uploaded to cosmic-proposed, waiting for SRU team's inspection.

Hello Hassan, or anyone else affected,

Accepted fetchmail into cosmic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/fetchmail/6.3.26-3ubuntu0.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-cosmic to verification-done-cosmic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-cosmic. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

Hi Brian, hi folks,

The patch/new build seems to fix the issue, thanks for the fix.

fetchmail: 6.3.26 querying pop.gmail.com (protocol POP3) at Wed Nov 14 11:24:19 2018: poll completed
fetchmail: New UID list from pop.gmail.com: <empty>
fetchmail: not swapping UID lists, no UIDs seen this query
fetchmail: Query status=1 (NOMAIL)
fetchmail: 6.3.26 querying pop.gmail.com (protocol POP3) at Wed Nov 14 11:24:19 2018: poll started
fetchmail: Trying to connect to 108.177.126.109/995...connected.
fetchmail: Certificate chain, from root to peer, starting at depth 2:
fetchmail: Issuer Organization: GlobalSign
fetchmail: Issuer CommonName: GlobalSign
fetchmail: Subject CommonName: GlobalSign
fetchmail: Certificate at depth 1:
fetchmail: Issuer Organization: GlobalSign
fetchmail: Issuer CommonName: GlobalSign
fetchmail: Subject CommonName: Google Internet Authority G3
fetchmail: Server certificate:
fetchmail: Issuer Organization: Google Trust Services
fetchmail: Issuer CommonName: Google Internet Authority G3
fetchmail: Subject CommonName: pop.gmail.com
fetchmail: Subject Alternative Name: pop.gmail.com
fetchmail: pop.gmail.com key fingerprint: 4E:C6:82:2E:F7:D7:40:F3:E1:7B:89:4F:D4:F7:CF:E4
fetchmail: SSL/TLS: using protocol TLSv1.2, cipher ECDHE-RSA-CHACHA20-POLY1305, 256/256 secret/processed bits

Thanks Hassan,

Updating tags per previous comment.

This bug was fixed in the package fetchmail - 6.3.26-3ubuntu0.1

---------------
fetchmail (6.3.26-3ubuntu0.1) cosmic; urgency=medium

  * d/p/sni-support.patch: TLS: set hostname for SNI. Thanks to Matthias
    Andree <email address hidden> (LP: #1798786)

 -- Karl Stenerud <email address hidden> Wed, 24 Oct 2018 05:12:24 -0700

The verification of the Stable Release Update for fetchmail has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

This morning an update for openssl and libssl from 1.1.0g to 1.1.1 went out to bionic (Ubuntu 18.04 LTS), which means bionic users are now affected by this bug as well (given that 1.1.1 ships TLS 1.3 support, plus the google configuration described in https://mta.openssl.org/pipermail/openssl-project/2018-April/000635.html ).

Any chance of this fix being pushed to bionic too?

Confirmed it's now happening in bionic, thanks for the heads up!

Uploaded, it's in the SRU bionic queue

Hello Hassan, or anyone else affected,

Accepted fetchmail into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/fetchmail/6.3.26-3ubuntu0.1~18.04.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

This seems like a very appropriate candidate for skipping the normal ageing period. We understand the problem well, it has been fixed in Cosmic for a long time, and the Bionic source will now be identical (apart from the changelog). And I am fairly confident there are a non-zero number of users using fetchmail against Gmail.

Is the bug description here inaccurate? It states that this problem exists when using TLS1.2, which was supported by OpenSSL on Bionic at release time. Does the problem in fact only occur with TLS1.3?

Bionic verification

First, reproducing the bug, following the test steps:

Version used:
 *** 6.3.26-3build1 500
        500 http://archive.ubuntu.com/ubuntu bionic/main amd64 Packages

Bug reproduced:
root@bionic-fetchmail-sni:~# fetchmail -d0 -vk --sslcertck pop.gmail.com
fetchmail: WARNING: Running as root is discouraged.
fetchmail: 6.3.26 querying pop.gmail.com (protocol POP3) at Wed Jun 12 15:27:44 2019: poll started
Trying to connect to 64.233.190.108/995...connected.
fetchmail: Server certificate:
fetchmail: Unknown Organization
fetchmail: Issuer CommonName: invalid2.invalid
fetchmail: Subject CommonName: invalid2.invalid
fetchmail: Server CommonName mismatch: invalid2.invalid != pop.gmail.com
fetchmail: pop.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
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 <email address hidden>@pop.gmail.com
fetchmail: 6.3.26 querying pop.gmail.com (protocol POP3) at Wed Jun 12 15:27:44 2019: poll completed
fetchmail: Query status=2 (SOCKET)
fetchmail: normal termination, status 2

Now updating to this version:
root@bionic-fetchmail-sni:~# apt-cache policy fetchmail
fetchmail:
  Installed: 6.3.26-3ubuntu0.1~18.04.1
  Candidate: 6.3.26-3ubuntu0.1~18.04.1
  Version table:
 *** 6.3.26-3ubuntu0.1~18.04.1 500
        500 http://archive.ubuntu.com/ubuntu bionic-proposed/main amd64 Packages

This time, TLS1.3 is established, and we just get the authentication error as expected:
root@bionic-fetchmail-sni:~# fetchmail -d0 -vk --sslcertck pop.gmail.com
fetchmail: WARNING: Running as root is discouraged.
fetchmail: 6.3.26 querying pop.gmail.com (protocol POP3) at Wed Jun 12 15:28:52 2019: poll started
Trying to connect to 64.233.186.108/995...connected.
fetchmail: Server certificate:
fetchmail: Issuer Organization: Google Trust Services
fetchmail: Issuer CommonName: Google Internet Authority G3
fetchmail: Subject CommonName: pop.gmail.com
fetchmail: Subject Alternative Name: pop.gmail.com
fetchmail: pop.gmail.com key fingerprint: BC:92:09:CC:42:0E:AA:91:CA:B6:64:C5:80:8B:08:74
fetchmail: SSL/TLS: using protocol TLSv1.3, cipher TLS_AES_256_GCM_SHA384, 256/256 secret/processed bits
fetchmail: POP3< +OK Gpop ready for requests from 177.16.188.25 z4mb74186347qtc
fetchmail: POP3> CAPA
fetchmail: POP3< +OK Capability list follows
fetchmail: POP3< USER
fetchmail: POP3< RESP-CODES
fetchmail: POP3< EXPIRE 0
fetchmail: POP3< LOGIN-DELAY 300
fetchmail: POP3< TOP
fetchmail: POP3< UIDL
fetchmail: POP3< X-GOOGLE-RICO
fetchmail: POP3< SASL PLAIN XOAUTH2 OAUTHBEARER
fetchmail: POP3< .
fetchmail: POP3> US...

Steve said:
Is the bug description here inaccurate? It states that this problem exists when using TLS1.2, which was supported by OpenSSL on Bionic at release time. Does the problem in fact only occur with TLS1.3?

The bug description is accurate. OpenSSL 1.1.1 started to validate and thus enforce requirement to send SNI with any TLS connections, including TLSv1.2, as described in the regression potential section of the openssl sru.

This bug was fixed in the package fetchmail - 6.3.26-3ubuntu0.1~18.04.1

---------------
fetchmail (6.3.26-3ubuntu0.1~18.04.1) bionic; urgency=medium

  * d/p/sni-support.patch: TLS: set hostname for SNI. Thanks to Matthias
    Andree <email address hidden> (LP: #1798786)

 -- Andreas Hasenack <email address hidden> Wed, 12 Jun 2019 10:46:34 -0300

I believe https://mta.openssl.org/pipermail/openssl-project/2018-April/000635.html explains why the problem with gmail occurs only with TLS 1.3.

When I hit the problem two days ago, using 'sslproto "TLS1.2"' (with no '+') in my configuration for gmail fixed the problem, since it forced the use of TLS 1.2 rather than TLS 1.3 (which started being used with the openssl upgrade).

Got the same issue on Sylpheed after upgrading to bionic. Any ideas?

Thanks for reporting that here: https://bugs.launchpad.net/ubuntu/+source/sylpheed/+bug/1847716