Issue 1:
I want to start off by saying I think this is a pretty unusual use case and it appears to me to boil down to a behaviour in urllib3. However, I encountered it while working with requests and I'm not familiar enough with urllib3 to say whether the behaviour is expected or not. It may be that the fix is to document this behaviour in requests, or make a change in urllib3, but I don't know for sure.

Problem Summary

Configure a requests.sessions.Session with a CA file.

Make a request using HTTPS to a host that has a certificate signed by this CA.

Reconfigure the requests.sessions.Session object with a new CA file and delete the old one.

Wait until the connection with the server is closed (either from inactivity or by forcing it with 'Connection: close' on the request made in step 2).

Make a second request using HTTPS to a host that has a certificate signed by the new CA.

Instead of the same response from step 2, an exception is raised.

The exception looks something like this and is from the reproducer I've included below:

Traceback (most recent call last):
File "test_requests.py", line 78, in <module>
headers={'Connection': 'close'})
File "/home/jcline/.virtualenvs/test_requests/lib/python2.7/site-packages/requests/sessions.py", line 480, in get
return self.request('GET', url, **kwargs)
File "/home/jcline/.virtualenvs/test_requests/lib/python2.7/site-packages/requests/sessions.py", line 468, in request
resp = self.send(prep, **send_kwargs)
File "/home/jcline/.virtualenvs/test_requests/lib/python2.7/site-packages/requests/sessions.py", line 576, in send
r = adapter.send(request, **kwargs)
File "/home/jcline/.virtualenvs/test_requests/lib/python2.7/site-packages/requests/adapters.py", line 447, in send
raise SSLError(e, request=request)
requests.exceptions.SSLError: [Errno 2] No such file or directory

I did some digging and what I concluded is that a when a connection is pulled out of the urllib3 connection pool the CA certificates (maybe even the client certificates?) are not reconfigured on the connection object, so when it goes to validate the server's certificate when it restarts the TCP connection it gets that "No such file or directory" when it tries to read that old CA certificate file.

I thought about this a bit and it may be the case that if you reconfigure the session object with a new CA file and don't delete the old one, you might encounter odd cases where a certificate you expect to pass validation with the new CA bundle fails because the old bundle is actually being used on some of the connections in the pool (but possibly not all of them).

Environment

I encountered this on Fedora 23. I installed requests into a clean virtualenv with pip rather than using the distro-provided packages. I saw this with requests-2.9.1.

Reproducer

I've written up a little script that reproduces this problem. It uses the same CA for both requests, but they are in different files and the CA file used for the first request is deleted.

import os
import tempfile

import requests

# The CA that signed the certificate used at cdn.redhat.com
CA = """
-----BEGIN CERTIFICATE-----
MIIHZDCCBUygAwIBAgIJAOb+QiglyeZeMA0GCSqGSIb3DQEBBQUAMIGwMQswCQYD
VQQGEwJVUzEXMBUGA1UECAwOTm9ydGggQ2Fyb2xpbmExEDAOBgNVBAcMB1JhbGVp
Z2gxFjAUBgNVBAoMDVJlZCBIYXQsIEluYy4xGDAWBgNVBAsMD1JlZCBIYXQgTmV0
d29yazEeMBwGA1UEAwwVRW50aXRsZW1lbnQgTWFzdGVyIENBMSQwIgYJKoZIhvcN
AQkBFhVjYS1zdXBwb3J0QHJlZGhhdC5jb20wHhcNMTAwMzE3MTkwMDQ0WhcNMzAw
MzEyMTkwMDQ0WjCBsDELMAkGA1UEBhMCVVMxFzAVBgNVBAgMDk5vcnRoIENhcm9s
aW5hMRAwDgYDVQQHDAdSYWxlaWdoMRYwFAYDVQQKDA1SZWQgSGF0LCBJbmMuMRgw
FgYDVQQLDA9SZWQgSGF0IE5ldHdvcmsxHjAcBgNVBAMMFUVudGl0bGVtZW50IE1h
c3RlciBDQTEkMCIGCSqGSIb3DQEJARYVY2Etc3VwcG9ydEByZWRoYXQuY29tMIIC
IjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA2Z+mW7OYcBcGxWS+RSKG2GJ2
csMXiGGfEp36vKVsIvypmNS60SkicKENMYREalbdSjrgfXxPJygZWsVWJ5lHPfBV
o3WkFrFHTIXd/R6LxnaHD1m8Cx3GwEeuSlE/ASjc1ePtMnsHH7xqZ9wdl85b1C8O
scgO7fwuM192kvv/veI/BogIqUQugtG6szXpV8dp4ml029LXFoNIy2lfFoa2wKYw
MiUHwtYgAz7TDY63e8qGhd5PoqTv9XKQogo2ze9sF9y/npZjliNy5qf6bFE+24oW
E8pGsp3zqz8h5mvw4v+tfIx5uj7dwjDteFrrWD1tcT7UmNrBDWXjKMG81zchq3h4
etgF0iwMHEuYuixiJWNzKrLNVQbDmcLGNOvyJfq60tM8AUAd72OUQzivBegnWMit
CLcT5viCT1AIkYXt7l5zc/duQWLeAAR2FmpZFylSukknzzeiZpPclRziYTboDYHq
revM97eER1xsfoSYp4mJkBHfdlqMnf3CWPcNgru8NbEPeUGMI6+C0YvknPlqDDtU
ojfl4qNdf6nWL+YNXpR1YGKgWGWgTU6uaG8Sc6qGfAoLHh6oGwbuz102j84OgjAJ
DGv/S86svmZWSqZ5UoJOIEqFYrONcOSgztZ5tU+gP4fwRIkTRbTEWSgudVREOXhs
bfN1YGP7HYvS0OiBKZUCAwEAAaOCAX0wggF5MB0GA1UdDgQWBBSIS6ZFxEbsj9bP
pvYazyY8kMx/FzCB5QYDVR0jBIHdMIHagBSIS6ZFxEbsj9bPpvYazyY8kMx/F6GB
tqSBszCBsDELMAkGA1UEBhMCVVMxFzAVBgNVBAgMDk5vcnRoIENhcm9saW5hMRAw
DgYDVQQHDAdSYWxlaWdoMRYwFAYDVQQKDA1SZWQgSGF0LCBJbmMuMRgwFgYDVQQL
DA9SZWQgSGF0IE5ldHdvcmsxHjAcBgNVBAMMFUVudGl0bGVtZW50IE1hc3RlciBD
QTEkMCIGCSqGSIb3DQEJARYVY2Etc3VwcG9ydEByZWRoYXQuY29tggkA5v5CKCXJ
5l4wDAYDVR0TBAUwAwEB/zALBgNVHQ8EBAMCAQYwEQYJYIZIAYb4QgEBBAQDAgEG
MCAGA1UdEQQZMBeBFWNhLXN1cHBvcnRAcmVkaGF0LmNvbTAgBgNVHRIEGTAXgRVj
YS1zdXBwb3J0QHJlZGhhdC5jb20wDQYJKoZIhvcNAQEFBQADggIBAJ1hEdNBDTRr
6kI6W6stoogSUwjuiWPDY8DptwGhdpyIfbCoxvBR7F52DlwyXOpCunogfKMRklnE
gH1Wt66RYkgNuJcenKHAhR5xgSLoPCOVF9rDjMunyyBuxjIbctM21R7BswVpsEIE
OpV5nlJ6wkHsrn0/E+Zk5UJdCzM+Fp4hqHtEn/c97nvRspQcpWeDg6oUvaJSZTGM
8yFpzR90X8ZO4rOgpoERukvYutUfJUzZuDyS3LLc6ysamemH93rZXr52zc4B+C9G
Em8zemDgIPaH42ce3C3TdVysiq/yk+ir7pxW8toeavFv75l1UojFSjND+Q2AlNQn
pYkmRznbD5TZ3yDuPFQG2xYKnMPACepGgKZPyErtOIljQKCdgcvb9EqNdZaJFz1+
/iWKYBL077Y0CKwb+HGIDeYdzrYxbEd95YuVU0aStnf2Yii2tLcpQtK9cC2+DXjL
Yf3kQs4xzH4ZejhG9wzv8PGXOS8wHYnfVNA3+fclDEQ1mEBKWHHmenGI6QKZUP8f
g0SQ3PNRnSZu8R+rhABOEuVFIBRlaYijg2Pxe0NgL9FlHsNyRfo6EUrB2QFRKACW
3Mo6pZyDjQt7O8J7l9B9IIURoJ1niwygf7VSJTMl2w3fFleNJlZTGgdXw0V+5g+9
Kg6Ay0rrsi4nw1JHue2GvdjdfVOaWSWC
-----END CERTIFICATE-----
"""

# Write two versions of the CA to temporary files. ca1 is used for the first request
# and ca2 is used for the second (after ca1 has been deleted).
fd, ca1_abs_path = tempfile.mkstemp(dir='/tmp/', text=True)
os.write(fd, CA)
os.close(fd)
fd, ca2_abs_path = tempfile.mkstemp(dir='/tmp/', text=True)
os.write(fd, CA)
os.close(fd)

# Make an initial request with the first CA
session = requests.sessions.Session()
session.verify = ca1_abs_path
response = session.get('https://cdn.redhat.com/',
headers={'Connection': 'close'})
print('Got HTTP ' + str(response.status_code) + ' (403 expected)')

# Remove the first CA and configure the session to use the second one.
os.remove(ca1_abs_path)
session.verify = ca2_abs_path

# This is going to end in a "file not found" because the connection needs to be
# re-established by urllib3 and the certificate on the connection is not
# updated to match the certificate on the connection pool.
try:
response = session.get('https://cdn.redhat.com/',
headers={'Connection': 'close'})
print('Got HTTP ' + str(response.status_code) + ' (403 expected)')
except requests.exceptions.SSLError as e:
os.remove(ca2_abs_path)
raise

Issue 2:
Using this code:

import requests
requests.get('https://github.com')

Throws the following exception:

Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/lib/python2.7/site-packages/requests/api.py", line 55, in get
return request('get', url, **kwargs)
File "/usr/lib/python2.7/site-packages/requests/api.py", line 44, in request
return session.request(method=method, url=url, **kwargs)
File "/usr/lib/python2.7/site-packages/requests/sessions.py", line 456, in request
resp = self.send(prep, **send_kwargs)
File "/usr/lib/python2.7/site-packages/requests/sessions.py", line 559, in send
r = adapter.send(request, **kwargs)
File "/usr/lib/python2.7/site-packages/requests/adapters.py", line 382, in send
raise SSLError(e, request=request)
requests.exceptions.SSLError: hostname '<Proxy>' doesn't match either of 'github.com', 'www.github.com'

where is the URL of the http(s)-proxy I'm using. I have set the environment-variables HTTP_PROXY and HTTPS_PROXY (lowercase, too) to that URL. Is it possible to avoid that error without appending verify=False so I don't have to mess with other projects?