Introduction
Many Certificate Authority servers that were installed on Windows Server 2003 never got upgraded until Microsoft ceased the support of Windows 2003. Some of those are still out there running today. A massive amount of them got set up in an era when Wi-Fi in the SME market became very popular and CA servers were deployed to easily secure access to it. To be fair, a lot of administrators didn’t wait for Windows Server 2003 support to expire and made sure their CA was more or less up to date by upgrading them in place. That alone is something to commend. However, the operating system version only introduces the capability of using modern more secure providers and algorithms. It doesn’t upgrade the ones used by the PKI automatically for you. So many of these upgrade PKI servers are still using an old cryptographic provider, the “Microsoft Strong Cryptographic Provider” (SCP) and an old hash algorithm (SHA1) that’s been deprecated (see SHA1 Deprecation: What You Need to Know) or even banned.
Older certification techniques won’t cut it anymore in 2017. Image courtesy of Max Pixel.
Whether this is a real serious issue for internal use cases is another discussion as most browsers, for example, will warn you but still allow the use to prevent issues with older or none up to date appliances in your environment. Still, it’s also only a matter of time before it does become one and technology debt never gets better with age (see An update to our SHA-1 deprecation roadmap). As the IT industry is moving or has moved to SHA256 for public services it’s really time to think about your internal certificate use cases. That way you’ll be up to date before you have to upgrade urgently because things broke down.
A closer look at an upgrade original Windows Server 2003 PKI server
Typically, for a CA that was installed on Windows Server 2003, even when that was upgraded over time, you’ll notice two facts. The first one is that the cryptographic provider is still the older “Microsoft Strong Cryptographic Provider”. The second is that the Hash algorithm is SHA-1.
I’m using a lab CA deployment here to demonstrate this. This is actually an on-line enterprise root CA that was upgraded from Windows Server 2003 all the way to Windows Server 2016. Take a look at the General tab of the root CA’s properties and notice the values for the provider and the hash algorithm.
You can also confirm this information by running Certutil –store my <Your CA common name> mine in the lab is called “PKI”.
The hash algorithm is SHA-1 and the provider is Microsoft Strong Cryptographic Provider even on this Windows Server 2016 Server. The same would be true if this server was still running Windows Server 2012 (R2) or lower.
The older “Microsoft Strong Cryptographic Provider” and SHA1 hash are less secure and it’s wise to upgrade them. Moving the CA to “Key Storage Provider” (KSP) means for support the latest enhanced key storage mechanism and stronger key and signature algorithms for Cryptography Next Generation (CNG). All this helps protect the private key a lot better.
We need to fix the provider first anyway before moving from SHA-1 to SHA-256. Upgrading from a Cryptographic Service Provider (CSP) to a Key Storage Provider (KSP) is rather tedious, so Microsoft helps us automate it! When you’re running an OS below Windows Server 2008 R2 you have to upgrade it first. Even when running Windows Server 2008 R2, you’ll make your life a lot easier by moving to at least Windows Server 2012. The good news is that if you are running a windows Server version Windows Server 2012 or higher, you have the certutil version that can help you move from CSP to a KSP provider and can do everything on the CA host itself.
Things to note
You must evaluate if handing out SHA256 certs will work in your environment for your needs. Software, hardware, operating systems. A reasonably modern Windows environment should not have an issue. To me that means Windows 7 / Windows 2008 R2 are the oldest OS versions around. Sure even older Windows clients will work with SHA256 (even Windows XP and Windows Server 2003 with hotfixes KB968730 and KB938397 installed. But really, you DO NOT want to be there.
Do note that Windows Server 2008 R2 is the minimum version you need for a CA to be able to handle SHA256, but again, upgrade it if you can.
There is no serious need to reissue the root signing CA certificate. Windows relies on other means to validate root certificates besides the signature. As long as all the PKI root CAs have been switched to use SHA2 to sign subordinate CA certificates, CRLs, client certs, etc., and you’re good to go. You might want to leave the root CA cert signed with SHA1 if this certificate is used with partners in some part of your infrastructure and is hard, expensive and tedious to change.
The Scenario
We are dealing with an on-line single-tier enterprise root CA deployment running Windows Server 2016 that was upgraded from an original Windows Server 2003 deployment over the years. Yeah, I hear you about the on-line single-tier enterprise root CA. But that’s reality. There are thousands of small and medium businesses out there that leverage a single on-line enterprise root CA for all their internal cert needs (WiFi, switches, servers, clients, etc.). These businesses aren’t exactly super security sensitive defense contractors. For them, whether you agree principally or not, a single root CA does the job, it’s very easy, low maintenance and they’d like to continue that way, no matter what moral high ground you take here. So, either you help them move to a KSP provider with SHA256 or keep preaching lonely on a hill while they are left with technology debt and will run into issues eventually.
Now, I’m not saying that this isn’t a great opportunity to get them to a 2 tier PKI and have that root CA moved to be standalone and off line for better protection. If this is possible and acceptable, sure, why not. But if for now, they’ll stick to the single on-line enterprise root CA, why not make sure they have the latest OS version for their root CA, moved from SCP to SKP and if possible have the root CA hand out SHA256 certs going forward? That’s already a big success and it provides them with a level of security that is sufficient for their needs. You have to understand that many organizations simply won’t be able to afford and support a multi-tier PKI, and if needed, even run two PKIs in parallel, one for the remaining SHA1 needs and the other for SHA2. The latter is in principle a great idea as its safe. You keep a functional SHA1 PKI for the legacy use cases that just can’t handle SHA256 and leverage the new SHA256 PKI for the uses case that can. Over time the old PKI will be phased out as the legacy use cases disappear or as they are upgraded. Sill, in reality, it’s just not going to happen like that everywhere. Also in smaller shops, it can be easy to upgrade a few small pieces of gear and it’s often also easier to identify all use cases for the PKI. Don’t let perfection be the enemy of the good here.
There are 2 big parts to the upgrade:
In the next parts, we’ll look at the steps needed to upgrade your CA to SKP & SHA256. When your PKI infrastructure is virtualized, you’re lucky as you have great tools like easy backup/restore and checkpoints at your disposal to mitigate the risk. The techniques are the same whether you upgrade a root CA or a subordinate one. In a multitier PKI, the management around CRL publishing becomes a bit more involved but nothing people who run one can’t handle.
