Forum Discussion
Using get-filehash on fips enabled system
I knocked up a test Windows Server 2022 Server Core guest and tested Get-FileHash with and without FIPS enabled.
As you'd expect, with FIPS disabled all the available hash algorithms worked.
With FIPS enabled, the only two algorithms that failed were MD5 and RIPEMD160. The remainder worked just fine.
Testing just that one setting (enabling FIPS) is hardly rigorous but it does seem to suggest that additional configuration is causing the issue, not FIPS on its own.
You might also want to check out if any customisation of the TLS ciphers has been done via group policy and/or the registry as outlined below, as this can also impact hashing.
I know I've done this in the past as a means to only allowing algorithms that support Perfect Forward Secrecy, so while it's only an educated guess at best, it may be worth checking.
Manage Transport Layer Security (TLS) | Microsoft Docs
Restrict cryptographic algorithms and protocols - Windows Server | Microsoft Docs
Transport Layer Security (TLS) registry settings | Microsoft Docs
I'm not sure if you have access to the following commandlet, but if you do, it's a quick way to get an idea on which suites are currently enabled, and while I'm not sure if it enumerates them in order, possibly which is providing the first relevant hash match. My guess is that a disallowed suite is providing the first match.
(Get-TlsCipherSuite) | ft -AutoSize Name, Exchange, MaximumExchangELength, Hash, HashLengthCheers,
Lain
Thank you for the response. Pretty much all of the algorithms are failing. I would understand MD5 being a problem. We are looking at the system to see if it is having other issues.
Thanks!
I knocked up a test Windows Server 2022 Server Core guest and tested Get-FileHash with and without FIPS enabled.
As you'd expect, with FIPS disabled all the available hash algorithms worked.
With FIPS enabled, the only two algorithms that failed were MD5 and RIPEMD160. The remainder worked just fine.
Testing just that one setting (enabling FIPS) is hardly rigorous but it does seem to suggest that additional configuration is causing the issue, not FIPS on its own.
You might also want to check out if any customisation of the TLS ciphers has been done via group policy and/or the registry as outlined below, as this can also impact hashing.
I know I've done this in the past as a means to only allowing algorithms that support Perfect Forward Secrecy, so while it's only an educated guess at best, it may be worth checking.
Manage Transport Layer Security (TLS) | Microsoft Docs
Restrict cryptographic algorithms and protocols - Windows Server | Microsoft Docs
Transport Layer Security (TLS) registry settings | Microsoft Docs
I'm not sure if you have access to the following commandlet, but if you do, it's a quick way to get an idea on which suites are currently enabled, and while I'm not sure if it enumerates them in order, possibly which is providing the first relevant hash match. My guess is that a disallowed suite is providing the first match.
(Get-TlsCipherSuite) | ft -AutoSize Name, Exchange, MaximumExchangELength, Hash, HashLength
Cheers,
Lain
- Lain,
Awesome! Thank you. On most servers we have, I see the same result with MD5, and RIPEMD160.
The system I need my PowerShell to run on, however, fails on the others, so I will check out the cipher suite as you recommend. I am suspecting that the system may have gotten more of a lock down than required.
I appreciate you taking the extra time to check this out and for sending the links to the articles.
Thank you!