What kind of private key is located in a PKC12 pfx file?

Question

Can anybody clarify to me what kind of "Private Key" is located in a PFX file ?

I am asking this because after having read quite a lot on digital certification I am still a bit confuse on the Private Key part, especially when Certificate Authority is involved.

The part I am missing is where it is said that the Private Key is kept secret on the CA side but if I go in my Personal Certificate Store and I try to export a certificate, I am able to export it with the private key in it.

Is this private key is the same as THE private key that we are not supposed to know ?

Answer 1

If you are talking about SSL-Certificates and SSL I think you mean X509-Certificates in common. Let me make it clear first: the passwords of the private keys are different.

The magic here is Chaining of the Certificates, i.e.

• Root Certificate from CA
  • Intermediate Certificate from CA (for instance Class 2)
    • Your Certificate

If you look at your SSL-Certificate, you will find this structure. Every certificate within this hierarchy can be seen as a certificate for its own. You can find more information within this msdn article. A briefly description from my point of view:

The Certifcates within this chain can be seen are separate Certificates. With their own ability to sign Information with the private key and validating signature with their private key. They are basically linked within this chain.

You might ask Why are the Certificates linked?

There are two main reasons: Security and Trust.

If you loose your private key or if your certificates is broken, it's need to be revocated. This basically says, that your Certificates should not be trusted anymore. It's listed on the Revocation-List on the parent Certificate to ensure that this security break can be fixed very fast. This behavior explains, why root certficates creating IntermediateCertificates and not your requested Certificate - they want to be sure that they can revocate their Intermediate Certificate as well.

Additionally to this functional explanation there is a mathematical, but I am not able to explain this is an easy way. You can find Information about this within it's article on Wikipedia. Basically it says, that you can't calculate the password from the parent and / or public certificate to use the private certificate.

Answer 2

Public key cryptography is used for two different purposes when it comes to X.509 certificates used for SSL/TLS.

Each X.509 certificate contains a public key, which has a matching private key held only by the identity this certificate belongs to (the subject of the certificate).

• One of the purposes is to build trust in another certificate. A CA uses its private key to sign other certificates: possibly other (intermediate) CA certificates or End-Entity Certificates (the ones that are actually going to be used for the SSL/TLS connection itself).

  For example, the Root CA's private key can be used to sign (i.e. issue) an Intermediate CA's certificate. The Intermediate CA certificate can be verified using the Root CA certificate's public key. The Intermediate CA's own key-pair isn't involved in this verification (although the verification process ensures that the public key in that cert belongs to the Intermediate CA).

  The Intermediate CA's private key can be used to sign your server certificate (an EEC). The Intermediate CA's public key can be used to verify the authenticity of your server certificate. Someone who would only have the Root CA certificate can therefore check your server certificate by building a chain. Again, your server public and private keys are not involved in this verification at all, but the result of these operations proves that the public key in your server certificate belongs to your server name.

  There is no relationship between any of the key pairs involved in a certification chain. Even the CA issuing a certificate will not (or should not) have access to the private key of the certificate it is issuing.

• The second usage of public key cryptography is during the SSL/TLS handshake. The exact mechanism depends on the cipher suite, but this allows the client to agree with the server on a secret that only the server with the private key matching the public key in the server certificate will be able to see. It's this private key that is the private key of the certificate itself.

In a PKCS#12 file, you will find an End-Entity Certificate and the private key matching the public key in that certificate, to be used by the entity to which this certificate was issued, and generally a chain of CA certificates (from the one directly issuing the EEC to other CA certificate further up the chain, possibly up to a Root CA).

Here, I've taken this example of an EEC for an SSL/TLS server, but the same could apply for EEC to be used in other contexts (e.g SSL/TLS client or S/MIME).