> Sounds promising. Do you think this should be hooked into SSLContext.set_default_verify_paths, or be exposed as a separate method?

If there were an API which exposed the certificate material, then this would be more useful to libraries trying to do other things (present debugging information, use an alternate SSL implementation *wink*, etc).  If this is *only* wrapped up inside set_default_verify_paths then many of these extra things are impossible with a seconding binding to the same API.