Hello everyone!
This a good time for a new blog post! Today I want to share some thoughts on Key Recovery Agent (KRA) certificate management.

What is KRA and Key Archival

Let's refresh what private key archival is in AD CS context. Key Archival is the process of securily storing subscribers' (clients) private key in CA database for backup purposes should client loose access to private key. Key archival is primarily used to implement a centralized long-term backup process for encryption keys (email, EFS, document encryption).

The whole idea may not be apparent from the first look, but here is a strong reason: encryption keys are used to decrypt documents/files/emails even after their expiration, so you may need encryption key after its expiration. Expired certificates are not normally backed up as part of regular backup process or stored in long-term backup set. If certificate is expired, we normally renew it and delete old one. And you will be stuck if such encryption certificates and their keys are lost. This is why Microsoft implemented a separate encryption certificate backup process and store them in CA database. CAs are long-living entities, can live for decades and survive multiple migrations. And it can be easily backed up with regular backup process, because it will store a complete history of CA DB content, including historical one.

While it may look insecure, storing private keys in database is never a good idea, right? And this is where Key Recovery Agent (KRA) comes to a play. All private keys stored in CA database are encrypted with one or more KRA certificates. And even if you steal CA database and dump it, client private keys will be stored in encrypted blobs and CA/attacker has no access to KRA keys to decrypt client keys. Here is a timeline diagram that shows key archival process:

As you can see, private key material is protected at every stage: between client and CA (on a wire) it is protected with CA Exchange certificate. In CA DB, it is protected with one or more KRA certificates. And this process perfectly scales to any enterprise size, whether it is SMB, or large holding because of built-in automation using certificate templates.

Key recovery process is a bit different as it involves different entities:

CA itself doesn't play any specific role, it acts as a secure storage. Instead, we involve two different entities: CA Manager, who has access to CA, CA database and retrieve encrypted blobs. CA Manager cannot decrypt these blobs, so we involve another entity, Key Recovery Agent. These MUST be different and highly trusted persons to avoid key archival misuse by a single person. So, CA Manager has access to CA DB, can retrieve encrypted blobs and that's pretty much all. KRA, on the other hand, can decrypt these blobs, but cannot retrieve them from CA DB. This is a clear responsibility separation. You cannot use single entity to compromise client keys.

What's wrong with KRA certificates?

While the whole process is pretty clear and understandable, there is a catch: KRA certs and keys MUST be available to decrypt the oldest encrypted client private key. And required KRA certificate MUST be easily identifiable over the time. Default recommendation is to use a pre-installed Key Recovery Agent certificate template to enroll for KRA certificates. Default validity is 2 years. Once it is expired, KRA has to enroll a new certificate and ask CA Administrator to replace expired KRA certs with new ones.

And here is the problem: KRA has to maintain the history of all its certificates and keys, including expired ones. When KRA certificate is replaced on a CA, previously encrypted client keys ARE NOT re-encrypted. So, in order to decrypt such key, KRA need its private key associated with certificate used to encrypt client's private key long ago. Assuming, CA lifetime of 20 years and default KRA cert validity of 2 years, you will end up with 10(!) different KRA certificates. And KRA is required to maintain them all. And this is where the process often fails. Comupters are changed/replaced/migrated much more often and it is enough to miss one KRA key backup process during PC replacement to make this KRA helpless. Of course, you can increase template validity to 5 years. It will reduce the number of keys from 10 to 4 per KRA. Still error-prone number.

I'm not familiar with latest official Microsoft recommendations as of today: the latest official whitepaper on Key Archival was released during Longhorn Beta 3, so I took an opportunity to think about my own solution.

Suggested Recommendation

Disclaimer: Suggested approach is provided by me. It may not comply with Microsoft recommendations or best practices or accepted by Microsoft Support. Provided recommendations are my own and gathered through my personal experience.

In order to make KRA certificate handling easier, less error-prone and keeping adequate security level, I propose to completely avoid CA-issued KRA certificates and instead use self-signed(!) ones with large validity. Yes, you read it right -- self-signed. Ultimately, KRA certificate will be valid throughout entire CA certificate validity.

KRA certificate validity scope is quite limited, it MUST be trusted only by CA and only at client private key encryption step (step 4.3 in first diagram). No other entity needs to trust KRA. And here we go: create a pair (at least) of long-living self-signed KRA certificates, configure them as trusted only CA server (install to Trusted Root CAs on CA itself only) and configure them as KRA certificates.

