Configure a Certificate Authority

A Certificate Authority (CA) is a trusted entity that manages and issues digital certificates. The digital certificate shows the ownership of the public keys and represents an online identity for the device.

When Okta evaluates an authentication policy that requires managed devices, Okta identifies the management status of each device by checking whether they have a client certificate installed. Okta attests certificate installation by creating a digital signature with the certificate and validating it on the server. Configuring a CA allows you to issue client certificates to devices to support this operation. You can configure Okta as a CA, or provide your own CA.

Users and devices may be displayed as unmananged after your certificates have been deployed. When the user authenticates and signs in to Okta FastPass successfully, the user and device statuses are updated in the Admin Console to reflect the managed state.

Option 1: Configure Okta as a CA

Configure Okta as a CA if you want to save time, streamline how certificates are issued, and avoid the complexity and expense of deploying and maintaining your own public key infrastructure (PKI).

When a device is deleted from the Universal Directory, the certificate that was associated with that device can no longer be used. To use the same device in the future, you must delete the certificate that was associated with it, and then re-deploy a new certificate to it.

To configure Okta as a CA, create a Simple Certificate Enrollment Protocol (SCEP) profile in your mobile device management (MDM) software, and then generate a SCEP URL in Okta. Okta provides the following methods for generating a SCEP challenge:

  • MDM SCEP policy configurations are examples only. Configure SCEP policies based on your organizational needs.
  • Static SCEP URL: The MDM software assigns the same challenge secret to all devices. With this device management configuration, the challenge secret is shared across devices. The shared secret that was created for the configuration is validated, and then a unique client certificate is issued to each device.

    See the following:

  • Dynamic SCEP URL (generic): The MDM software assigns a unique challenge secret to a device. With this configuration, a short-lived unique challenge secret is generated for each device. The secret is not shared with other devices. The device can then redeem the challenge secret for a single client certificate.

    See Configure Okta as a CA with dynamic SCEP challenge for macOS using Jamf Pro.

  • Delegated SCEP URL (MEM): Microsoft Endpoint Manager (MEM) generates a unique challenge secret for each request. Okta verifies the challenge secret, and then generates a client certificate for the device.

Okta revokes device certificates that were issued but not used for successful authentication within 90 days.

Okta as a CA doesn't support renewal requests. Instead, redistribute the profile before the certificate expires to replace the expired certificate. All MDM SCEP policies should be configured to allow for profile redistribution.

See the following:

Option 2: Provide your own CA

When you provide your own CA, Okta supports certificate revocation. Okta checks the certificate revocation list (CRL) for revoked or on-hold certificates, and then blocks those certificates from sending any management signals. Okta only supports CRL endpoints that use the HTTP or HTTPS protocol, and CRLs that are signed by the same intermediate certificate that the admin uploaded. The client certificate should also include the certificate distribution point uniform resource identifier (URI). When these conditions are met, Okta downloads the CRL, and then revokes any certificates that are on the CRL. The certificate revocation task occurs in a background process that runs a few times each day. When a certificate is marked as revoked, the client can't use the certificate to set management status. Check your system log events to see details about when a certificate is revoked.

You can provide your own CA if your environment has one of the following:

  • A PKI that is integrated with your MDM software
  • An existing Active Directory Certificate Services (ADCS) infrastructure

If you use your own CA, its certificate must meet the following prerequisites:

  • Not expired
  • Supports RSA or DSA keys
  • A minimum of a 2048-bit key
  • Basic Constraint extension (2.5.29.19) indicates that it's a CA (path length >=0)
  • KeyUsage extension (2.5.29.15) includes certificate signing

Manually delete intermediate CAs that are revoked by the root CA. These aren't automatically deleted.

For Windows, client certificates should be in the current user certificate store and not the machine store. If using the local machine certificate store is unavoidable, ensure that no elevation is required for the user to access the private key.

For macOS, select the appropriate level to deploy the client certificate:

  • To ensure all users of the device are managed, select Computer Level.

  • If you want only MDM-managed users of the device to be identified as managed, select User Level.

Ensure the client certificate is available to all applications. See Use your own certificate authority for managed devices and SCEP MDM payload settings for Apple devices.