Am 10.02.2017 um 03:07 schrieb Kevin J. McCarthy: > I will take a closer look tomorrow, but honestly I find the behavior with > the expired imap.google.com in your cert filed very strange. If I can't > figure anything out, I will revert the patch for the 1.8 release.
I object to reverting the patch. I've looked through the debug log and current code (6 commits further down than isdtor's), and the offending code apparently only triggers when mutt runs through the preverify_ok == 0 code paths. The design flaw is that OpenSSL assumes that its trust store (the verify locations) are "clean" and only has valid certificates, and CA root signing certificates at that. Mutt, when used in isdtor's setup, pollutes that store with server certificates that have shorter expiration times, and that confuses the crap out of OpenSSL. Personally, I consider storing server certificates in the trusted CA store abuse, and mutt automates this by loading back this "user-saved certificates" as though it were a set of CA certificates. I think the only way to remedy this is to keep the "accept always" certificates separate from any place that would be reloaded with any of the trust store functions (SSL_CTX_load_verify_locations()), and NOT load them, but only use them for explicit verification. For any properly configured use of TLS with certificates, we never need to look at mutt's cache, so in normal use of X.509-certificate based trust, the server certificates never make it into mutt's SslCertFile, and isdtor should install the proper root certificates. Any interactive_check_cert() prompt menu is a hint that the root CA trust store is incomplete, and that should be fixed, not the unverified server certificate stored.
