> You need to check expiration date of the cert in question, and I
> suppose invocation date as well.
> You need to look at each of the CNs in the subject name, as well as
> each of the DNSname types in the SAN extension.
> You *absolutely must* make sure that each of the intermediate
> certificates has Basic Constraints: CA set to True.  Otherwise a
> certificate for foo.com can sign for bar.com (this keeps happening).

I'm confident this is already done by OpenSSL (if requested by user,
which means using CERT_REQUIRED or CERT_OPTIONAL in Python's ssl module
- these map to OpenSSL's SSL_VERIFY_PEER).

I guess it would be easy to check this by providing an outdated
certificate - perhaps I'll give it a try.

> > > A) Integrate the Mozilla CA pack into Python, updating it with each
> > > security release.
> 
> > I suggest you discuss this on python-dev:
> > http://mail.python.org/mailman/listinfo/python-dev
> 
> It's an ugly dependency, I know.  X.509 suffers from a "false
> coherence" design, in which a couple of parties actively work to make
> it look like it has a coherent trust model.  The best you can do is
> try to borrow/leverage the work of one of those parties.

I suppose distributing CA certificates is a practical solution for the
user, *if* we are dedicated enough (e.g. release managers would have to
agree with the burden of tracking changes, and possibly making emergency
releases when a cert must be removed). That's the reason I suggest
asking on python-dev; I don't feel like making that decision alone.

That said, system OpenSSL builds on Linux (and perhaps OS X) should have
been compiled against a well-known system location of CA certificates
maintained by the OS vendor. In this case, you can simply use
SSLContext.set_default_verify_paths
(http://docs.python.org/dev/library/ssl.html#ssl.SSLContext.set_default_verify_paths )
That doesn't help under Windows, though (where we build OpenSSL
ourselves so that the ssl module can be bundled in installers).