This article addresses an issue where having multiple certificates in the Certificate Authorities list for Okta Device Access can lead to unexpected behavior. Specifically, Okta may default to using the first certificate in the list for device trust validation across all platforms (macOS and Windows), even if separate certificates have been configured for each.
- Okta Identity Engine (OIE)
- Devices
- Device Integrations
- Unmanaged Devices
- Desktop (MacOS/Windows)
When multiple certificates are configured under Security > Device Trust, devices may receive a certificate intended for a different operating system. For example, a Windows device might receive the certificate originally created for macOS device trust. However, when Okta Verify is used, the device is still correctly identified as "Managed" in Okta.
The root cause of this behavior is that when multiple Certificate Authorities are listed, Okta's Device Access feature uses the certificate listed at the top of the configuration page. It does not currently differentiate between certificates based on the platform (Windows vs. macOS) for which they were originally intended.
When configuring Device Trust for multiple platforms, it is important to be aware of the certificate priority.
- NOTE: The certificate listed first in the Certificate Authorities list is the one that will be deployed to devices, regardless of the operating system.
If using separate certificates for different platforms (for example, one for macOS via Jamf and another for Windows via InTune), it is recommended to ensure the most common or intended primary certificate is placed at the top of the list.
For maximum compatibility and simplified management, consider using a single certificate for both macOS and Windows devices if the security posture allows.
This approach will ensure that devices are correctly enrolled and recognized as managed without deployment issues.
