What is PKCS (PKCS#7, PKCS#11, PKCS#12)

PKCS (Public Key Cryptography Standards) is a family of standards originally published by RSA Laboratories that define formats and interfaces for cryptographic operations. Despite the name, they cover far more than public key crypto — they define how certificates are bundled, how applications talk to HSMs, how CSRs are formatted, and how encrypted messages are structured. You encounter PKCS standards constantly in PKI operations, even if you don’t realize it: every CSR is PKCS#10, every PFX file is PKCS#12, and every HSM uses PKCS#11.

Why it matters

• Interoperability — PKCS standards ensure that a certificate exported from one system can be imported into another. Without PKCS#12, moving a certificate+key between Windows and Linux would require custom tooling.
• HSM abstraction — PKCS#11 provides a standard API so your CA software, TLS library, or application can use any HSM vendor’s hardware without code changes. Switch from Thales to Entrust? Same PKCS#11 calls.
• Certificate enrollment — PKCS#10 defines the CSR format that every CA accepts. Whether you use ACME, EST, SCEP, or manual enrollment, the CSR is PKCS#10.
• Secure transport — PKCS#7/CMS wraps certificates and signed data for transport. SCEP uses PKCS#7 envelopes. S/MIME email uses PKCS#7. Certificate chains are often distributed as PKCS#7 files.
• Key protection — PKCS#12 bundles the private key with the certificate, protected by a password. This is how keys are transported between systems when HSM-to-HSM transfer isn’t available.

How it works

PKCS#10 (Certificate Signing Request):

• Contains: subject name, public key, requested extensions, self-signature (proof of key possession)
• Used: every certificate enrollment — client generates CSR, sends to CA
• Format: ASN.1 DER, typically PEM-encoded with -----BEGIN CERTIFICATE REQUEST-----

PKCS#7 / CMS (Cryptographic Message Syntax):

• Contains: certificates, CRLs, signed data, or encrypted data
• Used: certificate chain distribution, S/MIME, code signing, SCEP messages
• Format: ASN.1 DER, file extensions .p7b, .p7c, .p7s
• Does NOT contain private keys

PKCS#11 (Cryptoki — Cryptographic Token Interface):

• Defines: C API for accessing cryptographic tokens (HSMs, smart cards, TPMs)
• Used: CA software signing with HSM keys, TLS libraries offloading crypto to hardware
• Not a file format — it’s a programming interface (shared library / DLL)

PKCS#12 / PFX (Personal Information Exchange):

• Contains: private key + certificate + chain, password-encrypted
• Used: importing certificates into IIS, Java keystores, browsers, mobile devices
• Format: binary, file extensions .pfx, .p12
• The only standard format that bundles private key with certificate

In real systems

PKCS#10 — generating a CSR:

openssl req -new -key server.key -out server.csr \
  -subj "/CN=api.example.com/O=My Org" \
  -addext "subjectAltName=DNS:api.example.com,DNS:api-internal.example.com"

# View CSR contents
openssl req -in server.csr -noout -text

PKCS#12 — bundling for IIS/Java:

# Create PFX from PEM files
openssl pkcs12 -export \
  -in cert.pem \
  -inkey key.pem \
  -certfile chain.pem \
  -out certificate.pfx \
  -passout pass:MyPassword

# Import into Java keystore
keytool -importkeystore \
  -srckeystore certificate.pfx -srcstoretype PKCS12 \
  -destkeystore keystore.jks -deststoretype JKS

PKCS#11 — using HSM with OpenSSL:

# Sign with HSM-stored key via PKCS#11 engine
openssl dgst -engine pkcs11 -keyform engine \
  -sign "pkcs11:token=MyHSM;object=ca-key;type=private" \
  -sha256 -out signature.bin document.pdf

# Nginx with HSM via PKCS#11 (OpenSSL engine)
ssl_certificate_key "engine:pkcs11:token=HSM;object=server-key;type=private";

PKCS#7 — extracting certificates from a chain file:

# Convert PKCS#7 chain to individual PEM certificates
openssl pkcs7 -in chain.p7b -print_certs -out certs.pem

# Create PKCS#7 from PEM certificates
openssl crl2pkcs7 -nocrl -certfile cert.pem -certfile intermediate.pem -out chain.p7b

Where it breaks

PKCS#12 password encoding — PKCS#12 files use a password for encryption, but the password encoding differs between implementations. OpenSSL uses UTF-8, Windows uses UTF-16LE, and some Java versions use ASCII. A PFX created with OpenSSL using special characters in the password may fail to import on Windows (or vice versa). Stick to ASCII passwords for PFX files that cross platforms.

PKCS#11 library compatibility — your CA software expects PKCS#11 v2.40, but the HSM vendor’s library implements v2.20. Or the library works on Linux but the Windows DLL has different behavior for the same calls. PKCS#11 is a standard, but vendor implementations have quirks. Always test the specific HSM library version with your specific CA/TLS software before production deployment.

PKCS#7 chain order — a PKCS#7 file contains multiple certificates but doesn’t enforce order. Some implementations expect end-entity first, then intermediates. Others expect root first. When importing a PKCS#7 chain, the receiving system may not correctly identify which certificate is the end-entity vs. intermediate, leading to chain assembly errors. Extract to individual PEM files and assemble the chain explicitly.

Operational insight

The most common PKCS-related operational pain is PKCS#12 key export from HSMs. FIPS 140-2 Level 3 HSMs are designed to prevent key extraction — that’s their purpose. But when you need to migrate a CA to new hardware, or deploy the same key to a non-HSM system, you discover the key can’t be exported as PKCS#12. The only options: HSM-to-HSM key transfer (vendor-specific, often requires both HSMs to be the same model), key ceremony with backup tokens (planned at key generation time), or generating a new key and re-issuing all certificates. Plan your key backup and migration strategy at HSM deployment time, not when you need to move.

Related topics

• What is X.509
• What is FIPS 140-2/140-3
• Certificate Enrollment
• What is a Certificate Authority
• What are Hardware Security Modules