> It would be useful to know if you see the problem with a vanilla 1.7.1,
> vanilla 1.7.2 and default tip right now.
 
In brief: after 1.7.2. See below.

> My understanding is that the warning notice is occuring because the
> certficate presented by the server is expired, which shouldn't have
> anything to do with your local certificate store, so I'm a bit confused.

That's not consistent with the experience here. The problem is very clearly 
related to the local store.

It's a bit tricky to reproduce because the goalposts are moving, but here goes.

I'm restoring my old certificates file with 81 certificates, some 64 of which 
are expired. And here's where the "moving goalposts" come into play: since I 
saved that copy in January, I added a new CA cert

        Issuer: C=US, O=Equifax, OU=Equifax Secure Certificate Authority
        Validity
            Not Before: May 21 04:00:00 2002 GMT
            Not After : Aug 21 04:00:00 2018 GMT
        Subject: C=US, O=GeoTrust Inc., CN=GeoTrust Global CA

This makes everything that follows more transparent because it concerns only 
the gmail certificate. In fact, I can reproduce this with an "old certificates 
file " cut down to three certs, Equifax, Geotrust, expired imap.gmail.

I'm building copies of vanilla 1.7.1, 1.7.2 and tip resp. with

$ ./configure --enable-imap --without-gnutls --with-ssl --with-sasl

and run them with ./mutt -F ~/.mutt/gmail.rc in turn.

1.7.1 - reports there's a new gmail certificate,

This certificate belongs to:
   imap.gmail.com
   Unknown
   Google Inc
   Unknown
   Mountain View

This certificate was issued by:
   Google Internet Authority G2
   Unknown
   Google Inc
   Unknown
   Unknown

This certificate is valid
   from Jan 25 10:16:30 2017 GMT
     to Apr 19 10:09:00 2017 GMT

Fingerprint: 12F2 FD54 B782 1485 6C35 841F CEB3 A05F


-- Mutt: SSL Certificate check (certificate 3 of 3 in chain)
(r)eject, accept (o)nce, (a)ccept always

I (a)ccept and exit. Comparing the updated certificate file with a pre-update 
copy, there was one certificate added, and openssl x509 confirms that this is 
the certificate mutt presented above (on a side note, mutt shows the MD5 
fingerprint, and openssl without options shows SHA1). Opening mutt again, it 
goes straight to the password prompt.

So far so good. Reset the certificates file to the pre-update copy and repeat 
with 1.7.2. It behaves identically.

Repeat the process with tip. This is different:

server certificate has expired

This certificate belongs to:
   Google Internet Authority G2
   Unknown
   Google Inc
   Unknown
   Unknown
   Unknown
   US

This certificate was issued by:
   GeoTrust Global CA
   Unknown
   GeoTrust Inc.
   Unknown
   Unknown
   Unknown
   US

This certificate is valid
   from Apr  5 15:15:55 2013 GMT
     to Dec 31 23:59:59 2016 GMT
-- Mutt: SSL Certificate check (certificate 2 of 3 in chain)
(r)eject, accept (o)nce

This is certificate #2 in the certificates file.

Gentoo mutt behaves the same, they probably include some post-1.7.2 updates 
from mercurial.

This is getting very long, but here is another aspect: with the certificates 
store cut down to two certs (CN=Geotrust, Issuer=Equifax; CN=Google G2, 
Issuer=Geotrust), mutt 1.7.1 and 1.7.2 will prompt for acceptance of the 
imap.gmail.com cert shown above (fp = 12F2 ...). Tip and Gentoo do not actually 
check the server cert and go straight to the password prompt!

Reply via email to