Say I have an X.509 cert and a private key that corresponds to it. I can import X.509 certs easily enough into Windows but what about private keys?

Is the only way I can do that by converting both the cert and the private key to a "Personal Information Exchange (PKCS #12)" file and importing that?

4 Answers 4


The answer to your question is Yes. You must convert the X.509 into a PFX and import it. There is no separate key store in Windows.

You can convert your certificate using OpenSSL with the following command:

openssl pkcs12 -export -out cert.pfx -inkey private.key -in cert.crt -certfile CACert.crt
  • 2
    add winpty in front of it if it hangs on Loading 'screen' into rndom state - if you are on windows git/bash Commented Dec 14, 2016 at 12:05
  • This looks like what I need, however what is cert.crt and what is CACert.crt ? I just have one .key file and one .crt file, and would like to convert that into a .pfx file.
    – RocketNuts
    Commented Dec 7, 2020 at 16:21
  • @k1DBLITZ I see, how/where do I get such a CACert.crt if I don't have one? After purchasing a certificate I just got a cert.crt file (and I have the .key from when I generated the CSR). But I didn't receive any CACert.crt or similar file with that.
    – RocketNuts
    Commented Dec 13, 2020 at 13:14
  • @RocketNuts cert.crt is the public cert. CACert.crt is the trusted chain from the certificate authority. (typically the intermediate and/or root) You can view cert.crt to see if it already contains the trusted chain. If it does, copy out the intermediate and place it in a CACert.crt file. At a bare minimum you must include the intermediate or it is highly likely clients will not trust the certificate
    – k1DBLITZ
    Commented Dec 14, 2020 at 14:44
  • @RocketNuts The vendor for the the certificate will have a page on their site that allows you to download the trusted chain. It can be a tedious process initially, so take your time and make sure you are applying the correct chain. (there are going to be a lot of options) As an example, here are the intermediates for DigiCert: knowledge.digicert.com/generalinformation/INFO4033.html#links
    – k1DBLITZ
    Commented Dec 14, 2020 at 14:51

In Windows, you can have private keys "by themselves". Programmatically, you use CryptAquireContext() to access a key "by name". The CryptoAPI contains many functions which allow you to import and use keys, independently of certificates.

However, there is no existing graphical interface or file format for handling private keys, and applications do not use keys by name. They use certificates. Certificates, in Windows, are stored "elsewhere", but each certificate in the "My" store can optionally contain a link to a corresponding private key (the link would really be a CSP name, and name of a container within that CSP). This maps to what is expected in various protocols. For instance, in SSL, when the server requests a client authentication with a private key, it actually asks for a certificate: the client must present a certificate, and then, only then, demonstrate that it also has access to the corresponding private key.

Thus, in practice, certificates and keys "live together" and keys are reached only through certificates. A certificate and its private key travel together, and this means a PKCS#12 file (aka "PFX").

  • Good answer! I am trying to wrap my head with how Windows handles PFX. Can you please clarify about what you mean by "elsewhere"? And once we've imported the PFX with password, how does Windows "get" the private key everytime it's requested?
    – hendryanw
    Commented Mar 15, 2018 at 8:08
  • 1
    @Hendry The "PFX" is an archive format that contains both the certificate and the private key. In Windows, certificates go into a "certificate store" which is basically in either the user's roaming profile (files in a hidden directory) or the registry. Private keys are handled by a CSP, that will store them, again, somewhere else in the user's roaming profile (or the registry). In the certificate store, the certificate is stored with some extra data, one of which being "there is a private key for that certificate, held by CSP X under name Y", which allows Windows to get the key when needed. Commented Mar 15, 2018 at 14:12

A PKCS12 (*.p12, or *.pfx) is absolutely the easy way. There are quite a few common tools out there for combining a key pair and certificate into a p12. My favorite is OpenSSL, since it works on every OS I've ever needed to use it on and it's reasonably standards compliant. Here's a diverse collection of pages on how, although mileage will vary based upon how your key pair and certificate are currently stored.

Also - most devices with an export capability will offer a PKCS12 generation option if the settings allow key export - its more or less the standard for most PKI enabled applications, and the few cases where this is not the norm (Java for example), there is still usually a conversion or export capability.

One note - if you have a case where your key is on a hardware token or module, you can still reference it from the Microsoft Cert Store - you just need to import the certificate and instruct Microsoft on where the key is stored... to do this, you need to follow the device's instructions for updating the certificate store.

  • 1
    Update: since Java 9 in 2017, the default keystore format is PKCS12 -- albeit Java's version which supports lone certs with no privatekey but with a Java-defined 'bag' attribute. Commented Jul 4, 2019 at 23:30

Pub/priv key pairs should be imported into Windows using a PKCS12 (.p12/pfx) when you're using it as a client certificate. That's all there is to it here...

If you're importing it into IIS that's a bit different, but that doesn't seem to be what you're doing. Just in case - IIS requires a slightly different format than X.509 for its certificates; it requires a PKCS7 instead of generic X.509 because PKCS7 includes the signer certificates, whereas X.509 only has the individual certificate which has been signed. This differs from the typical Apache implemention where the signer certificates are included in a [trusted] cert bundle.

You must log in to answer this question.

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