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 evaluating an app sign-in policy that requires managed devices, Okta identifies the management status of each device by checking whether they have a client certificate installed. To attest certificate installation, Okta creates a digital signature with the certificate and then validates 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 unmanaged 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: 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:

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:
- Configure Okta as a CA with static SCEP challenge for macOS with Jamf Pro
- Configure Okta as a CA with static SCEP challenge for Windows using Workspace ONE
Dynamic SCEP URL: 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 isn't shared with other devices. The device can then redeem the challenge secret for a single client certificate.

See the following:
- Configure Okta as a CA with dynamic SCEP challenge for macOS with Jamf Pro
Delegated SCEP URL: Microsoft Intune generates a unique challenge secret for each request. Okta verifies the challenge secret, and then generates a client certificate for the device.

See the following:
- Configure Okta as a CA with delegated SCEP challenge for macOS with Microsoft Intune
- Configure Okta as a CA with delegated SCEP challenge for Windows with Microsoft Intune

MDM SCEP policy configurations are examples only. Configure SCEP policies based on your organizational needs.

Revoking certificates with Okta as a CA

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. Configure all MDM SCEP policies to allow for profile redistribution.

Option: Provide your own CA

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

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.

Revoking certificates with 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 signed by the same intermediate certificate that the admin uploaded. The client certificate should also include the uniform resource identifier (URI) for the certificate distribution point.

When these conditions are met, Okta downloads the CRL and then revokes any certificates on the CRL. The certificate revocation task occurs in a background process that runs a few times each day. After 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.

Manually delete any intermediate CAs that the root CA revokes. These aren't automatically deleted.