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:

Hello readers!

Blogs are dying

Last week I was surprised when got the following message on Microsoft Blogs (eaxmple: https://blogs.technet.microsoft.com/crypto):

After some investigation, more disabled blogs were found. I tried to find any information about what is going on, but not much luck. All I was able to find is the fact that Microsoft is retiring their TechNet and MSDN platforms and move to..yes, another blogging engine. Though, not all blogs are moved. There are various rumors (not yet official) and they suggest that only most popular and trending (Azure!) blogs will be migrated. The rest blogs will be wiped. Silently. Other rumors suggest that it is blogs owner’s responsibility to move their blog to a new platform. Keep in mind, these are just rumors, the fact is that blogs silently disappear: https://blogs.technet.microsoft.com/brandonlinton/2018/11/05/retirement/. There was no official announcement from Microsoft about the trend or blog decommission schedule. Further investigation revealed that MSDN blogs are mosing to DevBlogs and TechNet blogs are moving to TechCommunity.

Hello S-1-1-0,

Today I’m continuing my certutil tips and tricks post series. In this post, I will get an introduction into cryptographic service provider architecture and how certutil can list and query them.

A short introduction to Cryptographic Providers

Windows Cryptography relies on a cryptographic service provider (CSP) architecture when performing cryptographic operations. CSP is a program module that represents an abstraction between client application and functions that utilize private keys. Applications are not required to interact with private key material directly, implement cryptographic functions. They only interact with known CSPs that implement private key storage database and cryptographic functions and operations. Here is a simple diagram that shows the relationship between client application and CSP:

Hello world,

Today I’m continuing my certutil tips and tricks post series. In this post, I will show how cryptographic objects are stored in files and how certutil can convert between different presentation formats.

Binary formatting

In a nutshell, all cryptographic objects are stored in a binary stream form which is ready for transfer (transfer syntax, or raw syntax). However, transfer syntax is not suitable for other presentation forms, especially, display forms. For example, if we open binary certificate in notepad, we may see a mess like this:

We can see a lot of non-printable characters. This means that we cannot copy/paste its contents into a text-based messaging system (web page, email body, IM, etc.). The only thing we can do here is to attach the file. If messaging system doesn’t support file attachments, we are out of luck.

Time by time I see questions on StackOverflow.com where people ask “How to do view/decode/validate certificate in Windows?”. And answers often include OpenSSL examples for no reason. OpenSSL is not built-in into Windows box, it is a 3rd party dependency and such responses force users to download the tool to perform basic stuff. Sounds like, there is no other way to do that otherwise. Yes, OpenSSL can do these tasks, but why do people ignore native tools which are built in Windows box? I’m going to write several blog posts to promote a built-in certutil.exe tool.

Ok, what Windows can offer us? There are two main command-line cryptographic utilities called certutil.exe and certreq.exe.

Certutil is used for various cryptographic operations which include:

• dealing with cryptographic objects
• validating cryptographic objects
• managing Windows Certificate Store (view/add/delete/export/import)
• managing Active Directory Certificate Services components (including Certification Authority, OCSP server, Enrollment Web Services)

Certreq is used for certificate enrollment operations, which include:

• certificate request generation
• certificate request submission to ADCS server and issued certificate retrieval and installation

These tools cover most of cryptographic operations you may encounter when managing Windows box.

In this post, I will talk about parsing and decoding cryptographic objects with certutil.