FileVault 2 Recovery Key showing as long string

[mapurcel]

We're seeing an issue that started in the last 2 days where after a recon and SecurityInfo command the FileVault 2 recovery key in Jamf is showing as a long string

Jamf Pro 10.6 and High Sierra

Anyone else seeing this?

[adhuston]

I had this earlier in the week. Check your configuration profile that escrows your FileVault 2 Keys. I had removed a good portion of the configuration profile to allow for the ability to change the firewall and rebuilt it as a custom configuration profile. Something in the profile broke the escrow process. Specifically around the encryption and decryption of the keys. After rebuilding the profile using the built in payload the keys were escrowed properly.

[mapurcel]

@adhuston thanks, looking through the Jamf server logs it looks like our FileVault signing cert renewed when we started seeing this problem, the last entry shows the new certificate

2018-10-10 13:00:52,077 [WARN ] [duledPool-4] [RenewalMonitor           ] - FILEVAULT2COMM signing certificate needs renewal before 20181109T104533.000-0800
2018-10-10 13:00:52,077 [INFO ] [duledPool-4] [SigningCertificateHelper ] - Creating FILEVAULT2COMM signing certificate
2018-10-10 13:00:52,344 [INFO ] [duledPool-4] [icKeyInfrastructureHelper] - Refreshing pki information
2018-10-10 13:00:52,583 [INFO ] [duledPool-4] [RenewalMonitor           ] - FILEVAULT2COMM signing certificate renewal succeeded

2018-10-12 01:00:51,072 [INFO ] [duledPool-6] [RenewalMonitor           ] - FILEVAULT2COMM signing certificate valid until 20231011T130052.000-0700

[lashomb]

We are seeing this as well. Opened a case with Jamf.

[brennerbee]

Same here, also opened a case with Jamf!

[nsburgoyne]

Same here - resolved by recreating the profiles and policies that control any of the FileVault settings.

[analog_kid]

Also seeing this and I've opened a case with Jamf as well.

[mapurcel]

A couple additional notes on this: PI-006374

In our environment any machine that successfully runs the SecurityInfo APNS command will result in a long string. This command is usually associated with a recon, but sometimes a machine will successfully recon and the command will get stuck in Pending, meaning the machine will continue to report correctly.

Great write up on the mechanics of this process, kudos to macblog. https://www.macblog.org/post/how-to-manage-only-filevault-recovery-key-escrow-with-jamf-pro/

One way to fix this is to deploy a new configuration profile, but if a machine has already reported a long string, it seems to need the FV2 rotate script that prompts the user to enter their password. https://github.com/homebysix/jss-filevault-reissue

We are not sure we want to go that route if there ends up being a server side fix that restores the original FILEVAULT2COMM cert on the server, which presumably would fix endpoints at next inventory without running the reissue script. This would involve a way to upgrade the soon to be expiring FILEVAULT2COMM cert without breaking endpoints.