- Docker logs tail: Troubleshoot Docker containers with real-time logging - Wed, Sep 13 2023
- dsregcmd: Troubleshoot and manage Azure Active Directory (Microsoft Entra ID) joined devices - Thu, Aug 31 2023
- Ten sed command examples - Wed, Aug 23 2023
Why migrate to SHA-2?
As computing power continues to increase and its cost lowers over time, the amount of processing power available to attackers is far beyond what it was 20 years ago. SHA-1 is no longer considered a secure cryptographic hash algorithm due to these factors.
Since 2005, there have been known collision attacks in which multiple inputs can produce the same output. As a consequence, well-known cybersecurity standards organizations, such as the National Institute of Standards and Technology (NIST), recommended moving away from SHA-1. The NIST Special Publication 800-131A states:
SHA-1 may only be used for digital signature generation where specifically allowed by NIST protocol-specific guidance. For all other applications, SHA-1 is disallowed for digital signature generation.
Modern browsers display warnings and errors when old cryptographic technologies are detected. Since January 1, 2016, organizations have not been able to obtain a new SHA-1 certificate from most public certificate authorities.
As organizations migrate from SHA-1 implementations to SHA-2, considering internal Active Directory Certificate Services is part of the overall PKI infrastructure that needs updating. It may be several generations old, with root and subordinate certificates generated with SHA-1. As a result, there can be challenges when considering the migration to SHA-2.
Considerations and challenges of SHA-2 migration
There are still devices in use that may not support the SHA-2 algorithm. These include older mobile devices running older Android versions and even Windows XP before Service Pack 3. In addition, many businesses may be using these operating systems on devices to run legacy software that is still business critical.
These factors must be considered when migrating internal ADCS to new technologies, such as SHA-2, and these devices rely on internal certificates provided by the internal PKI infrastructure.
Cryptographic service provider vs. key storage provider
Another newer technology enhances the operation of Active Directory Certificate Services (AD CS). Once businesses migrate their AD CS server to Windows Server 2012 or higher, they can benefit from a newer technology called key storage provider (KSP). The KSP is the next generation of storage architecture for PKI compared to the older cryptographic service provider (CSP). It is included in what Microsoft refers to as Cryptography Next Generation (CNG).
Those who want to migrate to the newer KSP will have to upgrade to a newer version of the operating system if they run anything older than Windows Server 2012. However, it is required in order to reconfigure the CA to issue certificates using the SHA-2 hash algorithm rather than SHA-1.
How can you check to see which provider and hash algorithm you are currently using with AD CS? There are a couple of commands to run on your AD CS server to check this. Note the following:
Check to see which provider your server is configured to use:
certutil -getreg ca\csp\Provider`
Check to see which hash algorithm is used on your ADCS server:
certutil -getreg ca\csp\CNGHashAlgorithm`
As you can see below, the Windows Server 2019 that was checked using the commands listed is using the KSP provider and SHA256 for the hashing algorithm.
Evaluating the cryptography used for business-critical infrastructure is extremely important for organizations today to bolster their cybersecurity posture. SHA-1 is a fully deprecated protocol at this time and is considered insecure.
While most public certificate authorities have not issued any SHA-1 certificates since 2016, there is still the possibility of businesses using SHA-1 certificates as part of their internal ADCS infrastructure.
Subscribe to 4sysops newsletter!
It is time for companies to migrate to SHA-2 certificates and the newer KSP that has been possible since Windows Server 2012. In the next post in the series, we will look at migrating from SHA-1 to SHA-2 in AD CS.