Device Certificate Check and Multiple Certificate Authorities
Skyhigh CASB allows you to confirm that a device used to access a sanctioned corporate solution, such as Office 365 or Salesforce, is managed. It does so by requesting that a corporate deployed certificate exists on the endpoint or application. The managed device certificate check is part of the SSO workflow integrating with IdPs, such as Okta or Ping, using SAML.
Some organizations have multiple Certificate Authorities. For example, one is part of their Mobile Device Management solution used to deploy client certificates on supported corporate mobile operating system devices. Another uses Active Directory where client certificates are automatically distributed to all devices that are joined to the domain.
It is possible for most MDM solutions to use Active Directory for Certificate services. But this isn’t configured in all cases. Maybe MDM was deployed first and there is no appetite to re-architect and use Active Directory. Or there is a requirement to maintain an air gap between these solutions.
This might appear to pose a problem configuring the device certificate check within Skyhigh CASB as it seems that only one Certificate Authority is supported.
The purpose of this article is to clarify this point and state that this is not the case and multiple Certificate Authorities can indeed be used.
Step-by-Step Guide
To support the multiple Certificate Authorities use case, the file that is uploaded as the ‘Root Certificate” simply needs to contain the root certificates of all certificate authorities. On a Mac, the easiest way to do this and make sure the format of the original files is preserved is to use the CLI command 'cat'.
It is also possible to copy the contents of the files and paste them into a new file. If you use this method, make sure to maintain the format of the file, specifically EOL markers. Otherwise, the combined root CA file might not be usable.
- On your Mac, open a terminal window and change to the directory where the root certificates are held.
- Use the following command replacing the file names as needed.
cat root_ca1.pem root_ca2.pem > combined_root.pem - Upload this file as the Root Certificate and click Save.
- Test devices with client certificates that are signed by either of the certificate authorities.
The output of the file has the following format:
|
|
Certificate Revocation List - CRL
The purpose of the Certificate Revocation list is to maintain a list of certificates signed by the certificate authority that is no longer valid and might be not be trusted. For example, the device with a certificate is lost or the certificate compromised.
Using much the same method as above, it is also possible to use the Certificate Revocation Lists produced by the Certificate Authorities in use for this task.
But, it seems, a CRL must be present for all certificate authorities used. If only one certificate authority CRL is used, the certificates signed by the other certificate authority are rejected, even if valid.
The CRL is hosted by a customer-provisioned web server and it is their responsibility to maintain this service and make sure the CRL is kept up to date.
NOTE: You can force Skyhigh CASB to retrieve the CRL file from the customer location by changing in the certificate check section in the Skyhigh CASB Cloud Security Manager. For example, upload the root certificate again and save it.
The output of the combined CRL has the following format:
|
|
Here is an example of a completed configuration:
Supported UEM/MDM Solutions for Device Certificate Authentication
Skyhigh Security integrates with any Unified Endpoint Management (UEM) or Mobile Device Management (MDM) solution that can issue a device certificate.
Some of the commonly used UEM/MDM solutions that provide certificates to enforce device certificate-based policies are:
- VMware Workspace ONE (AirWatch)
- Ivanti Neurons (MobileIron)
- Microsoft Intune