Implement OCSP revocation checking to secure Workspace ONE Access certificate-based authentication

Using certificate-based authentication with Access

Workspace ONE Access is our main tool to provide Workspace ONE and Horizon customers with powerful access capabilities by offering a one-stop Hub portal. This portal allows access to all kinds of resources from native apps, and web apps to virtual applications, and allows customers to secure that access with an extensive set of authentication methods and targeted access policies.

It allows for authentication of users with 18 methods of which 12 are SaaS-based adapters, 4 are methods enabled by a connector installed on-premises and finally, you can also leverage your existing IDP leveraging SAML or OIDC federations. While you have your well-known adapters like Password, FIDO2, DUO Security and One Time Token which are known industry-wide, where Workspace ONE stands out is its ability to use its seamless sign-on functionality. All platforms, be it Windows, Android, iOS, iPadOS, MacOS or Linux, can perform platform-optimized seamless in-app SSO without ever having the end-user to leave the application itself. For this seamless SSO, Access uses high assurance certificate-based authentication.

The settings and certificates for those sign-on methods are configured and distributed to the devices using Workspace ONE UEM. UEM can leverage integration with an existing enterprise CA (Certificate Authority) or use the built-in AirWatch CA available on each tenant which provides a quick way to use this high assurance authentication method.

The high-level steps taken for the approach are as follows:

1. Set up a Third-Party Certificate Authority or AirWatch CA on Workspace ONE UEM.
2. Enroll devices into UEM and assign a certificate profile along with the relevant SSO configuration.
   1. Android is slightly different as it does not directly use the certificate in the OS or app but uses the Tunnel client to proxy the authentication and present the certificate there.
3. Add the trusted root CA into the relevant authentication adapter for Workspace ONE Access.
4. Set the access policy to use the applicable authentication adapter based on the platform.
5. Send the device traffic to an application protected by Workspace ONE Access.
6. You should be able to get access to the application, without any authentication required.

For more information, see Configuring Authentication Methods Associated with Workspace ONE Access Built-In Identity Providers.

Using revocation checking

Certificate authentication is considered secure due to its reliance on digital certificates issued by trusted Certificate Authorities (CAs). These certificates contain cryptographic keys that verify the identity of entities in online transactions, ensuring confidentiality, integrity, and authenticity. However, to maintain this security, revocation checking is essential. Revocation ensures that if a certificate becomes compromised or no longer valid, it is flagged as such, preventing unauthorized access or misuse. Common methods of revocation checking include Certificate Revocation Lists (CRLs) and Online Certificate Status Protocol (OCSP). CRLs are lists published and periodically updated by CAs, containing revoked certificates. OCSP, on the other hand, provides real-time verification by querying the CA's server for the status of a specific certificate.

Depending on the choice and configuration of your enterprise CA or the built-in AirWatch CA, you need to configure the revocation checking option in the certificate-based authentication methods. The AirWatch CA does not offer a CRL endpoint and depends solely on an OCSP responder.

The revocation settings are documented in Using Certificate Revocation Checking for Certificate Authentication, but we will go through the specific settings for the AirWatch CA next.

Configuring revocation checking for the AirWatch CA

As mentioned previously in the case of Workspace ONE UEM, we have implemented an API endpoint to process OCSP requests. This endpoint is also configured in the AirWatch CA-issued certificate in the Certificate Authority Information Access (AIA) extension.

At any point, each AirWatch CA certificate has a certificate status associated with it. Certificate status requests can be sent over HTTP. OCSP responder will then process the requests. Depending on the current status associated with the certificate, responder will generate the OCSP response and send it back over HTTP. The OCSP responder URL is only available in the client certificates; not in the Root CA certificate configured inside the authentication method. This becomes important when setting up OCSP revocation checking to work correctly for use with the built-in AirWatch CA.

So, when you “Enable OCSP Revocation” you also configure the OCSP URL source, the default being “Configuration Only” to “Certificate Only (optional)”. Why not “Certificate Only (required)” to make sure it always checks? For that, we need to explore how this setting affects the certificate authentication flow.

When we use mutual TLS certificate authentication, the following steps occur for the authentication.

1. The server requests a client certificate based on the issuer certificate.
2. The client presents its certificate.
3. The server side verifies the certificate.
   1. Checks validity, expiration
   2. Checks issuer signature
   3. Optional: Revocation check using CRL/OCSP
      1. Check the revocation client certificate
      2. Check revocation issuer (root CA) certificate
4. Uses UID or SAN to match the user.

We can see in step 3c that during the revocation check, we not only check the client cert but the whole certificate chain including the issuer certificate. Now as described above, only the client certificates include the OCSP endpoint URL and if we set that to “required”, the whole authentication will fail when it checks the revocation for the issuer certificate.

When using the AirWatch CA we have to set the OCSP URL option to “Certificate Only (optional)” and that will still work as intended and allow us to check the status of the certificate with UEM.

For the different certificate-based adapters the revocation settings look the same. The following demo shows an example for the Mobile SSO (for Android) authentication adapter.

Conclusion

We hope this brief post helps you to understand, set up, and use OCSP with the AirWatch CA for secure access to resources with Workspace ONE.

Check out the Workspace ONE Access product page on Tech Zone for more Workspace ONE Access resources: