Ramblings on IT and Security
Feedback on my earlier IIS caching article challenged an assumption I made: does a CRL’s own validity and publication fields ensure timely retrieval, regardless of HTTP caching? I built a lab to experiment with publication, download, storage and validation. Spoiler: My findings show that HTTP cache headers influence Edge’s CRL reuse, read more on how I got to this conclusion below.
Continue readingAnd we’re back again! During PKI assessments, I regularly come across IIS servers that are used as HTTP distribution points for CRLs and CA certificates. Most of the time, the web server itself works perfectly fine. The files are there, they can be downloaded, and certificate validation succeeds. There is, however, one configuration item that I see missing surprisingly often, HTTP caching. And when caching is configured, I regularly find values that do not match the CRL publication schedule. A common example is a cache lifetime of several days while the same web server is also distributing delta CRLs that are published every 24 hours.
Continue readingLast 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© 2026 Michael Waterman
Theme by Anders Noren — Up ↑