February 4, 2022

Introduction

Device certificate checks are one of the best security checks out there to validate device ownership, especially as they can be marked unexportable on operating systems. They are thus popular for securing network access and authenticating client VPNs.

As popularity wanes amongst traditional client VPNs due to their inherent vulnerabilities in favour of more modern VPN or “VPN-less” strategies (Citrix Secure Private Access, ZScaler Client Connector, Citrix Virtual Apps and Desktops, etc.) endpoint posture checking remains an important aspect of building confidence in the device attempting to gain access to internal, trusted resources <queue ZTNA references>. Albeit validating the presence, status, and configurations of security tools is commonplace, establishing device ownership has often been a little more challenging. And there are many organizations and use cases that must employ managed endpoints, disallow BYO or non-managed endpoints from connecting, or need to give less restricted access to managed devices vs. unmanaged devices. Domain membership checks in endpoint analysis tools such as Citrix EPA are easy enough to configure but also easy enough for the savvy user to spoof. Other checks that validate obscure registry keys that would confirm device ownership are an option and harder to reverse engineer, but few things beat the immutability of a device certificate that is locked to a device.

Citrix has long supported device certificate checks, and this guide is not intended to be a full “how-to” in configuring them. You can read up on documentation here:

Citrix Docs: Use device certificates for authentication
Citrix Docs: Device certificate in nFactor as an EPA component
Citrix KB: OCSP and CRL Check Behavior on NetScaler (OCSP config is an important consideration on ADC, and something we’ve written about before)

I should note there is a distinction between user certificates and device certificates. And they operate and are treated differently both by client operating systems and Citrix ADC. We’re focusing on device certificates in the context of them being able to determine the ownership of an endpoint. The challenge as you may note in the first link provided is the caveats around how we get to read the device certificates on an endpoint. Out of the box on Windows, the logged-in user either needs to be a local administrator, or the endpoint has the Citrix Gateway Plugin (VPN client) installed. This is due to the default Windows security restriction which prevents sufficient access for standard users to read the computer certificate store and private keys. If the Citrix Gateway Plugin is present, the Citrix EPA client plugin can route the calls to the computer certificate store through those services. Citrix explains this further under CTX230397.

But what if we have no desire to install the full Citrix Gateway Plugin? There are workarounds and they’ve changed slightly over versions. In this article I’ll walk through the basic configs necessary to allow a Citrix Gateway nFactor factor to initiate an EPA scan on a client device for device certificate validation, under the context of a standard user: no admin rights needed, no Citrix Gateway client needed. Without these modifications, the EPA scan will fail, with EPA debug logs (if enabled, and if they are enabled, should be disabled after troubleshooting and testing is completed so as not to create security exposure and risk audit compliance failure) indicating the certificate couldn’t be read.

This was validated on Windows 10, and Citrix ADC 12.1 firmware. Read on to learn how, but please note this is not officially supported. Configurations documented I should note, I have observed used to enable other VPN clients so this is not a unique predicament to Citrix EPA.

Challenge 1 – Reading the System Certificate Registry Hive

System certificates are stored under the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates\My location. If certificates are distributed via Group Policy, they’d be stored under the HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\SystemCertificates location.

Each computer \ device certificate would be stored under those locations as a separate registry key named as the thumbprint of the certificate.

The key action here is to ensure that Users and\or Domain Users (Domain Users likely nested under Users if the computer is domain joined) have READ rights on the certificate stores. This can be done via GPO or other means. This configuration may already be in place, but important to validate. The EPA client will read this store to determine what device certificates are available and allow the user to select them (if there is more than one) during the EPA scan with device certificate checking enabled.

More details on System Store Locations can be found on TechNet.

Challenge 2 – Reading the File System Private Key Store

The Windows computer account (the context in which system \ device \ computer certificates, whatever you want to call it) stores the private keys of the Microsoft Cryptographic Provider in an encrypted format in the following location: C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys. Alternatively, calling %ProgramData%\Microsoft\Crypto\RSA\MachineKeys or %AllUsersProfile%\Microsoft\Crypto\RSA\MachineKeys will bring you to the same location.

By default, only Administrators and SYSTEM accounts have access to read these files. The Citrix EPA plugin needs to read the private keys as part of the validation process. Running procmon while the EPA plugin runs its scan reveals to us on a default system the failure to read the private key, and explains the resulting failure during a device certificate check with EPA. When the Citrix Gateway Plugin (aka Citrix Secure Access) is installed, this access is facilitated by the “Citrix Secure Access Service” which gets installed into the OS and runs under the Local System context, thus having access to the keys.

Granting Users \ Domain users the “Read and Execute” permission on the folder and ensuring inheritance is propagated to the underlying files will overcome this limitation. An example of means to perform this is found below via GPO computer policy that modifies the security of the folder in the file system.

As for security implications, that is for your security team to review. As this configuration change affects an aspect of endpoint security, the risk (if any, being these are encrypted files and may not be easily portable for use with public keys) should be duly evaluated by personnel with a deep understanding of the MS crypto provider.

Configuring the EPA Factor in nFactor

This guide will not detail the building of an nFactor flow, but below is a snapshot of a simple device certificate action configuration to be used with a corresponding policy within an AAA configuration. Be sure to follow Citrix’s documentation on the proper configuration of AAA \ Citirix Gateway vServers to support device certificate authentication. I should also stress the importance of configuring OCSP responders as mandatory to ensure revoked device certificates cannot be used.

add authentication epaAction EPA_DEVICE_CERT_ACT -csecexpr sys.client_expr("device-cert_0_0")

Conclusion

It is my hope this guide provides a workaround for administrators and consultants alike to implement EPA device cert checks without needing local admin rights for the users on their endpoints, or the Citrix Gateway Plugin installed. Special thanks to Guillaume Octeau for his assistance in analyzing the procmon results and formulating a GPO configuration for ease of deployment to address MachineKeys security.

Subscribe