Michael Waterman

Ramblings on IT and Security

Windows Server 2025 and Post-Quantum PKI

Once upon a time, certificates were issued, systems trusted each other, smartcards authenticated users, VPNs connected remotely, web servers showed reassuring padlocks, and somewhere in a forgotten virtual machine or dusty rack server, a CA happily kept signing certificates while everyone collectively agreed not to touch it unless absolutely necessary. And to be fair, in most cases, that worked surprisingly well. Until suddenly… it didn’t.

Over the last few years, PKI has been pushed far beyond what many environments originally designed it for. Certificate usage exploded. Identity became the new security perimeter. TLS is everywhere. Code signing became critical. Zero Trust architectures increased certificate dependency. And now, on top of all that, the industry is preparing for something that used to sound like science fiction:

Post-Quantum Cryptography. (Insert some dramatic music)

During the recent Windows Server 2025 Summit sessions, Microsoft shared a major update on their Post-Quantum roadmap for Active Directory Certificate Services (AD CS), including the introduction of ML-DSA support in Windows Server 2025 and the first practical steps toward quantum-resilient PKI.

Continue reading

Building Windows images with Packer on Hyper-V

Back in December, I published a blog on building Windows images using Packer on Proxmox. That setup worked well, but like most things in infrastructure, you start tweaking, refining, and eventually rethinking parts of it. if you’re anything like me, this needs to work perfectly…. and that takes a lot of time. Over the past months, I’ve streamlined the entire workflow. Less friction, more consistency, and most importantly, something I can reuse across different Windows versions without thinking twice. And best of all, it’s now fully functional on Microsoft Hyper-V!

In this post, I’ll walk you through my current setup for building Windows Server images on Hyper-V using Packer. This is the version I actually use today as I moved back to Windows Hyper-V for my lab setup, not just something that works, but something that’s predictable and maintainable and was really fun to make.

Continue reading

Monitoring Windows Firewall logs with Azure Monitor

In a previous blog, On-prem Conditional Access You Never Knew You Had I explored how the built-in Windows Firewall can be used as a powerful control mechanism to restrict access to systems, effectively bringing conditional access concepts to on-premises environments. The response to that post was overwhelming, with over 23,000 views on Reddit alone. Clearly, many organizations are interested in rethinking how they use the Windows Firewall beyond its default, often permissive configuration, and so should you/ But before you can confidently start restricting access, there is a fundamental question you need to answer:

What is actually being used in your environment?

In many cases, firewall rules have grown organically over time. Ports are opened “temporarily,” (read: we forget, so they will be open forever) exceptions are made for specific systems, and over the years, the rule set becomes difficult to understand, let alone control or optimize. Tightening those rules without proper insight is risky and can easily break critical services.

Continue reading

On-prem conditional access you never knew you had

We often associate Conditional Access with Entra ID, Cloud apps, and Zero Trust.
But long before cloud-native policy engines existed, Windows already had a way to enforce identity-based access between endpoints, and I mean really long ago. I would make the claim that we could go back to February of the year 2000, when Windows 2000 saw the light of day. Years later in the era of Windows Vista and Windows 7, we got the Windows Advanced Firewall and that can do so much more than just block or allow a port, I think it’s a really cool piece of software. The combination of Windows Firewall, Kerberos and IPsec effectively gives you on-prem Conditional Access for east-west traffic. In this post I’ll tell you a bit of history, which problems my blog solves and why you want to start using it. And for the folks that see the word “IPsec”, trust me, I’ll make it easy to use, promise!

Let’s dive in!

Continue reading

Gone in a cipher, wiping deleted data the native windows way

Deleting a file in Windows rarely means the data is actually gone. In most cases, the file system simply removes the reference to the file while the underlying data remains untouched in unallocated space until it is overwritten. That is exactly why forensic tools can often recover deleted photos, documents, and other files long after a user believes they are gone.

When organizations need to prepare systems for redeployment, decommissioning, or internal reuse, many immediately look at commercial wiping solutions. What is often overlooked is that Windows already includes a native tool capable of securely overwriting deleted data: cipher.

And yes, it’s been there for a really long time.

Continue reading

Exploring the AD CS Database

I know, I know, last time I promised that this blog post would be about renewing the issuing CA certificate, but I have something cool today as well. I ran into an issue with my lab CA that made me dive into a rabbit hole filled with advanced certutil commands and direct access to the database. Instead of treating this as an incident and forget all the commands I’ve used to view and alter information I thought I would share the information.

When working with Active Directory Certificate Services (AD CS), most people interact with the Certification Authority through the MMC console. It provides a clear view of issued certificates, pending requests, and revoked certificates. It’s the easiest way. However, behind that interface sits a database that’s per default located in the directory: “C:\WINDOWS\system32\CertLog” and has the name of your CA, in my case “Corp-Enterprise-CA.edb“.

Continue reading

Renewing a Root CA Before Expiration

It was that time again. My Root CA had reached about 60% of its certificate lifetime, which means it was time to renew the certificate, a.k.a the dreaded ADCS Root CA Renewal (plays dramatic music). As I mentioned in a previous blog, if you’re going through the effort of renewing the certificate anyway, it’s generally a good idea to renew the key pair as well. However, there are a few gotchas that come with doing that, and that’s exactly what I want to cover in this week’s post.

Along the way I ran into a couple of things that are worth knowing before you start this process yourself. Nothing too dramatic, but definitely the kind of details that can come back to bite you later if you’re not aware of them.

Continue reading

PKI Certificate Lifetimes, from a Risk-Based Approach

In a few recent discussions about Public Key Infrastructure (PKI), certificate lifetimes are often treated as fixed best practices. A commonly cited example is a 10-year lifetime for a root Certification Authority (CA) and a 5-year lifetime for issuing CAs. More recently, some practitioners argue that such models are outdated and should be replaced with fully synchronized lifecycles or significantly shorter validity periods. At first glance, these claims appear to challenge long-standing PKI design principles. In practice, however, they often introduce more confusion than clarity. The discussion typically focuses on specific numbers, such as 10/5 or 10/10, without addressing the underlying assumptions means or operational context in which these values are applied.

The reality is that different PKI environments operate under fundamentally different constraints. Traditional enterprise infrastructures, highly automated cloud platforms, and hybrid environments each have distinct operational capabilities, threat models, and trust distribution challenges. As a result, lifecycle strategies that are appropriate in one environment may introduce unnecessary risk or complexity in another.

Continue reading
« Older posts

© 2026 Michael Waterman

Theme by Anders NorenUp ↑