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

Bug #1798786 reported by Hassan El Jacifi on 2018-10-19
38
This bug affects 5 people
Affects Status Importance Assigned to Milestone
fetchmail (Debian)
Fix Released
Unknown
fetchmail (Ubuntu)
High
Karl Stenerud
Bionic
High
Andreas Hasenack
Cosmic
High
Karl Stenerud

Bug Description

[Impact]

Fetchmail doesn't set hostname for SNI when using TLS. Without this, fetchmail fails to verify the SSL certificate using TLS 1.2 for places such as pop.gmail.com.

[Test Case]

# lxc launch ubuntu:cosmic tester
# lxc exec tester bash
# apt update
# apt dist-upgrade -y
# apt install -y fetchmail
# echo "set postmaster \"root\"
poll pop.gmail.com with proto POP3
   user '<email address hidden>' there with password 'any-password' is root here options ssl
" > ~/.fetchmailrc
# chmod 700 ~/.fetchmailrc
# fetchmail -d0 -vk --sslcertck pop.gmail.com
...
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: Server certificate verification error: self signed certificate
...

[Regression Potential]

This change affects how TLS connections are handled. The change adds a server name indication, which will either be ignored or not by the host. The only regression potential would be with possibly already broken SNI code that is now being activated.

[Original Description]

https://bugzilla.redhat.com/show_bug.cgi?id=1611815
https://bugs.archlinux.org/task/60038

ProblemType: Bug
DistroRelease: Ubuntu 18.10
Package: fetchmail 6.3.26-3build1
ProcVersionSignature: Ubuntu 4.18.0-10.11-generic 4.18.12
Uname: Linux 4.18.0-10-generic x86_64
NonfreeKernelModules: wl nvidia_modeset nvidia
ApportVersion: 2.20.10-0ubuntu13
Architecture: amd64
CurrentDesktop: GNOME
Date: Fri Oct 19 11:08:36 2018
InstallationDate: Installed on 2018-01-01 (290 days ago)
InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20171221)
SourcePackage: fetchmail
UpgradeStatus: Upgraded to cosmic on 2018-10-18 (0 days ago)
modified.conffile..etc.default.apport: [modified]
mtime.conffile..etc.default.apport: 2018-01-18T18:05:44.880717

Related branches

Hassan El Jacifi (waver) wrote :
Hassan El Jacifi (waver) wrote :

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!)

Hassan El Jacifi (waver) wrote :

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.

Hassan El Jacifi (waver) wrote :

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

Andreas Hasenack (ahasenack) wrote :

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?

Andreas Hasenack (ahasenack) wrote :

Ah, I see the other bug reports now.

Andreas Hasenack (ahasenack) wrote :
Changed in fetchmail (Ubuntu):
status: New → Triaged
importance: Undecided → High
tags: added: server-next
Changed in fetchmail (Ubuntu):
assignee: nobody → Karl Stenerud (kstenerud)
status: Triaged → Confirmed
description: updated
Changed in fetchmail (Ubuntu):
status: Confirmed → Fix Committed
Changed in fetchmail (Ubuntu Cosmic):
status: Fix Committed → In Progress
Changed in fetchmail (Ubuntu Bionic):
status: New → Confirmed
assignee: nobody → Karl Stenerud (kstenerud)
importance: Undecided → High
Karl Stenerud (kstenerud) wrote :

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.

no longer affects: fetchmail (Ubuntu Bionic)
Elbarbudo (patricearnal) wrote :

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

Elbarbudo (patricearnal) wrote :

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.

Andreas Hasenack (ahasenack) wrote :

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.

Changed in fetchmail (Debian):
status: Unknown → New
Launchpad Janitor (janitor) wrote :

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

Changed in fetchmail (Ubuntu):
status: In Progress → Fix Released
Andreas Hasenack (ahasenack) wrote :

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.

Changed in fetchmail (Ubuntu Cosmic):
status: In Progress → Fix Committed
tags: added: verification-needed verification-needed-cosmic
Hassan El Jacifi (waver) wrote :

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

Karl Stenerud (kstenerud) wrote :

Thanks Hassan,

Updating tags per previous comment.

tags: added: verification-done verification-done-cosmic
removed: verification-needed verification-needed-cosmic
Launchpad Janitor (janitor) wrote :

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

Changed in fetchmail (Ubuntu Cosmic):
status: Fix Committed → Fix Released

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.

Changed in fetchmail (Debian):
status: New → Fix Released
L. David Baron (dbaron) wrote :

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?

Andreas Hasenack (ahasenack) wrote :

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

Changed in fetchmail (Ubuntu Bionic):
importance: Undecided → High
Robie Basak (racb) on 2019-06-12
tags: added: regression-update
Changed in fetchmail (Ubuntu Bionic):
status: New → In Progress
assignee: nobody → Andreas Hasenack (ahasenack)
Andreas Hasenack (ahasenack) wrote :

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!

Changed in fetchmail (Ubuntu Bionic):
status: In Progress → Fix Committed
tags: added: verification-needed verification-needed-bionic
removed: verification-done
Robie Basak (racb) wrote :

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.

Steve Langasek (vorlon) wrote :

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?

Andreas Hasenack (ahasenack) wrote :
Download full text (3.8 KiB)

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...

Read more...

tags: added: verification-done-bionic
removed: verification-needed-bionic
Dimitri John Ledkov (xnox) wrote :

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.

Launchpad Janitor (janitor) wrote :

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

Changed in fetchmail (Ubuntu Bionic):
status: Fix Committed → Fix Released
L. David Baron (dbaron) wrote :

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).

Robie Basak (racb) on 2019-10-08
tags: added: bionic-openssl-1.1
Moshe Caspi (mcaspi12) wrote :

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

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.