Converting .crt to .pfx for IIS

At a glance#

• Purpose: Package a PEM-format SSL certificate and private key into a single .pfx file that IIS can import.
• Applies to: IIS on any Windows Server version; certificates issued by any CA.
• Risk: Low — creates a new file, changes nothing on the running server.
• Time: About 10 minutes.

Overview#

Certificate authorities normally issue certificates as separate PEM text files: the certificate itself, a CA bundle of intermediates, and the private key you generated with the CSR. Linux web servers such as Apache and nginx read these files directly.

IIS does not. Windows expects a single PKCS#12 container — a .pfx file — holding the certificate, its intermediate chain and the private key together, protected by a password. This article converts one to the other with OpenSSL.

Before you start#

You need all three files, and they must belong to the same certificate:

You also need OpenSSL. It ships with most Linux systems; on Windows it is included with Git for Windows, or available as a standalone build.

Warning: The private key is the secret that makes the certificate yours. Do the conversion on a trusted machine, and delete any copies of the key and the resulting .pfx from temporary or shared locations once the import is complete.

If you cannot find the private key, you cannot build a .pfx. The certificate will have to be reissued against a new CSR.

Procedure#

1. Confirm the certificate and key actually match#

Do this first. Importing a mismatched pair fails with an unhelpful error in IIS, and the cause is not obvious.

openssl x509 -noout -modulus -in example.com.crt | openssl md5
openssl rsa  -noout -modulus -in example.com.key | openssl md5

Both commands must print the same hash. If they differ, the key does not belong to this certificate — stop and locate the correct key.

2. Convert to PFX#

openssl pkcs12 -export \
  -macalg SHA1 \
  -keypbe PBE-SHA1-3DES \
  -certpbe PBE-SHA1-3DES \
  -out example.com.pfx \
  -inkey example.com.key \
  -in example.com.crt \
  -certfile example.com.ca-bundle

OpenSSL prompts for an export password. Set one — IIS will ask for it during import. Record it in the password manager, not in a text file next to the certificate.

Why the three legacy algorithm flags? OpenSSL 3.x defaults to AES-256 encryption inside the PKCS#12 container. Older Windows versions cannot read that and reject the file with a vague "The password you entered is incorrect" error, even when the password is right. Forcing the older SHA1/3DES algorithms produces a container Windows will always accept.

Note: If the target is Windows Server 2019 or newer, you can drop the three flags and let OpenSSL use its modern defaults, which are cryptographically stronger. Keep them only when the destination is an older server or you are unsure.

Argument reference:

3. Verify the PFX before importing#

openssl pkcs12 -info -in example.com.pfx -noout

Enter the export password when prompted. The output should list your certificate and the intermediates. If only one certificate appears, the -certfile argument was missing or pointed at the wrong file — browsers will then report an incomplete chain.

4. Import into IIS#

1. Copy the .pfx to the Windows server.
2. Open IIS Manager and select the server node in the left-hand tree.
3. Open Server Certificates.
4. In the Actions pane on the right, click Import.
5. Browse to the .pfx, enter the export password, and click OK.

5. Bind the certificate to a site#

1. Select the site in IIS Manager.
2. Click Bindings in the Actions pane.
3. Add (or edit the existing) binding of type https on port 443.
4. Choose your certificate from the SSL certificate list.
5. Click OK, then restart the site.

Verification#

Browse to the site over HTTPS and check the padlock. Confirm the certificate shows the correct common name and expiry date.

To confirm the chain is complete — the most common thing to get wrong — test from outside the network with an SSL checker, or from a Linux host:

openssl s_client -connect example.com:443 -servername example.com

Look for Verify return code: 0 (ok). Anything else usually means a missing intermediate, which sends you back to step 2.

Troubleshooting#

Related#

• Installing a Sectigo SSL Certificate on Self-Hosted GitLab
• SSL Renewal for Zimbra Server