I work daily with Microsoft Azure and the modern IT environment, but that doesn’t mean my experience in traditional IT doesn’t come in handy. A good case in point is Public Key Infrastructure (PKI) running on Windows servers.
Over the past few months, I’ve seen a sudden uptick in customers needing help with SSL certificates running on a dedicated PKI or as standalone certificates. Many of my customers are finally retiring Windows Server 2008 (or worse, 2003) and are suddenly reminded that these certificate services exist.
PKI servers are some of the most forgotten-about and undermanaged items in the IT fleet. I think this stems from the fact that you use PKIs so rarely that many of us never got comfortable with managing them. Regardless of the reason, it’s worth a having a serious discussion among your team.
Check IT Out
While I won’t go into the hows and whys, you should consider checking a few configurations on your Windows Certificate Authorities.
- Did you perform an in-place upgrade of Windows Server 2003 or 2008 to 2012 or newer? If so, verify you aren’t running the older Cryptographic Service Provider (CSP). This is a deprecated software library for encoding and decoding. You should be running the newer Key Storage Provider (KSP), but in-place upgrades can sometimes leave this in your environment. Make sure you are running Secure Hash Algorithm SHA-2 instead of the legacy SHA-1 with its known vulnerabilities. SHA-2 isn’t perfect, but it is years better than SHA-1—at least until SHA-3 is widely accepted.
- Browsers stopped supporting SHA-1 in recent years and public entities no longer issue them. However, as my recent engagements have shown, there are many other non-browser use cases for these certificates that companies still rely on.
If you have a PKI in your environment, do yourself a favor and check on these two variables. It’s possible all of this slipped under the radar while you were dealing with whatever daily fire was happening at the time.
