Export a Certificate with MMC

原文：Export a Certificate with MMC — theDXT (Daniel Keer)

If you work with wild card certificates, it’s common to need to deploy them to more than one server. You will need to export the certificate to install it on other systems.

In this post, I will show you step-by-step how to export a certificate using MMC (Microsoft Management Console), what the export options actually mean, how to check whether the private key on your certificate is even exportable, and how to do the same job with PowerShell when you have more than a couple of servers to handle.

When You Need to Export a Certificate

Exporting is the first half of a two-part operation — the second half is importing it somewhere else, which is covered in Install PFX Certificate in Windows. The situations where this comes up:

• Multiple servers sharing one wildcard. A *.contoso.com certificate protects any number of hosts. Only one server holds the original enrollment; the rest need a copy of the key material.
• Moving a service to a new host. Hardware refresh, or a load-balanced cluster where each node needs its own binding to the same certificate.
• Backing up before expiry. A copy of the PFX is the difference between a routine renewal and an outage on the morning the certificate expires.
• Sharing a self-signed or internal CA certificate with an application team that needs to trust your service.

Note what “export” does and does not mean. Exporting does not remove anything from the source machine — the certificate stays where it is. What you are creating is a portable copy, and if the private key is included, that copy is as sensitive as the certificate it came from.

Export Formats: PFX, CER, and P7B

The wizard offers a format choice on one of the middle pages, and picking the wrong one is the single most common source of “it installed but there is no private key” tickets.

• Personal Information Exchange — PKCS #12 (.PFX, .P12). The only option that can carry the private key, and the only one worth using for the server-to-server case in this post. It is password protected and can hold the whole chain.
• DER encoded binary X.509 (.CER) and Base-64 encoded X.509 (.CER). Public certificate only, no private key. This is what you hand out for trust; it is safe to email.
• Cryptographic Message Syntax Standard — PKCS #7 (.P7B). Public certificates plus the full chain, but no private key. Useful when you specifically want the intermediates to travel with the leaf certificate for a Java keystore or a non-Windows appliance.

If the receiving system needs to terminate TLS, you want PFX. There is no way to add a private key to a CER after the fact — if you exported the wrong format, export again from the original server.

The Process

• Connect to the system that has the certificate you want to export.
• Open MMC. Running certlm.msc directly jumps to the machine certificate store and skips the next three steps; the manual snap-in route is what the wizard-based screenshots below show, and it is the one you need when you are also managing a remote computer's store.
• Add the Certificates Snap-in.

• Select Computer account and click Next.

• Select Local computer and click Finish. If the certificate belongs to a different machine, this is where you select Another computer and browse to it.

• Click OK to close the Add or Remove Snap-ins window.

• Right-click on the Certificate you want to export and click Export. In MMC this is under All Tasks → Export; the certificate needs to be in the Personal store to have a private key to offer.

• Click Next on the Certificate Export Wizard.

• Select if you need to Export the private key and click Next.

Most of the time, you want to export the private key.

Two things to check on that page. First, if Export the private key is greyed out rather than merely unselected, the key is not exportable on this machine and no amount of clicking will change that — see the section below. Second, the format list is empty until you select the private key option, because the private key is the only thing that requires a container format.

• Select the following options for Personal Information Exchange – PKCS #12 (.PFX)

  • Select Include all certificates in the certification path if possible.
  • Select Export all extended properties.
  • Select Enable certificate privacy.

• Click Next.

Why those three boxes matter: Include all certificates in the certification path pulls the intermediates into the file so the destination server can build a chain without extra copying. Export all extended properties preserves attributes such as the friendly name and any custom OIDs, which some applications use for certificate selection. Enable certificate privacy is what actually turns on password protection for the private key — with it cleared, the wizard still writes a PFX, and some environments will accept it, but the key inside is not protected.

If you deliberately untick Enable certificate privacy, the following page is skipped and you get an unprotected PFX. Do not do that for anything with a private key in it.

• Select Password, enter a password, set the Encryption to AES256-SHA256, and click Next.

On the encryption choice: AES256-SHA256 is the correct default and the only sensible option for Windows-to-Windows moves. The alternative, TripleDES-SHA1, exists for backwards compatibility — if the PFX has to be consumed by an older appliance, a Java keystore tool, or a device that predates AES container support, AES will fail to import there and TripleDES is the fallback. Choose AES unless something on the receiving end tells you otherwise, and note that the password you enter here is the password the importing administrator will need; there is no second chance to recover it.

• Select a location to save the PFX certificate export.

• Review the settings and click Finish.

• Click OK to confirm the export was successful.