The only requirement here is to securely store KRA keys. Ideally, you would store them on smart cards, network¹ HSMs, protected USB dongles. It is important to store them on a portable secure storage, so you can lock them in safe, or secure offline location. And never use only one smart card/storage. I would recommend to have at least a pair of KRA certs and physical storages to avoid single point of failure.

¹ - I recommend to use network HSMs over PCIe ones, as netHSM provide high-availability (HA) configurations. PCIe HSMs may not provide redundancy.

With suggested approach we make key recovery process pretty transparent and much more reliable, because you don't have to maintain a potentially large history of KRA certificates, you maintain only one KRA key per agent. And you can align KRA certificate renewals with CA certificate renewals, which will allow KRA key rolling at reasonable periods, which will exceed 5yr period offered by CA-issued certs.

Suggested Recommendation Implementation

This section will provide steps to implement new approach, including self-signed certificate creation and CA configuration.

First step is to prepare a pair of smart cards, ensure that required driver/CSP/KSP is installed on your system. Consult with supported asymmetric key algorithms. Pick the strongest one. Often it will be RSA 4096, or ECDH_P384/ECDH_P521, though actual algorithm support will vary. In our use-case, I will use ECDH_P521.

Second step is to prepare a self-signed certificate creation script. I will use New-SelfSignedCertificate cmdlet:

$name = "Example Org KRA-1"
$ValidForYears = 20
New-SelfSignedCertificate -Subject "CN=$name, OU=Division of IT (DoIT), O=Example Org, C=LV" `
    -NotBefore ([datetime]::UtcNow) `
    -NotAfter ([datetime]::UtcNow.AddYears($ValidForYears)) `
    -Provider "Microsoft Software Key Storage Provider" `
    -HashAlgorithm "SHA512" `
    -KeyAlgorithm "ECDH_P251" `
    -KeyExportPolicy Exportable `
    -KeyUsageProperty All `
    -KeyUsage DataEncipherment `
    -CertStoreLocation Cert:\CurrentUser\My `
    -TextExtension @('2.5.29.37={text}1.3.6.1.4.1.311.21.6',"2.5.29.19={critical}{text}false") `
    -FriendlyName $name

This command uses Software KSP with exportable (in case if no smart card is used) ECDH_P521 key, SHA512 signature, 20 years validity, EKU is set to Key Recovery Agent and Basic Constraints extension is set explicitly as end-entity certificate and critical.

For smart card-based enrollment, the command would look like this:

$name = "Example Org KRA-1"
$ValidForYears = 20
New-SelfSignedCertificate -Subject "CN=$name, OU=Division of IT (DoIT), O=Example Org, C=LV" `
    -NotBefore ([datetime]::UtcNow) `
    -NotAfter ([datetime]::UtcNow.AddYears($ValidForYears)) `
    -Provider "Microsoft Smart Card Key Storage Provider" `
    -HashAlgorithm "SHA512" `
    -KeyAlgorithm "ECDH_P251" `
    -KeyUsage DataEncipherment `
    -CertStoreLocation Cert:\CurrentUser\My `
    -TextExtension @('2.5.29.37={text}1.3.6.1.4.1.311.21.6',"2.5.29.19={critical}{text}false") `
    -FriendlyName $name

The difference is: smart card KSP, no export flags.

Do not use TPM to store KRA keys.

Repeat these commands for "Example Org KRA-2" certificate. It should be identical to previous, only different subject name.

Third step: If you use software KSP, export all KRA certificates and delete private key from system after export. Copy PFX and passwords to removable media and put them to secure location (safe). Store PFX and password separately. After securing KRA private keys, export KRA certificates into .cer file (only public part, no private key) and copy them to CA server or transfer to CA administrator.

Fourth step: we need to establish a trust to KRA certs on CA server. Use certmgr.msc or certutil commands:

Certutil -addstore Root path\kra1.cer
Certutil -addstore Root path\kra2.cer
# next two commands will publish KRA certs to AD, configuration naming context. This is where CAs will look for available KRA certs
Certutil -dspublish -f path\kra1.cer KRA
Certutil -dspublish -f path\kra2.cer KRA

First two commands (certutil -addstore) must be invoked again after migrating CA to another server.

Fifth step: Use AD CS MMC (certmgr.msc) to add and configure KRA certificates. You may need until KRA certificates published in AD are replicated to all domain controllers.

