How to Import and Export a PFX File in IIS

A PFX file is how Windows moves a certificate and its private key together, as one password-protected file. You export one when you are migrating a site to a new server, building a load-balanced pair, or taking a backup before a renewal. You import one when the certificate was issued somewhere else and has to be installed here.

Both jobs can be done straight from IIS Manager, which is quicker than the Certificates management console most guides send you to. This page covers the IIS Manager route, the PowerShell equivalents, the binding step that actually puts the certificate into service, and the two failures that account for most of the trouble people hit.

What a PFX file is

PFX is the common name for PKCS#12, a binary container that holds the server certificate, any intermediate certificates, and the private key in a single file, encrypted under one password. The extensions .pfx and .p12 mean the same thing.

The reason it exists is that a certificate on its own is useless for serving traffic. The certificate is public, the private key is what proves the server owns it, and Windows keeps the two joined in the certificate store rather than as separate files on disk. PFX is the format that lets that pairing leave one machine and arrive intact on another.

Treat the file accordingly. Anyone who has the PFX and its password has your private key and can impersonate your site. Use a strong password, move it over a channel you trust, and delete it from disk once the import is done.

Export a PFX file

From IIS Manager

1. Press Windows + R, type inetmgr and press Enter to open IIS Manager. Searching the Start menu for “IIS” works too.
2. In the Connections pane, select the server node, not a site. Server Certificates is a server-level feature.
3. Double-click Server Certificates in the middle pane.
4. Select the certificate you want and click Export… in the Actions pane on the right.
5. Choose a path for the .pfx file, set a password, and click OK.

That is the whole export. The file it writes contains the certificate, its chain and the private key.

With PowerShell

Run PowerShell as Administrator. First find the certificate and note its thumbprint:

Get-ChildItem -Path Cert:\LocalMachine\My | Format-List Subject, Thumbprint, NotAfter

Then export it, substituting your own thumbprint:

$pwd = Read-Host -AsSecureString -Prompt "PFX password"
Get-ChildItem -Path Cert:\LocalMachine\My\THUMBPRINTHERE |
    Export-PfxCertificate -FilePath C:\certs\mydomain.pfx -Password $pwd -CryptoAlgorithmOption AES256_SHA256

-CryptoAlgorithmOption is worth adding rather than leaving out. Microsoft documents the default as TripleDES_SHA1, so an export you do not configure protects your private key with Triple DES and SHA-1. AES256_SHA256 is the other accepted value and it is the one to use, with a single exception worth knowing before you migrate: Windows 11 and Windows Server 2019 and later read AES256-SHA256 PFX files, while older releases do not, and Microsoft’s own note is that they fail the import with “The password you entered is incorrect”. If the destination server is Windows Server 2016 or older, that misleading error is the reason, and TripleDES-SHA1 is the documented workaround for that case only. The chain is included automatically: the cmdlet exports “extended properties and the entire chain” unless you ask otherwise with -ChainOption EndEntityCertOnly.

Using Read-Host -AsSecureString keeps the password out of your command history. Examples that build the password with ConvertTo-SecureString -AsPlainText put it in plain text on the command line, which is fine for a lab and a bad habit on a production server.

If the private key will not export

This is the failure that stops most exports, and almost no guide mentions it. A private key in the Windows certificate store carries a flag saying whether it may leave. If that flag was not set when the certificate was installed, then Yes, export the private key is greyed out in the Certificate Export Wizard, IIS Manager’s export produces nothing usable, and Export-PfxCertificate fails.

There is no switch that undoes this. The flag is enforced by the cryptographic provider holding the key, which is the point of it. Your options are to go back to an earlier PFX copy that still had an exportable key, or to reissue the certificate from a fresh key pair and import it correctly this time. Which is exactly why the import step below matters more than it looks.

Import a PFX file

From IIS Manager

1. Open IIS Manager with inetmgr, select the server node, and double-click Server Certificates.
2. Click Import… in the Actions pane.
3. Browse to the .pfx file and enter the password it was protected with.
4. Choose the certificate store. Personal is the right answer for a single site. Web Hosting is designed for servers holding a large number of certificates and keeps them out of the Personal store, which stays readable in the general-purpose tools.
5. Tick Allow this certificate to be exported unless you have a specific reason not to. Microsoft’s wording for the equivalent PowerShell switch is unambiguous: “if this parameter is not specified, then the private key cannot be exported”. Leave the box unticked and you will not be able to move this certificate to another server later.
6. Click OK. The certificate appears in the Server Certificates list.

With PowerShell