• You will now find the exported certificate in a PFX file in the location you selected for the export.

With the PFX certificate export, you can install that on other systems as needed.

Exporting with PowerShell Instead

The wizard is fine for one certificate. For anything repeatable, the same job is two lines. First find the certificate and confirm it has an exportable private key:

Get-ChildItem Cert:\LocalMachine\My |
  Select-Object Subject, Thumbprint, NotAfter, HasPrivateKey

# Narrow to the one you want and store its thumbprint
$cert = Get-ChildItem Cert:\LocalMachine\My |
        Where-Object { $_.Subject -like "*contoso.com*" -and $_.HasPrivateKey } |
        Sort-Object NotAfter -Descending |
        Select-Object -First 1
$cert | Select-Object Subject, Thumbprint, NotAfter

Then export it. Export-PfxCertificate produces exactly the same PFX container the wizard does:

$pw = Read-Host -AsSecureString "Password for the new PFX"

Export-PfxCertificate -Cert $cert `
                      -FilePath C:\Certs\wildcard-contoso.pfx `
                      -Password $pw `
                      -ChainOption BuildChain `
                      -CryptoAlgorithmOption AES256_SHA256

For a public-only certificate, or an entire chain without the key, use Export-Certificate instead — it never exports private keys, which makes it safe by construction:

# Leaf certificate only
Export-Certificate -Cert $cert -FilePath C:\Certs\wildcard-contoso.cer -Type CERT

# Full chain, no private key
Export-Certificate -Cert $cert -FilePath C:\Certs\wildcard-contoso.p7b -Type P7B

The parameters mirror the wizard's checkboxes: -ChainOption BuildChain corresponds to Include all certificates in the certification path, and -CryptoAlgorithmOption AES256_SHA256 corresponds to the encryption dropdown. Both cmdlets honour the exportable flag on the key, so a non-exportable certificate fails the same way in PowerShell as it does in the wizard.

When the Private Key Is Not Exportable

If Export the private key is unavailable, the key was created or imported with the exportable flag cleared. This is common with certificates enrolled through a domain CA with a template that sets Allow private key to be exported to false, and with keys generated in a hardware module. Options, in order of preference:

1. Fix the source. For a CA-issued certificate, change the template to allow export and re-enroll, or create a new template that permits it and request a fresh certificate on the server that holds the key. This is the clean answer, and the one to use before a certificate is in production.
2. Re-import on the host that has the key. If the key once came from a PFX on that server, importing it again with the exportable flag set re-creates an exportable instance.
3. Use a different distribution mechanism. Where the private key genuinely must not leave a device — an HSM or a TPM-bound key, which is the point of making it non-exportable — you cannot copy it. Issue a separate certificate per server, or front the service with a load balancer that terminates TLS once.

Never try to work around this with a third-party key-extraction tool on a production certificate. If the design intent was that the key stays put, moving it defeats the control and invalidates whatever compliance story the certificate was part of.

After the Export: Verify and Handle It Carefully

Before shipping the PFX anywhere, prove it is complete. The cheapest check is to import it into a Personal store on a test machine and confirm HasPrivateKey is true and that the chain builds:

# On the destination, during a dry run
Import-PfxCertificate -FilePath C:\Certs\wildcard-contoso.pfx `
                      -CertStoreLocation Cert:\LocalMachine\My `
                      -Password (Read-Host -AsSecureString "PFX password")
Get-ChildItem Cert:\LocalMachine\My | Select-Object Subject, Thumbprint, HasPrivateKey

Then treat the file with the respect it deserves. A PFX containing a private key is a credential: put it somewhere access-controlled, never in a public share or an email thread, and delete the working copy from any temp directory once deployment is done. If the certificate was exported for a project that has finished, delete that PFX too — a forgotten archive of production private keys is a standing risk, and the certificate can be exported again from the source while it is still valid. Log the password somewhere your team can find it, in a password manager rather than a note file next to the PFX.

Two posts worth reading next: the install side of this workflow in Install PFX Certificate in Windows, and what to do when a client rejects the chain afterwards in TLS Certificate Chain Problems: Diagnosing with OpenSSL. If you are replacing a self-signed certificate rather than moving an existing one, the equivalent procedure for an ESXi host is in ESX Regenerate Self-Signed Certificate.

Summary

Run certlm.msc, open the Personal store, right-click the certificate and choose Export. Select Export the private key, keep the PFX format, tick all three path and property options, and set a password with AES256-SHA256 encryption. Then verify the file by importing it once on a test host — an export that silently dropped the key is far easier to catch now than after it has been pushed to every server in the farm.