1. Open Certification Authority MMC snapin (certmgr.msc);
2. Right-click CA node and select Properties in context menu;
3. Switch to Recovery Agents tab;
4. Press Add button and select new certificates;
5. Add all required KRA certificates;
6. Save changes and restart certificate services

Additional Reading

Here are two official Microsoft whitepaper related to key archival:
1. Key Archival and Management in Windows Server 2003
2. Key Archival and Management in Longhorn Beta 3

Happy Key Archival and Key Recovery!

Hello, S-1-1-0!

Today I’m going to talk about interesting subject about Enhanced Key Usage constraints in CA certificates. This question is inspired by a thread on Security StackExchange: Root CA with Extended Key Usage fields. I put a brief answer in that thread, but still feel it is incomplete. In this blog post I will try to explain the subject in more details. Let’s start!

Extended Key Usage definition

What is Extended Key Usage or simply EKU (Microsoft calls it Enhanced Key Usage, but they both share the same abbreviation)? RFC 5280 §4.2.1.12 says:

This extension indicates one or more purposes for which the certified public key may be used, in addition to or in place of the basic purposes indicated in the key usage extension.

The meaning is quite clear. How it is processed (should be processed). Few paragraphs below (same section in RFC):

In general, this extension will appear only in end entity certificates.

<…>

If the extension is present, then the certificate MUST only be used for one of the purposes indicated. If multiple purposes are indicated the application need not recognize all purposes indicated, as long as the intended purpose is present. Certificate using applications MAY require that the extended key usage extension be present and that a particular purpose be indicated in order for the certificate to be acceptable to that application.

This part is clear too: applications verify if particular OID is presented in EKU extension or not. If OID is presented, validation continues, otherwise validation fails. RFC makes no assumptions about constraining EKU on CA level to restrict CA on issuing certificates only to a specified usages subset. Since CA certificate is not directly used as end entity certificate, EKU in CA certificate makes little sense. In theory. In practice, it is not very flexible in a number of scenarios and there are cases when such constraint is necessary. For example, company manages multiple CAs where each CA is dedicated to specific purposes. another scenario is cross-certification (qualified subordination) where such constraint is a must in order to reduce chances of mississuance and detect if misissuance occurred.

Read more →

This blog post finishes a Certificate Autoenrollment in Windows Server 2016 blog post series. Here is a list of posts in the series:

• Certificate Autoenrollment in Windows Server 2016 (part 1)

First part makes introduction to certificate autoenrollment and describes certificate enrollment architecture in Windows 10 and Windows Server 2016.

• Certificate Autoenrollment in Windows Server 2016 (part 2)

Second part explains certificate autoenrollment architecture, its components and detailed processing rules.

• Certificate Autoenrollment in Windows Server 2016 (part 3)

Third part provides a step-by-step guide on configuring and utilizing certificate autoenrollment feature.

• Certificate Autoenrollment in Windows Server 2016 (part 4)

References

The last part provides information about advanced certificate autoenrollment features, scenarios and troubleshooting guide. Next section contains a list of reference documents used to write this whitepaper:

Read more →

This is a third part of the Certificate Autoenrollment in Windows Server 2016 whitepaper. Other parts:

• Certificate Autoenrollment in Windows Server 2016 (part 1)
• Certificate Autoenrollment in Windows Server 2016 (part 2)
• Certificate Autoenrollment in Windows Server 2016 (part 3)

---

Configuring Advanced Features

This section discusses templates that require certificate manager approval, self-registration authority, and how to supersede a certificate template.

Requiring certificate manager approval

A specific certificate template can require that a certificate manager (CA officer) approve the request prior to the CA actually signing and issuing the certificate. This advanced security feature works in conjunction with autoenrollment and is enabled on the Issuance Requirements tab of a given certificate template (Figure 25). This setting overrides any pending setting on the CA itself.

Read more →

This is a third part of the Certificate Autoenrollment in Windows Server 2016 whitepaper. Other parts:

• Certificate Autoenrollment in Windows Server 2016 (part 1)
• Certificate Autoenrollment in Windows Server 2016 (part 2)

---

Configuring Autoenrollment

Autoenrollment configuration in general consist of three steps: configure autoenrollment policy, prepare certificate templates and prepare certificate issuers. Each configuration step is described in next sections.

Configuring autoenrollment policy

The recommended way to configure autoenrollment policy is to use Group Policy feature. Group policy feature is available in both, domain and workgroups environments. This section provides information about autoenrollment configuration using Group Policy editor. It is recommended to turn on autoenrollment policy in both, user and computer configuration.

Read more →