From the documentation:

requests can also ignore verifying the SSL certificate if you set verify to False.

>>> requests.get('https://kennethreitz.com', verify=False)
<Response [200]>

If you're using a third-party module and want to disable the checks, here's a context manager that monkey patches requests and changes it so that verify=False is the default and suppresses the warning.

import warnings
import contextlib

import requests
from urllib3.exceptions import InsecureRequestWarning

old_merge_environment_settings = requests.Session.merge_environment_settings

@contextlib.contextmanager
def no_ssl_verification():
    opened_adapters = set()

    def merge_environment_settings(self, url, proxies, stream, verify, cert):
        # Verification happens only once per connection so we need to close
        # all the opened adapters once we're done. Otherwise, the effects of
        # verify=False persist beyond the end of this context manager.
        opened_adapters.add(self.get_adapter(url))

        settings = old_merge_environment_settings(self, url, proxies, stream, verify, cert)
        settings['verify'] = False

        return settings

    requests.Session.merge_environment_settings = merge_environment_settings

    try:
        with warnings.catch_warnings():
            warnings.simplefilter('ignore', InsecureRequestWarning)
            yield
    finally:
        requests.Session.merge_environment_settings = old_merge_environment_settings

        for adapter in opened_adapters:
            try:
                adapter.close()
            except:
                pass

Here's how you use it:

with no_ssl_verification():
    requests.get('https://wrong.host.badssl.example/')
    print('It works')

    requests.get('https://wrong.host.badssl.example/', verify=True)
    print('Even if you try to force it to')

requests.get('https://wrong.host.badssl.example/', verify=False)
print('It resets back')

session = requests.Session()
session.verify = True

with no_ssl_verification():
    session.get('https://wrong.host.badssl.example/', verify=True)
    print('Works even here')

try:
    requests.get('https://wrong.host.badssl.example/')
except requests.exceptions.SSLError:
    print('It breaks')

try:
    session.get('https://wrong.host.badssl.example/')
except requests.exceptions.SSLError:
    print('It breaks here again')

Note that this code closes all open adapters that handled a patched request once you leave the context manager. This is because requests maintains a per-session connection pool and certificate validation happens only once per connection so unexpected things like this will happen:

>>> import requests
>>> session = requests.Session()
>>> session.get('https://wrong.host.badssl.example/', verify=False)
/usr/local/lib/python3.7/site-packages/urllib3/connectionpool.py:857: InsecureRequestWarning: Unverified HTTPS request is being made. Adding certificate verification is strongly advised. See: https://urllib3.readthedocs.io/en/latest/advanced-usage.html#ssl-warnings
  InsecureRequestWarning)
<Response [200]>
>>> session.get('https://wrong.host.badssl.example/', verify=True)
/usr/local/lib/python3.7/site-packages/urllib3/connectionpool.py:857: InsecureRequestWarning: Unverified HTTPS request is being made. Adding certificate verification is strongly advised. See: https://urllib3.readthedocs.io/en/latest/advanced-usage.html#ssl-warnings
  InsecureRequestWarning)
<Response [200]>

I'm new to this, so any help would be greatly appreciated

This is actually an issue were not only newbies despair. The issue is complex and depends on specific implementations and bugs in the TLS libraries involved. Thus it is not really your fault that it does not work as expected. I hope the following explanation can be understood:

There are actually several trust path to a trusted certificate. What the server sends as certificates is this:

#0 CN=www.google.com SAN=DNS:www.google.com
#1 CN=Google Internet Authority G2
#2 CN=GeoTrust Global CA

The last certificate is signed by #3 OU=Equifax Secure Certificate Authority which is not included in the chain sent by the server.

The NSS library used in Chrome and Firefox starts at the top and checks for each certificate if it can find a trusted CA which signed this certificate, i.e. a certificate which exists in the local trust store. It will stop with the validation at certificate #1, because it has a local certificate for GeoTrust Global CA which can be used to validate certificate #1. Thus it is done with validation and ignores certificate #2.

OpenSSL up to version 1.0.1 (at least up to 1.0.1p) works different. It will look at the whole chain and try to find a trust anchor for the last certificate in the chain. Since often servers send the root certificate inside the chain (which is wrong) it will eliminate all self-signed certificates from the chain before it will look for the trust anchor (since root certificates are usually self-signed).

In this case the certificate #2 for "GeoTrust Global CA" is not a self-signed certificate (signed by Equifax) and will not be removed. It will thus try to find the issuer for this certificate #2 "GeoTrust Global CA" in the trust store to built the trust chain. If you included the certificate #3 (Equifax) in the trust store (file name in verify parameter) then all is fine and the validation succeeds. If you only include the "GeoTrust Global CA" in the trust store the validation fails because this is not the correct trust anchor for certificate #2. OpenSSL 1.0.1 is too dumb to realize that this would be the perfect trust anchor for certificate #1 and thus the validation fails.

The situation was changed finally (more than 3 years after I reported this kind of bug) in OpenSSL 1.0.2. If the first attempt to validate the chain fails it will remove the last certificate from the chain (certificate #2) and retry. In this case it will succeed. That means if you would use a version of Python built with OpenSSL 1.0.2 then it should be fine. For more details about the different ways of validating the trust path see the last comment at OpenSSL bug#3621.

Before coming to the different values for verify one needs to understand first, what this verify is about in the first place. It is about validating that the server certificate matches the expected one, which means that there is a direct end-to-end protected connection to the server and there is not some man in the middle who can read and modify the traffic. The server validation is (among other things) based on locally trust root certificates which represent trusted certificate authorities (CA): if no chain from the server provided leaf certificate to any of the local trust anchors can be constructed, then the certificate is not trusted. For more on this see SSL Certificate framework 101: How does the browser actually verify the validity of a given server certificate?.

verify=True then means that the server validation is done to use the default trust anchors, which are commonly the same public root certificates as used in the browser. verify=file.pem means to not use the default trust anchors but instead only the ones given in the specific file. This can be a single CA certificate, can be multiple CA certificates but can also be self-signed certificates expected for a specific server. Both of these options are usually sufficiently secure. But explicitly specifying which CA or certificate is trusted with verify=file.pem is more restrictive and thus more secure.

verify=False instead means that no certificate validation is done at all. This means a man in the middle will not be detected and thus anybody in the middle could sniff and fiddle with the traffic. This is totally unsafe and should never be used for critical data.. Critical data are obviously things like passwords or access tokens, but even exposing the exact URL visited can be considered critical in many cases.

Try:

r = requests.post(url, data=data, verify='/path/to/public_key.pem')