Message231001
I think I was getting mixed results by using requests and urllib2/3. After nearly being driven crazy, I performed the following steps:
1. Recreated client certificates, and verified that the correct CA was being used from Nginx.
2. Experimenting using an SSL-wrapped client-socket directly, in tandem with s_client.
3. I then removed all of my virtualhosts except for a new one that pointed to a flat directory, just to make sure that I wasn't activating the wrong virtualhost, and there weren't any other complexities.
4. Implemented a bonafide, signed, SSL certificate on my local system, and overriding the hostname using /etc/hosts.
5. This got me past the 400. I switched back to using my local hostname with my self-signed certificate, and told wrap_socket to not verify (at this point, I stopped checking with s_client).
6. I started reactivating all of my normal virtualhost includes, one include at a time.
7. Reverted back to using the standard, proprietary client, and verified that it worked.
I'm guessing that a) something happened to my original certificates, b) I might've had an incorrect CA certificate for authentication, and/or c) I had added a default virtualhost on the non-standard port that I am using that always returns Forbidden, and this might've been unexpectedly catching the wrong requests.
Since I verified my client certificates against my internal issuer in the beginning, I don't think it's (a) or (b).
I could've done without these problems. I can't even say what started it all. |
|
Date |
User |
Action |
Args |
2014-11-11 06:50:53 | dsoprea | set | recipients:
+ dsoprea, pitrou, r.david.murray, Dustin.Oprea |
2014-11-11 06:50:53 | dsoprea | set | messageid: <1415688653.54.0.978686180241.issue22835@psf.upfronthosting.co.za> |
2014-11-11 06:50:53 | dsoprea | link | issue22835 messages |
2014-11-11 06:50:52 | dsoprea | create | |
|