$pwd = Read-Host -AsSecureString -Prompt "PFX password"
Import-PfxCertificate -FilePath C:\certs\mydomain.pfx `
    -CertStoreLocation Cert:\LocalMachine\My -Password $pwd -Exportable

Two details decide whether this works the way you expect. -CertStoreLocation must be a LocalMachine path, since IIS serves certificates from the machine store and not from your user store; Cert:\LocalMachine\My is Personal and Cert:\LocalMachine\WebHosting is Web Hosting. And -Exportable is off by default, so an import without it produces a certificate you can never move again.

The cmdlet returns the imported certificate, including its thumbprint, which is what you need for the binding step.

The MMC alternative

The Certificates management console does the same job and is worth knowing for certificates that are not web server certificates. Run certlm.msc to open it directly on the local computer store, which saves adding the snap-in by hand. Expand Personal, then right-click the Certificates folder itself, not a certificate inside it, and choose All Tasks, then Import.

One thing catches people out in the file browser: it filters for X.509 certificate files by default, so your .pfx file is simply invisible until you change the file type drop-down to Personal Information Exchange or to All Files.

Bind the certificate to your site

Importing a certificate does not serve it. Until you attach it to a site binding, nothing changes for visitors. This is the step people skip.

1. In IIS Manager, expand Sites and select the site.
2. Click Bindings… in the Actions pane.
3. If the site already has an https binding, select it and click Edit…. If it does not, click Add….
4. Set Type to https, leave the IP address as All Unassigned unless you have a reason to pin one, and leave the port at 443.
5. Pick your certificate from the SSL certificate drop-down and click OK.

Tick Require Server Name Indication and fill in the Host name field when several sites share one IP address and each needs its own certificate. Server Name Indication is what lets the server pick the right certificate from the host name the client asks for. With a single site on the address you can leave it alone.

Do not restart IIS afterwards. Microsoft’s own walkthrough for setting up SSL goes straight from adding the binding to verifying it, with no restart step in between, and a needless restart on a production web server is an outage you did not have to take.

The PowerShell equivalent, using the thumbprint from the import:

New-IISSiteBinding -Name "Default Web Site" -BindingInformation "*:443:" `
    -Protocol https -CertificateThumbPrint "THUMBPRINTHERE" -CertStoreLocation "Cert:\LocalMachine\My"

-CertStoreLocation accepts Cert:\LocalMachine\My or Cert:\LocalMachine\WebHosting, matching the store you imported into. For the SNI case, put the host name in the binding string and add the flag, as in -BindingInformation "*:443:www.example.com" -SslFlag Sni. The same parameter accepts CentralCertStore, DisableTLS13 and DisableLegacyTLS among others, if you need to control protocol behaviour per binding.

Verify it took effect

An HTTPS binding lives in two places, which is why it can look correct in IIS Manager and still fail. Microsoft describes the split directly: the binding is stored in applicationHost.config for the site, and separately “the SSL configuration associated with the binding is stored in the HTTP.sys configuration”. Check the second one:

netsh http show sslcert

You should see an entry for your IP:port with a certificate hash matching your certificate’s thumbprint and a certificate store name. Microsoft’s own troubleshooting note is the check to run when something is off: “verify that the binding is configured in ApplicationHost.config, and that the HTTP.sys store contains a valid certificate hash and store name for the binding”.

Then confirm from outside the server, which is the only test that reflects what visitors get. Our SSL Checker reports the certificate being served, whether the intermediate chain is complete, and the expiry date. A chain that is complete on the server but incomplete over the wire usually means the PFX was built without its intermediates.

Building a PFX from separate PEM files

Certificate Authorities often deliver a certificate, a chain file and nothing else, because your private key stayed on the machine where you generated the request. If you need a PFX from those pieces, build it yourself with OpenSSL.

Do not use an online converter for this. Building a PFX requires the private key, so uploading the inputs to a third-party website hands your private key to someone else. That is a key compromise, and the correct response to it is to revoke and reissue the certificate, not to hope. Run the conversion locally instead:

openssl pkcs12 -export -out mydomain.pfx -inkey private.key -in cert.crt -certfile chain.crt

OpenSSL prompts for the export password. Include -certfile with the CA bundle: leave it out and you get a PFX with no intermediates, which imports without complaint and then serves an incomplete chain that fails on some clients and not others.

To go the other way and pull the pieces back out of a PFX, for a server that wants PEM files:

openssl pkcs12 -in mydomain.pfx -clcerts -nokeys -out cert.crt
openssl pkcs12 -in mydomain.pfx -cacerts -nokeys -out chain.crt
openssl pkcs12 -in mydomain.pfx -nocerts -nodes -out private.key

The third command writes an unencrypted private key, so protect that file and remove it when you are done. Current OpenSSL builds a PFX using AES-256 with PBKDF2 by default, which current Windows reads without complaint. Very old tooling may not, and -legacy exists for that case, at the cost of falling back to Triple DES and RC2. Reach for it only if an import genuinely fails.

If you do not have OpenSSL on the machine, our guide to installing OpenSSL on Windows covers getting it there.

When the import fails

IIS Manager reports import failures with a message that names only one cause and misses several: Cannot import pfx file. Either you entered wrong password for this file or the certificate has expired. The same import through the Certificates console gives a different and more revealing error: An internal error occurred. This can be either the user profile is not accessible or the private key that you are importing might require a cryptographic service provider that is not installed on your system.

Check the password first, since it really is the most common cause and PFX passwords are usually typed once and never again. If the password is right, Microsoft documents three further causes:

• Insufficient permissions on the MachineKeys folder, where Windows stores machine private keys. Restoring its default permissions resolves it.
• A third-party registry subkey blocking access to the cryptographic provider. If HKEY_USERS\Default\Software\Microsoft\Cryptography\Providers\Type 001 exists, deleting it lets IIS reach the provider again. Back up the registry before touching it.
• A Remote Desktop session whose user profile is not stored on that server. Move the profile to the server or use roaming profiles.

One more worth ruling out early: import the file on any machine you trust with openssl pkcs12 -info -in mydomain.pfx -nokeys. If OpenSSL reads it, the file and password are sound and the problem is on the Windows side.

Frequently Asked Questions

If you are installing a certificate on IIS from scratch rather than moving an existing one, our guide to installing an SSL certificate in IIS covers the request and completion steps. If the site loads but browsers still object, see our guides to common SSL errors.