Last time I wrote about the why a Certificate Revocation List (CRL) should be available for the majority of services that make use of certificates. One of those prime examples is the use of smartcards. When revocation can’t be checked, you simply can not logon. Most Microsoft PKI deployments start with a single web server hosting the CRL Distribution Point (CDP) and Authority Information Access (AIA) locations. While this works well for smaller environments or labs, it introduces a single point of failure. If the web server becomes unavailable, certificate revocation checking may fail and certificate validation can be disrupted across the environment.
Continue reading
Last week I attended an interesting PKI training from CQURE. I never really had any formal PKI training before, mostly because I’ve spent years learning it the way many infrastructure engineers do, by breaking things in labs, fixing production issues, and occasionally questioning my life choices while staring at certutil output at 2 AM.
Still, I thought it would be fun to join. Most of the material was already familiar, but I met interesting people, had some good discussions, and definitely learned a few new things along the way. If you want to get into Microsoft PKI, I can genuinely recommend the training. PKI is one of those subjects that somehow manages to be both incredibly boring and extremely fascinating at the same time.
One of the topics we discussed was revocation checking. In the Microsoft world, this usually means Certificate Revocation Lists (CRLs) or the Online Certificate Status Protocol (OCSP). What many people misunderstand, however, is that revocation checking is not some universally enforced security mechanism. Whether revocation is actually checked often depends entirely on the application, service, operating system, or even the exact API being used underneath.
Continue reading
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
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
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
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 readingRecently I was working on a side project involving Windows AppLocker, or whatever the marketing people decided to call the tool this week. Same engine, different sticker.
Continue readingDeleting 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 readingSo, this turned out to be an interesting quest. I had reinstalled my lab Enterprise (issuing) CA, configured the server, issued new CA certificates, and created a new Remote Desktop certificate template. The next step should have been simple: publish the template.
Except it wasn’t. When I tried to publish the template, it didn’t show up.
Continue readingI 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“.