Hello S-1-1-0, here is a second part of an "AD CS Partitioned CRLs - A Comprehensive Guide" blog post series.

All posts in this series:

• Part 1 - Introduction
• Part 2 - Design Strategies (current)

In this part, I will explain Partitioned CRL strategies and their behavior. I will focus on partition zero handling and partition assignment randomization.

Partitioned CRL Concept

Just a brief recap of previous post: revoked certificates are uniformly (or close to it) distributed across different partitions. The following figure shows basic partitioning concept with five partitions:

Hello all! This blog posts opens an "AD CS Partitioned CRLs - A Comprehensive Guide" blog post series.

Starting with 2025 10B update (October 14, 2025), AD CS on Windows Server 2019 and newer will receive a new feature called Partitioned Certificate Revocation List (CRL), or Partitioned CRL. CRL partitioning is a process of splitting single CRL into a set of smaller CRLs. The following updates will enable this feature:

• Windows Server 2019 - KB5066586
• Windows Server 2022 - KB5066782
• Windows Server 2025 - KB5066835

Let's recall the need of partitioned CRL and current state of the subject before we dig into new update.

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:

Six years ago I joined PKI Solutions company and as part of this process I wasn't allowed to blog about PKI/DEV stuff here. Today was my last official working day at PKI Solutions and I'm back here! I spent very interesting six years there, we did really incredible work "like no one ever seen before" ©Trump. We went just from some rough idea to a quite mature product: PKI Spotlight. I was responsible for architecture design, concepts and core/critical component development and for random really cool stuff. It was a very challenging journey, nothing came just as a straight line. Throughout the process, I learned quite a lot of new stuff, such as Azure, DevOps, containers, etc., it was a non-stop learning process. At PKI Solutions, I met some really good men, Ján Sokoly, Nick Sirikulbut, Mike Bruno, Jake Grandlienard and many others. But things are changing, the company is growing, people come and go, and it's a time for new opportunities and challenges.

As I mentioned in previous post, I brought my open-source projects (PSPKI and others) to company's GitHub account. In return, I've got a permission to work on them during my work hours (with some conditions, but anyways), which was very appealing. Throughout the work at PKI Solutions, I continued the support of these tools and we created some new open-source projects as part of company's commitment to community. As part of my resignation, I was given these tools back. I want to thank Mark B. "the PKI guy" Cooper (PKI Solutions president) who is a great man and released them without conditions. So, basically almost the same stuff is back:

• PowerShell PKI module
• pkix.net library
• ASN.1 Editor and ASN parser library

I didn't bring SSL Certificate Verifier, because it looks good enough in its current state and I have no particular plans on it. I will continue to support existing tools, though I need to do some work, such as updating documentation on my website, update internal tooling, Azure DevOps pipelines and so on. And, of course, will occassionally blog about some PKI/PowerShell/CryptoAPI stuff. So stay tuned!

Disclaimer: by no means I’m an IPv6 expert and I’m not going to teach on different IPv6 configuration options and basics. In this post, I will focus solely on a specific subject.

As a part of my IPv6 learning path I played with stateful DHCPv6 and spent all weekends to sort one interesting. Here is my simple network setup:

basically, two private networks connected to a router.

1. UDM Pro router
2. L2 switch
3. DHCPv6 stateful server
4. DHCPv6 client
5. IPv6 network: fd00:0:0:4::/64

The problem: clients receive IPv6 address from DHCPv6 and cannot communicate in same network using LUA (fd00) addresses.