Document Encryption Certificates for BIOS Password Management

The CMS method described in Securing BIOS Passwords relies on a document encryption certificate. The BIOS password is encrypted to that certificate’s public key, and only devices holding the matching private key can decrypt it. This post is a companion to that one. It covers how to create and manage the certificate itself: choosing between a self-signed certificate and one issued from an enterprise PKI, and handling the full lifecycle from creation through distribution, rotation, and removal.

How the certificate is used

Before getting into the options, it helps to be clear about what this certificate actually does, because it is not used the way a typical certificate is.

CMS (Cryptographic Message Syntax) uses the certificate purely as an RSA key pair. Protect-CmsMessage encrypts the password to the public key, and Unprotect-CmsMessage decrypts it with the private key. That is the entire relationship. The certificate is a key container, not an identity.

Important

This means CMS does not validate a trust chain, an expiration date, or revocation. The certificate does not need to chain to a trusted root, it does not need to be “trusted” by the device, and decryption keeps working even after the certificate has expired. That one fact drives most of the decisions in this post, so it is worth keeping in mind throughout.

Self-signed or enterprise PKI?

Because CMS ignores trust and revocation, a self-signed certificate decrypts exactly as securely as one issued by a certificate authority. The choice between them is about operations and governance, not cryptographic strength.

Enterprise PKI is the better choice for production fleet use if you already run AD CS. The payoff is operational: the CA tracks issuance and expiry, the template enforces the correct key size, EKU, and other parameters every time, and issuance is logged and auditable. Two of the usual PKI benefits do not really apply here though. Revocation does nothing for CMS, and auto-renewal does not help because you distribute a static copy of the private key to the fleet, so renewing on the source does not reach the devices.

Self-signed is perfectly fine for labs, testing, small environments, or anywhere you do not have (or do not want to involve) a PKI. It is one command and has no dependencies. The trade-off is that you own the entire lifecycle manually; tracking expiry, recreating the certificate, and getting the parameters right by hand.

The rest of this post covers both. The creation step differs, but everything after it (export, distribution, rotation, removal) is the same.

What the certificate needs

However you create it, the certificate has to have:

• Enhanced Key Usage: Document Encryption (OID 1.3.6.1.4.1.311.80.1). The CMS cmdlets require this EKU.
• Key Usage: Key Encipherment (and Data Encipherment). CMS uses RSA key transport.
• Key algorithm: RSA, 2048-bit or larger. The CMS cmdlets will not use an ECC key for this.
• An exportable private key. The whole model is one certificate whose private key is exported and distributed to the fleet, so the key must be exportable at creation time.

Option 1 - Create a self-signed certificate

A single command on an admin workstation produces a certificate with all of the required properties:

$cert = New-SelfSignedCertificate -Subject "CN=BIOS Password Encryption" `
    -KeyUsage KeyEncipherment,DataEncipherment -Type DocumentEncryptionCert `
    -CertStoreLocation Cert:\CurrentUser\My -KeyExportPolicy Exportable

-Type DocumentEncryptionCert sets the Document Encryption EKU and the appropriate key usage for you. The default key is RSA 2048. Skip ahead to Export the certificate below.

Option 2 - Issue the certificate from an enterprise PKI

There is no built-in Document Encryption template, so you duplicate one and configure it.

Create the template. On a machine with the Certificate Templates console (certtmpl.msc):

1. Right-click any existing template and choose Duplicate Template (the base does not matter, you will override the relevant settings).
2. Compatibility: set the CA and recipient to your environment’s minimum. Only your admin workstation enrolls this certificate, so you can set it fairly high.
3. General: give it a name, set a validity period (see the expiration section below), and uncheck Publish certificate in Active Directory.
4. Cryptography: Provider Category = Key Storage Provider; Algorithm = RSA; minimum key size 2048 or larger; request hash SHA256.
5. Request Handling: Purpose = Encryption, and check Allow private key to be exported.
6. Extensions - Application Policies: edit the list, remove what is there, and add Document Encryption.
7. Extensions - Key Usage: Key Encipherment and Data Encipherment; clear the signature usages.
8. Subject Name: Supply in the request, so you can set a fixed common name.
9. Security: grant Read and Enroll to your own admin account or group only. Do not configure Autoenroll, and do not scope it to the device fleet. The devices never enroll this certificate, they receive the exported private key.

Then publish it: in the Certification Authority console (certsrv.msc), expand the CA, right-click Certificate Templates, and choose New > Certificate Template to Issue, then select the new template.

Enroll the certificate. On a secured admin workstation that can reach the CA, open certlm.msc, go to Personal, and choose All Tasks - Request New Certificate. Select the new template, supply a common name such as BIOS Password Encryption when prompted, and enroll. If your CA requires manager approval for supply-in-request templates, the request will go pending - issue it from the Certification Authority console.

Export the certificate

From this point the process is the same for both options. You need two files: the public key for encrypting passwords, and the private key for the devices.

# Locate the certificate (adjust the store and subject to match where you created it)
$cert = Get-ChildItem Cert:\CurrentUser\My |
    Where-Object { $_.EnhancedKeyUsageList.ObjectId -contains '1.3.6.1.4.1.311.80.1' -and $_.Subject -eq 'CN=BIOS Password Encryption' }

