Last Updated on July 31, 2023 by rudyooms

This time a simple blog about a BitLocker escrow error (0x80072f8f )that started happening (out of a sudden) on multiple devices when you were trying to silently enable BitLocker. This blog is not 100% done but as a lot of people were experiencing this issue I decided to post it before it was totally finished

I will divide this blog into multiple parts

1. The Issue
2. The Solution
3. Microsoft

1. The Issue

When you have configured some BitLocker policies in your tenant to silently enable Bitlocker and start to enroll some devices, you could run into an “escrow/backup” issue.

Somehow the device failed to back up the BitLocker Drive Encryption recovery information to your Azure AD. The event 846 will fail with the error code: 0x80072f8f AKA a security error occurred or 0x80072efe AKA WININET_E_CONNECTION_ABORTED

So no access was denied (0x80070005) or 0x801c0450 as I was mentioning in this blog below, but something to do with “security”

Configure BitLocker | Intune | Escrow error 0x801c0450 (call4cloud.nl)

When taking a closer look at that error and just looking it up on my own website, drew my attention to a certificate issue as it looks like an SSL/TLS issue for now.

2. The Solution

So when taking a look at the issue and how to fix it we have some possible solutions

• Upgrading the firmware of the TPM
• Disable the RSS PSS Signature Algorithm in the registry

Of course, it’s obvious that upgrading the TPM firmware is the best option you have to make sure BitLocker encryption would be successful.

No question about that but what if somehow it was working on the device and after a wipe and reenroll with Autopilot it isn’t?

So if upgrading the TPM its firmware isn’t an option or maybe because Microsoft changed “something” you could choose to delete the cipher suite if you need to fix it ASAP.

When you delete those 3 values from the cryptography\configuration\local\SSL\00010003 registry key the client will use a different cipher for signing after you rebooted the device. After removing the RSAE-PSS keys and restarting the device it will start the encryption and would send out the recovery key to Azure AD

Luckily Richard Hicks dealt with a similar kind of issue in the past and created a PowerShell remediation for it!

https://github.com/richardhicks/endpointmanager/blob/main/Detect-RsaePssCiphers.ps1

Please note: removing the cipher suite that’s part of TLS1.3 isn’t the smartest decision. Please read further!

3. Microsoft

It seems Microsoft Support has finally awakened and has identified that there is an issue in which some Windows Clients with TPM 2.0 cannot handle some algorithms (RSA PSS) during client TLS communicating with enterpriseregistration.windows.net

So that explains the error I noticed and the first idea I had about what it could cause. It looks like Microsoft still needs a couple of days to fix it as the ETA for this fix is now set to 04-08-2023

Conclusion

0x80072f8f AKA Security Error could break your BitLocker enrollment because the TPM doesn’t and the service doesn’t go along with the RSA PSS cipher or maybe because of some weird issue service side