In my company, we are issued .p12 files and extract the certificate and private key like so:

openssl pkcs12 -in path.p12 -out newfile.crt.pem -clcerts -nokeys
openssl pkcs12 -in path.p12 -out newfile.key.pem -nocerts -nodes

These are now in PEM format, and when making any call to a web service, we must send the credentials like so:

with requests.Session() as s:
    s.cert = (cert_file_path, key_file_path)
    r = s.get(some_url, verify=False)

As I understand it, the CA generates a certifcate (and public key) along with the corresponding private key and packages these in a .p12 file. The certificate is signed using the CA's private key, such that when sent, the certificate is proof that I am who I say I am as a trusted user. But why do I send the private key? Shouldn't that be kept on my system?


1 Answer 1


You don't send the private key, your software will use the private key to prove that you are the legitimate holder of that certificate.

Metaphor: physical driver's licenses instead of certificates. Imagine you get your hands on someone else's driver's license (or a copy of it). That's ok because it's a photo ID, the person you present the driver's license to will check that you match the photo.

Certificates work the same way, except that instead of a photo, the certificate contains a public key, and you need to create a digital signature using the matching private key in order to prove that you are the legitimate holder of that certificate.

See our canonical answer:

  • 1
    Oh, so its similar to this (which I just discovered), in which the certificate is sent to the server, then at some point the client's private key is used to sign something that is sent back to the server at which point the server uses the public key to verify it against.
    – pstatix
    Commented Oct 29, 2020 at 21:13
  • @pasta_sauce Yes! Exactly! In fact more that being similar to that, but it is that. Commented Oct 30, 2020 at 0:30

Not the answer you're looking for? Browse other questions tagged .