Certificate Enrollment settings

Certificate enrollment settings are used as follows:

  • As part of a larger process of setting up a certificate enrollment server to support authentication for VPN on demand, Wi-Fi, Exchange ActiveSync, AppTunnel and so on.
  • To provide devices identity certificates that you uploaded to Core for the case when you want to provide the same identity certificate to many users’ devices.
  • To provide user-provided certificates to devices when end users use the Core user portal to upload their identity certificates to Core.
  • To specify that AppConnect apps on devices use derived credentials.

The available options are:

  • Blue Coat: Select Blue Coat to create a Blue Coat certificate enrollment setting for integrating with the Blue Coat Mobile Device Security service.
  • Client-Provided: Select Client-Provided if you want AppConnect apps to use derived credentials for authentication, digital signing, or encryption.
  • Entrust: Select Entrust if you are using the Entrust Datacard certificate enrollment solution.
  • GlobalSign: Select GlobalSign if you are using GlobalSign as the CA for certificate enrollment.
  • Local: Select Local if you are using Core as the CA.
  • OpenTrust: Select OpenTrust if you are using the OpenTrust integration. See Configuring OpenTrust CA.
  • Single File Identity: Select Single File Identity to upload an identity certificate for distribution to devices.

  • SCEP: Select SCEP for standard certificate-based authentication using a separate CA.

    SCEP Configurations created before upgrading to Core 7.0.0.0 or later should be replaced with a new SCEP Configuration. Failure to do so might result in cert renewal failure from Core 9.4.0.0.

  • Symantec Managed PKI: Select Symantec Managed PKI if you are using Symantec’s Certificate Enrollment solution. See Configuring Symantec Managed PKI for more information.
  • Symantec Web Services Managed PKI: Select Symantec Web Services Managed PKI if you are using the Symantec Web Services Managed PKI solution. See Configuring Symantec Web Services Managed PKI for more information.
  • User-Provided: Select User-Provided if device users will upload their personal certificates. The user portal includes a certificate upload section for this purpose. A web services API is also available for you to upload user-provided certificates.

If Certificate Enrollment integration is not an option

If Certificate Enrollment integration is not an option for your organization, consider configuring Core as an intermediate or root CA. See Certificate Enrollment settings for more information.

Supported variables for certificate enrollment

The following variables are supported for the required and optional fields when configuring integration with supported Certificate Authorities (CA’s):

  • $EMAIL$
  • $USERID$
  • $FIRST_NAME$
  • $LAST_NAME$
  • $DISPLAY_NAME$
  • $USER_DN$
  • $USER_UPN$
  • $USER_LOCALE$
  • $DEVICE_UUID$
  • $DEVICE_UUID_NO_DASHES$
  • $DEVICE_UDID$
  • $DEVICE_IMSI$
  • $DEVICE_IMEI$
  • $DEVICE_SN$
  • $DEVICE_ID$
  • $DEVICE_MAC$
  • $DEVICE_CLIENT_ID$
  • $USER_CUSTOM1$
  • $USER_CUSTOM2$
  • $USER_CUSTOM3$
  • $USER_CUSTOM4$
  • $REALM$
  • $TIMESTAMP_MS$
  • $RANDOM_16$
  • $RANDOM_32$
  • $RANDOM_64$
  • $CONFIG_UUID$*

* This substitution variable works only for the values under the Subject Alternative Names section for the following configurations: Entrust, Local, SCEP, Symantec Managed KPI. It is used for Sentry certificate-based tunneling (CBT).

Certificate generation time

Certificate enrollment settings can be referenced from other settings on Core that require an identity certificate. Some settings that can reference certificate enrollment settings are Exchange settings, Email settings, Wi-Fi settings, VPN settings, AppConnect app configuration settings, Docs@Work settings, and Web@Work settings.

Most certificate enrollment settings cause an identity certificate to be generated. The identity certificate is generated at one of these times:

Some certificate enrollment settings do not cause an identity certificate to be generated. Specifically, for user-provided certificate enrollment settings and single file identity certificate enrollment settings, the certificate is available on Core. For client-provided certificate enrollment settings, the certificate is available in Mobile@Work.

Early generation

Early generation occurs when you apply a label to a setting that references the certificate enrollment setting. Core generates identity certificates at this time for:

  • AppConnect app configurations
  • Docs@Work settings
  • Web@Work settings

