CVE-2022-26355 is a serious security misconfiguration that affects Citrix Federated Authentication Service (FAS) versions 7.17 through 10.6. If your FAS deployment stores a registration authority (RA) certificate’s private key in a Trusted Platform Module (TPM), but you used PowerShell scripts instead of the GUI for setup, the key actually lands in a far less secure place — the Microsoft Software Key Storage Provider (MSKSP). This mistake leaves your private keys more vulnerable to theft and misuse, undermining the security benefits of TPM storage.

Let’s break down what went wrong, how you can check for (and optionally exploit) this flaw, and what best actions to take.

About FAS and TPM

Citrix FAS provides seamless, strong authentication to virtual apps and desktops through certificate issuance. Protecting the RA certificate’s private key is critical because anyone with that key can issue certificates — and potentially impersonate enterprise users.

Storing the key in a TPM hardware chip is the gold standard, because a TPM never lets software copy the key out; it only allows signing operations inside the chip.

Where Citrix FAS Gets it Wrong

If an administrator uses a PowerShell command to set FAS up to put the private key in the TPM, Citrix FAS incorrectly stores the key in the MSKSP instead, which is just software on the server. The key can now be exported or stolen by a malicious attacker with admin rights or malware on the system.

Impersonation:

- With the RA certificate, malicious actors can generate valid client certificates and potentially access critical resources as trusted users.

Run the following command to list all RA certs and providers:

Get-ChildItem -Path 'Cert:\LocalMachine\My' |
    Where-Object { $_.Subject -like '*FAS Registration Authority*' } |
    foreach {
        "Subject: $($_.Subject)"
        "Provider: $($_.PrivateKey.CspKeyContainerInfo.ProviderName)"
    }

Technical Details

Here’s why this happens:
When you use PowerShell to generate the RA certificate and tell it to use the TPM, FAS’s script logic accidentally defaults to the software provider. What you see as “I chose TPM,” Windows ends up storing just in MSKSP through the script, not the real hardware TPM. Only the GUI does the right thing.

Suppose your setup PowerShell looked like this

New-FasAuthorizationCertificate –UseTpm

But under the hood, due to a FAS bug, it’s really doing

$providerName="Microsoft Software Key Storage Provider"
New-SelfSignedCertificate -Provider $providerName ...

What it *should* have done

$providerName="Microsoft Platform Crypto Provider"
New-SelfSignedCertificate -Provider $providerName ...

Where-Object { $_.Subject -like '*FAS Registration Authority*' }

Export-PfxCertificate -Cert $cert -FilePath C:\Temp\exported-ra.pfx -Password (ConvertTo-SecureString -String 'YourPassword123!' -AsPlainText -Force)

`

3. Attacker imports the key elsewhere and issues valid certificates, potentially impersonating any user.

*If this was stored securely in the TPM, the export would fail!*

Immediately check the provider for your RA certificate.

- If you find it on the software provider, revoke and re-issue it using the FAS admin console, choosing to securely store it in the TPM.
- Don’t use PowerShell for this specific configuration step until Citrix confirms a fix/patch is in place.

Patches & References

- Citrix Security Bulletin: CVE-2022-26355
- CVE Details
- Citrix FAS Documentation

Conclusion

CVE-2022-26355 reminds us that *how* you configure security is just as important as *what* you configure. Using a script isn’t always safe, even for experienced admins. If you run Citrix FAS and have aimed for hardware security with TPM, double-check your work — you might be less protected than you think.

> Found your key stored in MSKSP? Stop now, revoke, and fix it using the GUI — don’t risk your environment!

Timeline

Published on: 03/10/2022 17:47:00 UTC
Last modified on: 03/18/2022 13:47:00 UTC