# Public key - used to encrypt passwords (safe to share)
Export-Certificate -Cert $cert -FilePath .\BiosEnc.cer

# Private key - what the devices need (protect this file)
$pfxPw = Read-Host -AsSecureString -Prompt 'PFX password'
Export-PfxCertificate -Cert $cert -FilePath .\BiosEnc.pfx -Password $pfxPw

The .pfx is the sensitive file. Give it a strong export password, keep it in a restricted location, and lifecycle-manage it.

Distribute the private key to devices

The goal is for every target device to have the certificate and its private key in Cert:\LocalMachine\My, so the management script (running as SYSTEM) can decrypt at runtime. The import command, run elevated or as SYSTEM:

Import-PfxCertificate -FilePath .\BiosEnc.pfx -CertStoreLocation Cert:\LocalMachine\My -Password $pfxPw

Import-PfxCertificate imports the key as non-exportable by default, which is what you want on devices - the fleet copy cannot then be re-exported off the machine. Do not add -Exportable.

Deliver the .pfx and that import step using whatever you already use for content and scripts:

• Configuration Manager - a package, application, or a “Run PowerShell Script” step that drops the file and runs the import.
• Intune - a Win32 app or a platform script that does the same.
• A task sequence step or startup script - the same import, running as SYSTEM.

Caution

One method that does not work for this is Group Policy. GPO can deploy public certificates to the Trusted Root or Trusted People stores, but it cannot deploy a .pfx with a private key into Cert:\LocalMachine\My. Use one of the options above for the private key.

Note that the import step has to supply the .pfx password, so that password lives in your deployment content, keep it restricted. It only protects the file in transit; once imported, the key is in the protected machine store.

If you run any of this in WinPE, the certificate and private key have to be present in the WinPE certificate store. See the key custody section of Securing BIOS Passwords for details.

Encrypt a password and use it

With the public key in hand and the private key on the devices, encrypt the password once and use it with the scripts. This is covered in more detail in Securing BIOS Passwords, but in short:

# Once, on the admin workstation - encrypt the BIOS password to the public key
Protect-CmsMessage -To .\BiosEnc.cer -Content 'TheBiosPassword' -OutFile .\BiosPw.cms

# On the device (as SYSTEM) - the script finds the private key and decrypts in memory
Manage-LenovoBiosSettings.ps1 -SetSettings -SupervisorPasswordCmsFile .\BiosPw.cms

The .cms file is ciphertext and is safe to store alongside your content.

Certificate expiration

Note

An expired certificate does not break decryption. CMS matches the recipient by issuer and serial number and uses the private key directly - it never checks the certificate’s expiration date. A device whose certificate has expired will keep decrypting .cms files without any issue. (In current Windows builds, Protect-CmsMessage will even keep encrypting to an expired certificate.)

So expiration is not a runtime cliff. It is really a prompt to rotate, and a flag that audit and compliance tooling will raise, rather than something that stops the scripts from working.

That also changes the usual “shorter is more secure” calculation. For an identity or TLS certificate, a short validity period limits how long a stolen key is useful, because expiration and revocation eventually cut it off. That mechanism does not apply here. A leaked private key decrypts any .cms file it can reach regardless of the certificate’s expiration, and CMS ignores revocation. The only thing that neutralizes a compromised key is to rotate it and re-encrypt. A very short validity period therefore buys little security while forcing a fleet-wide redistribution every time it lapses.

My recommendation is to size the validity period to a rotation cadence you will actually keep, rather than to the smallest number you can pick. Two to three years is a reasonable default, aligned with your BIOS password rotation policy. One year is fine if your security policy calls for tighter cycling. I would avoid sub-annual lifetimes here, since they create repeated redistribution work without the compromise-window benefit they would provide a TLS certificate.

Rotating the certificate

It is worth separating two things that both get called “rotation”:

• Rotating the BIOS password does not require a new certificate. Just re-encrypt the new password to the existing certificate with Protect-CmsMessage and ship the new .cms file.
• Rotating the certificate is needed when it is nearing expiration or when the private key may have been exposed. Issue a new certificate, re-encrypt your passwords to it, distribute the new .pfx to the devices, and once every device has the new key and all .cms files have been re-encrypted, remove the old certificate (next section).

If you are rotating because of a suspected key compromise, also change the BIOS password itself. The old password may have been exposed along with the key, and re-encrypting an unchanged password to a new certificate does not help if the password is already known.

Removing the certificate

Once a certificate is retired and nothing depends on it any longer, clean it up.

On the devices, remove the old certificate from the machine store (run as SYSTEM, after the replacement is in place):

Get-ChildItem Cert:\LocalMachine\My |
    Where-Object Thumbprint -eq 'OLD_CERT_THUMBPRINT' |
    Remove-Item

On the source side, securely delete any exported .pfx and .cer files you no longer need, and remove the certificate from the admin workstation’s store if it is no longer used to encrypt.

If the certificate came from an enterprise PKI, you can revoke it as well. Keep in mind that revocation has no effect on CMS decryption (it will not stop a leaked private key from decrypting existing files) but it keeps your certificate inventory accurate and is good hygiene. Rotation and re-encryption, not revocation, are what actually retire the certificate’s usefulness.

Related posts

• Securing BIOS Passwords - why the CMS method exists and how the -...CmsFile parameters work.
• BIOS Management Scripts v2 Released - an overview of the current scripts.