For each device that has the same label as the setting, Core does the following:

  • For devices running Mobile@Work 9.1 for iOS or earlier, Core generates an identity certificate for the device for each setting that references the certificate enrollment setting.
  • For devices running Mobile@Work 9.5 for iOS, Core generates exactly one identity certificate for the device regardless how many settings reference the certificate enrollment setting

After Core generates an identity certificate, if Core does not send the certificate to a device within 14 days, Core deletes the certificate from its file system. The certificate will be generated on-demand.

On-demand generation

On-demand generation occurs when Core sends a setting that references the certificate enrollment setting to the device. On-demand generation occurs for all settings (that reference a certificate enrollment setting) that are not listed in the early generation list above. A setting, including the certificate, is delivered to a device when the device checks in with Core.

Certificate delivery time for AppConnect-related certificates

This feature is not supported on macOS devices.

When an AppConnect-related setting (AppConnect app configuration, Web@Work setting, or Docs@Work setting) specifies a certificate enrollment setting, the time that Core delivers the identity certificate to the device depends on the Mobile@Work version on the device.

Certificate delivery from Core to the device is not applicable in these cases:
- The certificate enrollment setting specifies decentralized mode.
- The certificate enrollment setting type is client-provided.

Certificate delivery for Mobile@Work 9.1 for iOS and earlier versions‫

Core delivers the identity certificate to the device when the AppConnect-related setting is delivered to the device. An AppConnect-related setting is delivered to the device when Mobile@Work does an app check-in with Core and either:

  • The AppConnect app launched for the first time.
  • The AppConnect-related setting changed.

These versions of Mobile@Work do not store the certificates.

Certificate delivery for Mobile@Work 9.5 for iOS

Core delivers an identity certificate to Mobile@Work on the device when the first AppConnect app that uses the certificate launches. Mobile@Work stores the identity certificate. Subsequent AppConnect apps which use the same certificate receive the certificate from Mobile@Work without any involvement from Core.

When an AppConnect app launches, control switches to Mobile@Work so that Mobile@Work can check in with Core to receive the AppConnect-related configurations and identity certificates for the app. The time it takes to switch control back to the app is longer when the app needs many identity certificates and it is the first AppConnect app that needs those certificates.

Note the following:

  • Mobile@Work stores the certificates securely on the device, encrypting them the same way it encrypts AppConnect-related data such as AppConnect app configurations. Mobile@Work displays general information about each stored certificate, such as its expiration date.
  • When a device user upgrades Mobile@Work from version 9.1 or earlier, existing AppConnect apps that already have their certificates continue to use those certificates. Such apps receive replacement certificates from Mobile@Work only when their AppConnect-related setting changes on Core.
  • The delivery strategy has no impact on AppConnect apps themselves. The apps do not need to be rebuilt or rewrapped.

Related topics

  • “Data encryption for secure apps” in The AppConnect and AppTunnel Guide.
  • “App check-in and Mobile@Work” in The AppConnect and AppTunnel Guide.
  • “Viewing certificates stored in Mobile@Work” in The AppConnect and AppTunnel Guide.

Performance impact

When a device uses Mobile@Work 9.5 for iOS, the generation and delivery strategy of certificates to a device improves performance on Core and on the device.

The Core performance improvements are:

  • When multiple AppConnect apps’ AppConnect-related settings use the same certificate enrollment setting, Core generates and delivers the certificate to the device only once.
  • With prior versions of Mobile@Work, Core generates and delivers a separate certificate for each AppConnect app.
  • When you modify an AppConnect-related setting field that does not involve the certificate:
    • Core does not regenerate the certificate.
    • With prior versions of Mobile@Work, Core regenerated the certificate unless you had selected Store keys on Core on the certificate enrollment setting.
    • Core does not re-deliver the certificate to the device.
    • With prior versions of Mobile@Work, Core redelivered the certificate.

These improvements are especially significant when Core has many registered devices, each with many AppConnect apps.

The device user experiences improved launch time when launching an AppConnect app other than the first AppConnect app. The improvement is because:

  • The app does not have to wait for Core to deliver the certificate.
  • The app does not have to wait for Core to generate the certificate when non-certificate fields have changed.

Related topics

Certificate generation time