In this age of high-level languages, why do I still have to worry about this? I don't mean 'security' I mean 'managing certificates.' My local framework/API should complain if I don't have a trusted root and should then make it dead simple to provide that root.
Because during most of the development cycle when these libraries are being used, the certificates aren't validating (they're dev/test/UAT systems) --- and so during actual development, certificate verification seems like just another annoying obstacle to clear as quickly as possible.
It's easy enough to generate a snakeoil cert and use its public part as your cert bundle. On Debian/Ubuntu, just install the ssl-cert package, and point to /etc/ssl/certs/ssl-cert-snakeoil.pem as your certificate bundle; the private key is at /etc/ssl/private/ssl-cert-snakeoil.key .
Or just serve your app/API/etc from different urls, plain HTTP for development and HTTPS for preprod and production.
That's exactly how it works in C# (.NET in general), and I would take a fairly large bet that's exactly the same in Java. It seems like a regression (when thinking on terms of lower level --> higher level language movement).
Security is something that should just work - arguably, the first thing with such requirement. Even though it simply can't just work in many cases, it should be as close to just-working as it can.
However, this isn't exposed in the higher-level httplib.HTTPSConnection class for some reason. I'd bet it's not too hard to write your own subclass to handle it though.
In Python, a sufficiently recent httplib2 will require valid certificates by default; same with the requests library. Both let you use your own cert bundle, as a quick-and-dirty way to do certificate pinning. That's reason enough to discourage the use of Python's standard library for http requests (another reason is that it's quite low-level).
