Management attestation FAQ

Why should admins push client certificates to desktop devices with Okta Verify?

If client certificates are pushed through mobile device management (MDM) software and can’t be obtained through another channel, client certificates can be used to attest that the device is managed.

How is a client certificate used by Okta?

A client certificate is only used to sign an additional payload that attests for management. It isn’t used for authentication or to authenticate the user.

Can I obtain my certificates from a third-party certificate authority (CA)?

Yes, but for security reasons, it's important that the CA only issues certificates to managed devices.

For example, if you use a CA that allows self-service enrollment for users, users could obtain and use these certificates on a device that isn’t managed and then spoof management attestation. With this, users could access resources without providing the assurance that is required by the authentication policy.

How does the client pick the client certificate?

On every authentication, the server sends a list of admin-configured issuers to the client. The client goes through the list and loads all the client certificates that were issued by those issuers. It prefers the user store, but it also checks the machine store if an issuer doesn’t have any corresponding certs in the user store. After checking if the client certificate can be used for signing (private key can be accessed), Okta selects the most recently issued client certificate to attest that the device is managed. The client doesn’t do a proper revocation check, so it’s recommended to delete revoked certificates from the client.

Can client certificates in the machine store be used for management attestation?

It’s recommended to use the user store, but the machine store can be used. If the machine store it used, admins need to make sure that no elevation is required for the user to access the private key.

How does Okta validate the management attestation on the server?

Okta performs these validations:

  • The payload was signed with the client certificate.
  • The client certificate is valid (revocation checks are included).
  • The client certificate was issued by a trusted issuer that the admin uploaded.

Okta doesn’tn’t validate the whole chain, and expects the admin to delete an issuer from Okta when they’re no longer trusted.

What certificate properties do I need when I create a SCEP profile in my MDM software?

The following settings are required when you create a Simple Certificate Enrollment Protocol (SCEP) profile in your mobile device management (MDM) software:

  • URL: Enter the SCEP URL from the OktaAdmin Console.
  • Name: Enter a name for the SCEP profile.
  • Subject: Enter a subject.
  • For example: CN = {EmailUserName} managementAttestation {DeviceUid}.

    Okta doesn’t require the subject name to be in any particular format. Choose a name that indicates that the certificate is used as the device management signal to Okta. If you’re using Jamf Pro, you can also include profile variables to include the device ID (UDID).

    See Jamf Pro Administrator's Guide - Computer Configuration Profiles.

  • Challenge type: Specify if you require a static, dynamic, or delegated URL.
    • URL To SCEP Admin: Enter the Challenge URL from the OktaAdmin Console.
    • Username: Enter the UserName from the OktaAdmin Console.
    • Password: Enter the Password from the OktaAdmin Console.
  • Key Size: 2048.
  • Key usage: Digital signature.
  • Allow export from keychain: Leave cleared. It’s good security practice to mark the certificate as non-exportable.
  • Allow all apps access: If the SCEP profile is for macOS devices, select this.

After the SCEP certificate deployment, the message "Organization Intermediate Authority certificate is not trusted" appears.

This is expected behavior. An Organization Intermediate Authority certificate is used to issue client certificates. It can validate the client certificate on the Okta service, so there's no requirement for the OIA certificate itself to be trusted.

How does Okta protect against copying certificates to multiple desktop devices?

Okta creates a binding between the deviceId and the client certificate on the first authentication. After that, if the client certificate is used by a different device for a management attestation, the management attestation will fail.

What happens if I delete a desktop device management configuration?

If you delete a desktop device management configuration, new devices don’t request client certificates from the Okta CA service.

In your device management solution, delete any SCEP policies associated with the device management configuration that you deleted.

Devices that already have client certificates issued by Okta keep sending management attestations. In your device management solution, remove the client certificate from the managed devices. If some devices still have client certificates deployed, authentication policies with unmanaged device conditions might prevent user from accessing apps on those devices.