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 readingTag: PKI (Page 1 of 2)
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 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 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“.
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 readingIn 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 readingOver the past few months, I’ve been writing extensively about building and configuring Microsoft Enterprise PKI (AD CS). And if you’re anything like me, you probably run some kind of home lab where you test ideas before deploying them at work.
At the same time, there’s a noticeable shift happening in the industry. Proxmox is showing up more and more, not just in home labs, but increasingly in enterprise environments as well. The same applies to my own setup. I’ve been running Proxmox for over two years now and I genuinely like the platform.
One thing that has been bothering me for a while, however, is that it uses a self-signed certificate for its management web interface. While the connection itself is still encrypted and protected (contrary to popular belief), it simply isn’t how things should be in a properly managed environment. So let’s fix that.
Continue readingThis post is a small (promise!) but practical addition to my PKI series.
I wrote this blog because I wanted my own version of “how to set up RDP certificates.” Mostly as personal documentation, I can’t remember everything off the top of my head anymore… getting old.
During my initial research, I was surprised to see that many blogs still recommend older practices, SHA1 signatures, legacy cryptographic providers, or RSA 2048-bit keys without much explanation. And to be clear, I’m not saying RSA 2048 is bad. It’s absolutely still secure and widely used.
Continue readingIn my previous blog about LDAPS certificates, I briefly touched on a topic that often leads to confusion, how a Domain Controller actually decides which certificate to use for LDAPS. At the time, I promised to dive deeper into that specific mechanism, because understanding it is critical when troubleshooting seemingly “mysterious” LDAPS issues. This post is that promised deep dive.
Continue reading