PFX File Documentation

Summary

A PFX (PKCS #12 Personal Information Exchange) file is an encrypted, password-protected bundle that holds a digital certificate together with its matching private key, and often the CA chain. Its MIME type is application/x-pkcs12 and .pfx is interchangeable with .p12. You do not read a .pfx, you import it: double-click on Windows to run the Certificate Import Wizard, or on macOS to add it to Keychain Access. Keep it secret — it contains a private key.

Technical details

FeatureValue
Full namePKCS #12 Personal Information Exchange File
File extension.pfx, .p12
MIME typeapplication/x-pkcs12
Format typeEncrypted certificate + private-key bundle (binary, DER/ASN.1)
ContainsPrivate key, X.509 certificate, optional CA chain, bag attributes
DeveloperRSA Laboratories (PKCS #12); now IETF
IntroducedPKCS #12 v1.0, 1999 (Microsoft PFX predates and feeds into it)
StandardIETF RFC 7292 (PKCS #12 v1.1); ASN.1 DER encoded
Open standardYes
EncryptionPassword-based (PBE); key and certificates encrypted with the password
IntegrityOptional HMAC (MacData) over the AuthenticatedSafe
Byte orderASN.1 DER (big-endian length encoding)
Magic number30 82 (ASN.1 SEQUENCE, 2-byte length) — shared by many DER objects
Related extensions.p12, .cer, .crt, .pem, .der, .key
Typical useTLS server certs, code signing, client auth, PDF/e-mail signing
SensitivityHigh — contains the private key; never share unprotected
Specificationrfc-editor.org/rfc/rfc7292
File signature (magic bytes)
30 82 xx xx

Offset 0. A PFX is DER-encoded ASN.1, so it opens with the tag byte 0x30 (an ASN.1 SEQUENCE) followed by 0x82, which signals a 2-byte length field (the next two bytes give the total content length). This 30 82 prefix is common to almost every DER-encoded crypto object — X.509 certificates, PKCS keys, PKCS#7 — so it identifies DER, not PFX specifically. The file is not human-readable and must be identified by extension and context, not by the header alone.

What is a PFX file?

PFX (Personal Information Exchange) is Microsoft’s name for a PKCS #12 file: a standardised, encrypted container that bundles a private key with its matching X.509 certificate, and usually the chain of intermediate and root CA certificates, in one portable, password-protected file. The PKCS #12 standard was defined by RSA Laboratories in 1999 and is now maintained by the IETF as RFC 7292 (version 1.1). The extensions .pfx and .p12 name the same format and are interchangeable. Its MIME type is application/x-pkcs12.

The defining feature is that a PFX carries a private key. A bare .cer or .crt holds only a public certificate and is safe to hand out; a PFX holds the secret half of the identity, so anyone with the file and its password can impersonate the owner. That is why you do not “open” a PFX to view its contents the way you open a document. You import it into a certificate store, and from there applications use the installed identity for TLS, code signing, client authentication, or signing PDFs and e-mail.

DER, ASN.1, and the 30 82 header

A PFX is encoded in DER (Distinguished Encoding Rules), the canonical binary form of ASN.1. Every ASN.1 value is written as a tag–length–value triple. The outermost value is a SEQUENCE, whose tag is 0x30, so a PFX begins with the byte 30. The next byte is the length. Because the structure is large, the length uses the long form: 0x82 means “the length itself occupies the next two bytes”, giving the familiar 30 82 xx xx opening.

This prefix is not unique to PFX. The same 30 82 starts DER-encoded X.509 certificates, RSA keys, and PKCS#7 blobs, because they are all ASN.1 SEQUENCEs of similar size. A tool cannot reliably tell a PFX from any other DER object by the first bytes; it has to parse the structure. All length fields are big-endian, and the whole file is binary, so a text editor shows only noise.

The PFX PDU: authSafe and macData

RFC 7292 defines the top-level object, the PFX PDU, as three fields:

PFX ::= SEQUENCE {
    version   INTEGER {v3(3)},   -- always 3
    authSafe  ContentInfo,       -- the actual payload (usually Data)
    macData   MacData OPTIONAL   -- password-based integrity check
}

version is the integer 3. authSafe is a PKCS#7 ContentInfo that wraps the payload. macData is an optional integrity structure: a keyed HMAC computed from a password, a salt, and an iteration count, covering the entire authSafe. It exists so a reader can detect tampering or a wrong password before trusting anything inside.

MacData ::= SEQUENCE {
    mac         DigestInfo,      -- e.g. SHA-256 HMAC value
    macSalt     OCTET STRING,    -- salt fed into key derivation
    iterations  INTEGER DEFAULT 1 -- PBKDF iteration count
}

The MAC and the encryption both derive their keys from the same user password through a password-based key-derivation function, which is why a single password unlocks the file and also verifies its integrity. A high iteration count slows brute-force attacks on the password.

AuthenticatedSafe and the SafeBags

Inside authSafe is an AuthenticatedSafe, a sequence of ContentInfo values. Each one is either plaintext Data, password-encrypted EncryptedData, or public-key EnvelopedData. When encrypted, the plaintext is a SafeContents: a sequence of SafeBags, the individual items the file carries.

AuthenticatedSafe ::= SEQUENCE OF ContentInfo
    -- Data           : unencrypted bag
    -- EncryptedData  : password-encrypted bag (typical for the cert)
    -- EnvelopedData  : public-key-encrypted bag

SafeBag ::= SEQUENCE {
    bagId          OBJECT IDENTIFIER,
    bagValue       [0] EXPLICIT ANY,
    bagAttributes  SET OF PKCS12Attribute OPTIONAL
}

The bag types that matter are the keyBag and pkcs8ShroudedKeyBag (the private key, the second being the encrypted form), the certBag (an X.509 certificate), and crlBag (a revocation list). A typical PFX places the certificate chain in one EncryptedData ContentInfo and the private key, separately shrouded, in another. Bag attributes carry a friendlyName (a human label) and a localKeyId. The localKeyId is the glue: the key bag and its certificate bag share the same value, which is how a reader pairs the private key with the correct certificate when several are present.

Bag typeHolds
keyBagA PKCS#8 private key, unencrypted
pkcs8ShroudedKeyBagA PKCS#8 private key, password-encrypted (the usual case)
certBagAn X.509 certificate (end-entity or CA)
crlBagA certificate revocation list
secretBag / safeContentsBagArbitrary secret data, or a nested SafeContents

Importing rather than opening

Because the payload is encrypted and the private key is sensitive, a PFX is designed to be imported into an operating-system certificate store, not displayed. On Windows the file is associated with the Certificate Import Wizard: double-click, enter the export password, and choose a store (Personal for the current user, or Local Machine for a service). PowerShell (Import-PfxCertificate, Get-PfxData) and certutil -dump file.pfx do the same from a shell. On macOS a double-click adds the identity to Keychain Access. On Linux the file is imported into GNOME Keyring / Seahorse, or split with OpenSSL for a web server.

On the command line, OpenSSL is the standard tool for inspecting and unpacking a PFX. Extracting the parts is the most common server task:

# everything (key + certs) into one PEM, key left unencrypted
openssl pkcs12 -in file.pfx -out out.pem -nodes

# just the certificate, no key (safe to share)
openssl pkcs12 -in file.pfx -clcerts -nokeys -out cert.pem

# just the private key
openssl pkcs12 -in file.pfx -nocerts -nodes -out key.pem

Each command prompts for the export password before it can decrypt the bags. The resulting PEM files are what Apache and Nginx consume; the .crt/.cer split is how you distribute the public certificate without ever exposing the key.

Is a PFX file safe? Handling the private key

A PFX is not executable, so opening one cannot run code. The danger is the opposite: the file is one of the most sensitive things a person handles, because it contains a private key. Anyone who obtains the file and its password can sign code or documents as the owner, or stand up a server presenting the owner’s TLS identity. Three consequences follow. First, never e-mail a PFX unprotected and never commit one to source control; a leaked PFX is a leaked identity. Second, use a strong export password, since the entire security of the file rests on the password-based encryption of the key bag: a weak password can be brute-forced offline against the MAC. Third, prefer trusted local tools (the OS wizards, OpenSSL) over “certificate viewer” websites, which could exfiltrate both the key and the password you type. Treat an unexpected .pfx attachment as suspicious, and if you lose the password there is no legitimate recovery: the key is encrypted with it, and you must re-export or reissue the certificate.

References