Product Documentation

About XenMobile PKI

Mar 14, 2014

The XenMobile Public Key Infrastructure (PKI) Integration feature allows you to manage the distribution and lifecycle of security certificates used on your devices.

The main feature of the system is the PKI Entity. A PKI entity models a back-end component for PKI operations. That component may be either local to XenMobile (internal) or a part of your corporate infrastructure (external, such as a Microsoft, RSA or OpenTrust PKI). The PKI entity handles the back-end certificate issuance and revocation. It is the authoritative source for the certificate’s status. The XenMobile configuration will normally contain exactly one PKI Entity per back-end PKI component.

The second feature is the Credential Provider. A Credential Provider is a particular configuration of certificate issuance and lifecycle. It will control things like the certificate’s format (subject, key, algorithms) and the conditions for its renewal or revocation, if any. The Credential Providers delegate operations to the PKI Entities. In other words, although Credential Providers control when and with what data PKI operations are undertaken, PKI Entities control how those operations are performed. The XenMobile configuration will normally contain many Credential Providers per PKI Entity.

The third feature of the system are Server Certificates. Server Certificates are X.509 certificates used functionally by the PKI Entity or the Credential Provider configurations.

Server Certificates

Server certificates are certificates used functionally by the XenMobile server that are uploaded to the Device Manager web console in the PKI integration section. They include Certificate Authority (CA) certificates, Registration Authority (RA) certificates, and certificates for client authentication with other components of your infrastructure. In addition, you may use server certificates as a storage for certificates you wish to deploy to devices. This will especially apply to CAs used to establish trust on the device.

XenMobile may or may not possess the private key for a given certificate. In some cases, XenMobile will require the private key; whereas for others, it will not. Each certificate you upload will be represented by an entry in the Server Certificates table, summarizing its contents. Later, when you configure PKI integration components that require a certificate, you will be prompted to choose from a list of those Server Certificates that satisfy the context-dependent criteria.

For example, you might want to configure XenMobile to integrate with your Microsoft CA. The connection to the Microsoft CA should be authenticated using a client certificate.

You can upload the CA certificate (without the private key) that the CA will use to sign requests and an SSL client certificate (with the private key) for client authentication. When configuring the Microsoft CA entity, you need specify the CA certificate, which you can then select from a drop-down list with all Server Certificates that are CA certificates. Likewise, when configuring client authentication, you can select from a drop-down list with all the Server Certificates for which XenMobile has the private key.

To import a server certificate

XenMobile supports the following input formats for certificates:

  • PEM or DER-encoded certificate files
  • PEM or DER-encoded certificate files with associated PEM or DER-encoded private key file
  • PKCS#12 key stores (P12; also known as PFX on Windows)
  • Java Key Store (JKS) and Extended Java Key Store (EJKS)

Key stores, by design, can contain multiple entries, so when loading from a key store, you will be prompted to specify the entry alias identifying the entry you wish to load. If you do not specify an alias, the first entry from the store will be loaded. Since PKCS#12 files usually contain only one entry, you should leave the alias empty for those files.

When importing a certificate, either from a file or a key store entry, XenMobile will attempt to construct a certificate chain from the input, and will import all certificates in that chain (creating a Server Certificate entry for each). This will only work if the certificates in the file or key store entry really do form a chain, such as if each subsequent certificate in the chain is the issuer of the previous one. You can add an optional description for the imported certificate for heuristic purposes. The description will only be attached to the first certificate in the chain. You can update the description of the remainders later.

  1. From the Device Manager web console, click Options.
  2. In the XenMobile Server Options dialog box, from the left side, select PKI > Server Certificate.
  3. Click Upload Certificate to import a certificate.
  4. From the Certificate Type list, select either Certificate or Keystore.
  5. Click Choose File to select a certificate.
  6. Click Choose File to select a private key file for the certificate.
  7. Enter an optional description and then click Upload.

Updating a Certificate

XenMobile only allows one certificate per public key to exist in the system at any given time. If you attempt to import a certificate for the same key pair as an already imported one, you will be presented with the option to either replace the existing entry or to delete it.

To most effectively update your certificates, simply upload the new one in the Device Manager web console Options dialog box, under PKI > Certificates. When a Server Certificate entry is updated, components that were using the previous one will automatically switch to using the new one. Likewise, if you have deployed the Server Certificate on devices, it will automatically be updated on the next deployment.

PKI Entities

A XenMobile Public Key Infrastructure (PKI) Entity configuration represents a component performing actual PKI operations (issuance, key escrow, revocation, and status information). These components may either be internal to XenMobile, in which case they are called discretionary, or external to XenMobile if they are part of your corporate infrastructure.

XenMobile supports the following three types of PKI entities:
  • Discretionary CAs
  • Generic PKIs (GPKI)
  • Microsoft Certificate Services

Common PKI Concepts

Regardless of its type, every PKI entity has a subset of the following capabilities:
  • sign Issuing a new certificate, based on a Certificate Signing Request.
  • fetch Recovering an existing certificate and key pair.
  • revoke Revoking a client certificate.
Table 1. PKI Capabilities
PKI Type Capability
Discretionary Sign
PKI The adapter is capable of taking Certificate Signing Requests (CSRs), transmitting them to the PKI, and returning newly signed certificates.
Microsoft Sign

About CA Certificates

When configuring a PKI entity, you will have to inform XenMobile which CA certificate is going to be the signer of certificates issued by (or recovered from) that entity. One and the same PKI entity may return (fetched or newly signed) certificates signed by any number of different CAs; the certificate of each of these CAs will have to be provided as part of the PKI entity configuration, by uploading it to the Server Certificates repository and then referencing them in the PKI entity. For discretionary CAs, this will implicitly be the signing CA certificate, but for external entities, you will have to specify it manually.

Note: XenMobile will verify that the actual issuer of a certificate newly obtained through a sign or fetch operation matches the purported, configured issuer. An error will be raised if this is not the case.

Discretionary CAs

A discretionary CA is created by providing XenMobile with a CA certificate and the associated private key. XenMobile will handle certificate issuance, revocation, and status information internally, according to the parameters you specify. However, XenMobile will never store the private keys of issued certificates, and so will not offer escrow services. Status information for certificates issued by a discretionary CA.

When configuring a discretionary CA, you will have the option to activate OCSP support for that CA. If, and only if, OCSP support is enabled, the CA will add an id-pe-authorityInfoAccess extension to the certificates it issues, pointing to the XenMobile internal OCSP Responder at the following location.

https://[server]/[instance]/ocsp

When configuring the OCSP service, you will have to specify an OCSP signing certificate for the discretionary entity in question. You can use the CA certificate itself as the signer. If you wish to avoid the unnecessary exposure of your CA private key (recommended), you will have to create a delegate OCSP signing certificate, signed by the CA certificate and include an id-kp-OCSPSigning extendedKeyUsage extension.

The XenMobile OCSP responder service supports basic OCSP responses and the following hashing algorithms in requests:
  • SHA-1
  • SHA-224
  • SHA-256
  • SHA-384
  • SHA-512

Responses are signed with SHA-256 and the signing certificate key algorithm (DSA, RSA or ECDSA).

Generic PKI (GPKI)

The Generic PKI (GPKI) protocol is a proprietary XenMobile protocol running over a SOAP Web Service layer for purposes of uniform interfacing with various PKI solutions. The GPKI protocol defines the following three fundamental PKI operations:
  • sign. The adapter is capable of taking Certificate Signing Requests (CSRs), transmitting them to the PKI, and returning newly signed certificates.
  • fetch. The adapter is capable of retrieving (recovering) existing certificates and key pairs (depending on input parameters) from the PKI.
  • revoke. The adapter is able to cause the PKI to revoke a given certificate.

The receiving end of the GPKI protocol is the GPKI adapter. The adapter translates the fundamental operations to the specific type of PKI for which it was built. In other words, there is a GPKI adapter for RSA, another for OpenTrust, and so on.

Figure 1. GPKI Communication Overview


The GPKI adapter, as a SOAP Web Services endpoint, publishes a self-describing WSDL. Creating a GPKI PKI entity amounts to providing XenMobile with that WSDL, either through a URL or by uploading the file itself.

Support for each of the PKI operations in an adapter is optional. If an adapter supports a given operation, it is said to have the corresponding capability (sign, fetch, or revoke). Each of these capabilities may be associated with a set of user parameters.

User parameters are parameters that are defined by the GPKI adapter for a specific operation and for which you need to provide values to XenMobile. Which operations the adapter supports (which capabilities it has) and which parameters it requires for each of them is determined by XenMobile by parsing the WSDL. The connection between XenMobile and the GPKI adapter may optionally be secured by using SSL client authentication.

Microsoft Certificate Services

XenMobile interfaces with Microsoft Certificate Services through its web enrollment interface. It only supports the issuing of new certificates through that interface (the equivalent of the GPKI sign capability).

To create a Microsoft CA PKI entity in XenMobile , you must specify the base URL of the Certificate Services web interface. The connection between XenMobile and the Certificate Services web interface may optionally be secured by using SSL client certificate authentication.

Note: This integration method is historical and limited. It will be migrated to the GPKI protocol in the future.

Migrating Previous PKI Configurations

Since the new XenMobile PKI integration capabilities have been significantly enhanced, migrating to the new system is not automatic. If you had used PKI configurations in previous versions, you will be able to continue to use those versions in 8.0 without changes. If you want to make use of the new capabilities, you will have to manually upgrade existing PKI entities.

Your pre-8.0.1 PKI entities (Microsoft CA or GPKI) will appear in the list of PKI entities, but will be marked as not ready to be used, indicated by a red icon in the Valid column in the Options dialog box, under PKI > Entities.

To prepare the entity for 8.10 usage, edit the entity and provide the missing settings. The system will indicate which settings are missing when you try to save the configuration. This process requires providing one or more CA certificates for the entity.

Credential Providers

Credential providers are the actual configurations you will use in the various parts of the XenMobile system. They define the sources, parameters, and lifecycles of your certificates, whether these are part of device configurations or standalone - that is, pushed as is to the device.

Figure 2. Certificates Lifecycle


The certificate lifecycle is constrained by the device enrollment. That is, no certificates are issued before enrollment, although some may be issued as part of enrollment. In addition, certificates issued within the context of one enrollment are revoked when the enrollment is revoked; that is, no certificate remains valid after the management relationship. The enrollment, has been terminated.

One Credential Provider configuration may be used in multiple places, to the effect that configuration may govern any number of certificates at the same time. The unity, then, is on the deployment resource and the deployment. If the Credential Provider P is deployed to device D as part of the configuration C, then the issuance settings for P will determine the certificate that is deployed to D, its renewal settings will apply when C is updated, and its revocation settings will apply when C is deleted or D is revoked.

With the aforementioned in mind, the Credential Provider configuration does the following:
  • Determines the source of certificates.
  • Determines the method using which certificates are obtained. Signing a new certificate or fetching (recovering) an existing certificate and key pair.
  • Determines the parameters for the issuance or recovery. For example, CSR parameters, such as key size, key algorithm, distinguished name, certificate extensions, and so on.
  • Determines the manner in which certificates are delivered to the device.
  • Determines revocation conditions. While all certificates are revoked when the management relationship is severed, the configuration may specify an earlier revocation; for instance, when the associated device configuration is deleted. In addition, under some conditions, the revocation of the associated certificate in XenMobile may be sent to the back-end PKI; that is, its revocation in XenMobile may cause its revocation on the PKI.
  • Determines renewal settings. Certificates obtained through a given Credential Provider may be automatically renewed when they near expiration, or, separately from that, notifications may be issued when that expiration approaches.

To what extent various configuration options are available will mainly depend on which type of PKI Entity and issuance method are selected for a Credential Provider.

Methods of Certificate Issuance

There are two fundamental methods of obtaining a certificate, which in this context are referred to as methods of issuance:
  • SIGN. With this method, the issuance involves creating a new key pair, creating a Certificate Signing Request (CSR) for the key pair, and submitting it to a CA for signature.
  • FETCH. With this method, the issuance (from the point of view of XenMobile) is in actuality a recovery of an existing certificate and key pair.

A Credential Provider uses exactly one of these methods; the method that is selected impacts the configuration options that are available. Notably, CSR configuration and distributed delivery are only available if the issuing method is sign. If the certificate is fetched, it is always sent as a PKCS#12 to the device (equivalent to centralized delivery mode for the sign method).

The issuing methods that are available for a Credential Provider also depend on the capabilities the PKI Entity it uses supports.

Certificate Delivery

The delivery of certificates is independent of the issuance, although it only applies when the issuing mode is newly issued (sign), not recovered (fetch] from the PKI.

Two modes of certificate delivery are available: centralized and distributed. Distributed mode uses the SCEP protocol and is only available in situations where the client supports the protocol. Distributed mode is even mandatory in some situations.

For a Credential Provider to support distributed (SCEP-assisted) delivery, a special configuration step is necessary: Setting up Registration Authority (RA) certificates. Those are required because when using the SCEP protocol, XenMobile acts like a delegate (a registrar) to the actual CA,and must prove to the client that it has the authority to act as such. That authority is established by providing XenMobile with the aforementioned certificates.

Two distinct certificate roles are required (although one and the same certificate can fulfill both requirements): RA signature and RA encryption. The constraints for these roles are as follows:
  • The RA signing certificate must have the X.509 key usage digital signature.
  • The RA encryption certificate must have the X.509 key usage key encipherment

To configure the Credential Provider RA certificates, you must upload them to the Server Certificates repository and then link to them in the Credential Provider.

A Credential Provider is considered to support distributed delivery if, and only if, it has a certificate configured for each of the aforementioned roles. Each Credential Provider can be configured to either prefer centralized mode, to prefer distributed mode, or to require distributed mode. The actual result will depend on the context: If the context does not support distributed mode, but the Credential Provider requires it, deployment will fail. Likewise, if the context mandates distributed mode, but the Credential Provider does not support it, deployment will fail. In all other cases, the preferred setting will be honored.

Table 2. SCEP Distribution Availability
Context SCEP supported SCEP required
iOS Profile Service yes yes
iOS MDM enrollment yes no
iOS configuration profiles yes no
SHTP    enrollment no no
SHTP configuration no no
Windows Phone enrollment no no
Windows Phone configuration no no

Certificate Revocation

There are three types of revocation.
  • Internal revocation. Internal revocation affects the certificate status as maintained by XenMobile. This status is taken into account when XenMobile evaluates a certificate presented to it, or when it has to provide OCSP status information for some certificate. The Credential Provider configuration determines how this status is affected under various conditions. For instance, the Credential Provider may specify that certificates obtained through it should be flagged as revoked when they have been deleted from the device.
  • Externally propagated revocation. Also known as Revocation from XenMobile, this type of revocation applies to certificates obtained from an external PKI, and means that the certificate will be revoked on the PKI when it is internally revoked by XenMobile, under the conditions defined by the Credential Provider configuration. The call to perform the revocation requires a revoke-capable GPKI Entity.
  • Externally induced revocation. Also known as Revocation from PKI, this type of revocation also only applies to certificates obtained from an external PKI, and means that whenever XenMobile evaluates a given certificate status, it will query the PKI as to that status, and, if the PKI returns that the certificate is revoked, will internally revoke it. This mechanism uses the OCSP protocol.

These three types are not exclusive, but rather apply together: The internal revocation is caused either by an external revocation or by independent findings, and in turn it potentially effects an external revocation.

Certificate Renewal

A certificate renewal is the combination of a revocation of the existing certificate and an issuance of another certificate.

Note that XenMobile will first attempt to obtain the new certificate before revoking the previous one, in order to avoid discontinuation of service if the issuance fails. If distributed (SCEP-supported) delivery is used, the revocation will also only happen once the certificate has been successfully installed on the device; otherwise, the revocation will occur before the new certificate is sent to the device and independently of the success or failure of its installation.

The revocation configuration requires that you specify a certain duration (in days). When the device connects, the server verifies whether the certificate NotAfter date is later than the current date, minus the specified duration. If it is, a renewal is attempted.

To create a Credential Provider using discretionary CA entities

Configuring a Credential Provider varies mostly as a factor of which issuing entity and which issuing method are selected for it. You can distinguish between a Credential Provider using an internal entity, such as discretionary, and a Credential Provider using an external entity, such as Microsoft CA or GPKI. The issuing method for a discretionary entity is always sign, meaning that with each issuing operation, Device Manager will sign a new key pair with the CA certificate selected for the entity. Whether the key pair is generated on the device or on the server will depend on the selected distribution method.

  1. In the Device Manager web console, click Options.
  2. In the Options dialog box, select PKI > Credential Provider.
  3. In the Define a new credential provider dialog box, on the General tab, enter the following information:
    1. Credential Provider name. Type a unique name for the new provider configuration. This name will be used subsequently to refer to the configuration in other parts of the Device Manager console.
    2. Description. Enter an optional description for the configuration.
    3. Issuing method. Select a discretionary entity to server as the method that the system should use to obtain certificates from the configured entity.
  4. On the CSR tab, configure the parameters for the key pair that will be created during issuance, as well as the parameters of the new certificate.
    1. Key algorithm. The key algorithm for the new key pair. Available values are RSA, DSA and ECDSA.
    2. Key size. The size, in bits, of the key pair. Note that the valuesthat are permissible depends on the type of key; for instance, the maximum size for DSA keys is 1024 bits. To avoid false negatives, which will depend on the underlying hardware and software, Device Manager will not enforce key sizes. You should always test Credential Provider configurations in a test environment before activating them in production.
    3. Signature algorithm. The signature algorithm for the new certificate. Values are dependent on the key algorithm; in this case, Device Manager will limit your choices to matching values.
    4. Subject name. The Distinguished Name (DN) of the new certificate’s subject. For example: CN=${user.username}, OU=${user.department}, O=${user.companyname}, C=${user.c}\endquotation
    5. Subject alternative names. X.509 subject alternative names. To create a new entry, click New alternative name and then click the first column to select the type of alternative name. Enter a value in the second column. Note that, as for the subject DN, you can use Device Manager macros in the value field.
  5. Click the Distribution tab.

    Because the Credential Provider uses a discretionary CA entity, the CA certificate for the Credential Provider will always be the CA certificate configured on the entity itself; it will be presented here for consistency with configurations that use external entities.

    The second element on this tab is the configuration of certificate delivery. If you have defined RA certificates at the entity level, they will be filled by default here, but you can change them. The constraints on RA certificates still apply.

    You can select the delivery mode for certificates obtained from this entity. If you select the Prefer centralized delivery mode, RA certificates are optional; otherwise, they are mandatory.

  6. Click the Revocation tab.

    Configure under what conditions Device Manager should internally flag certificates, issued through this provider configuration, as revoked. You can also instruct the system to send a notification when it flags a certificate as revoked. To do so,elect a template for the event type Certificate revoke. Device Manager will create a default template for that type, but you can edit it or create others. Note that the revocation configured here will be what determines the responses from the Device Manager OCSP Responder for certificates created with this configuration, if OCSP support is enabled for the PKI Entity.

  7. Next, click the Renewal tab. Configure the renewal of certificates obtained through this configuration. Two basic operations can be configured:
    1. Renewing the certificate, optionally sending a notification when this is done (notification on renewal), and optionally excluding already expired certificates from the operation. Note that "already expired" in this case means that their NotAfter date is in the past, not that they already have been revoked. Device Manager will not renew certificates once they have been internally revoked.
    2. Issuing a notification for certificates that near expiration notification before renewal.

      To have notifications sent for either case, simply specify a Notification Template for the appropriate event type. The event type for the former is Certificate is renewed; for the latter, Certificate will expire. Device Manager will create default Notification Templates for both these event types, but you can modify them or create new ones.

      Note that renewal takes precedence over notification before renewal. That is, if, at a given moment, Device Manager determines that a certificate must be renewed, it will not also send a notification before renewal. Instead, the notification on renewal, if any configured, will be used. You should configure a greater period for the notification before renewal if you imperatively need both to be sent. Notifications before renewal will only be sent at most one time for a given certificate.

  8. Click Create.

To create a Credential Provider using external PKI entities

When you create a Credential Provider using external Microsoft or GPKI entities, the main difference in configuring the two is the issuing method for the provider. The methods that are available also depends on the capabilities of the selected PKI entity according to the following scenarios:

  • If you opt for using a Microsoft CA entity for your Credential Provider, your choice of issuing method will be limited to sign. The sign method of issuance involves creating a new key pair, creating a Certificate Signing Request (CSR) for the key pair, and submitting it to a CA for signature. You will be prompted to select which certificate template to use for issuance. You must choose a value from those you have defined during the creation of the PKI entity. This is the template name that will be sent to the Microsoft CA along with the CSR during issuance. A Credential Provider can only use one template. If you want to issue certificates based on different templates, create a Credential Provider configuration for each of them.
  • If you opt for using a GPKI entity for your Credential Provider, your choice of issuing method will depend on which capabilities are supported by the adapter. If the GPKI adapter defines user parameters for the selected capability, you will be presented with an interface to specify values for each of those. The parameters are specific to a capability; different capabilities have different sets of user parameters.
Note: For information on configuring Microsoft Certificate Services to work with Device Manager, see Configuring Device Manager with Microsoft Active Directory Certificate Services.
  1. In the Device Manager web console, click Options.
  2. In the Options dialog box, select PKI > Credential Provider.
  3. In the Define a new credential provider dialog box, on the General tab, enter the following information:
    1. Credential Provider name. Type a unique name for the new provider configuration. This name will be used subsequently to refer to the configuration in other parts of the console.
    2. Description. An optional description for the configuration.
    3. Issuing method. The method that the system should use toobtain certificates from the configured entity. Select a Microsoft GPKI entity.
  4. On the CSR tab, you can configure the parameters for the key pair that will be created during issuance, as well as the parameters of the new certificate:
    1. Key algorithm. The key algorithm for the new key pair. Available values are RSA, DSA and ECDSA. .
    2. Key size. The size, in bits, of the key pair. Note that the values that are permissible depends on the type of key; for instance, the maximum size for DSA keys is 1024 bits. To avoid false negatives, which will be dependent on the underlying hardware or software, Device Manager will not enforce key sizes. You should always test Credential Provider configurations in a test environment before activating them in production.
    3. Signature algorithm. The signature algorithm for the new certificate. Values are dependent on the key algorithm; in this case, Device Manager will limit your choices to matching values.
    4. Subject alternative names. To create a new entry, click New alternative name and then click the first column to select the type of alternative name. Then, enter a value in the second column. Note that, as for the subject DN, you can use Device Manager macros in the value field.
  5. Click the Distribution tab.

    Specify the issuer CA of the certificates returned by the PKI entity in the configuration you have selected. You can choose one of the CA certificates defined on the entity. If the issuing method for this Credential Provider is sign, you can configure the delivery method, because the fetch method retrieves the key pair from the PKI server . Therefore, there is no key generation involved; distributed key generation is not available with that method.

  6. Click the Revocation XenMobile tab. Configure the conditions and actions for the internal revocation of certificates. You can choose to have certificates revoked under any combination of the following conditions:
    1. When they are removed from the device, that is, either when the system detects that they have been removed from the device without server interaction, or when the server has removed them subsequent to the scheduling of a removal command.
    2. hen they are updated on the device, that is, when they are replaced with a newer certificate for the same function.
    3. When the enrollment is revoked by the administrator.
    4. When the device is deleted.

    You can further opt to have a notification sent when the revocation action is undertaken. To do so, configure a notification template for the appropriate event type.

    In addition to these conditions, because the certificates obtained through this configuration will have come from an external source, you can opt to propagate the revocation status externally. The propagation is achieved by using a GPKI entity with the revoke capability. The interface will display a list of revoke-capable GPKI entities that exist in the system. If the selected entity defines user parameters for the revoke operation, you will be prompted to enter values for them. You can use Device Manager macros for the values.

  7. Click the Revocation PKI tab.

    Configure the system to perform external certificate status checks for certificates issued through this CredentialProvider configuration. The checks are performed using the OCSP protocol and take place when a deployment is initiated. For the checks to occur, the back-end PKI must insert corresponding OCSP responder address extensions (ASN.1 OID: 1.3.6.1.5.5.7.1.1) in the certificates it issues. If that is not the case, the setting will be silently ignored.

    As part of the OCSP protocol, the initiator of the OCSP request (in this case, XenMobile) must be able to validate the OCSP responder (likely your PKI server) signing certificate. To that effect, as part of the external revocation check configuration, you must specify the CA certificate of your PKI OCSP Responder signing certificate. The CA certificate must be uploaded to the Server Certificates repository so that you can select it in the drop-down list. Its private key is not required for this purpose.

    Note that OCSP Responder certificates are usually either the CA certificate itself (that is, the CA that signed the certificate the status of which is queried), or a certificate signed directly by that CA. It that sense, specifying that CA certificate in this section will usually be adequate.

    You can further define what actions XenMobile should undertake in the event that the OCSP verification yields a status indicating that the certificate in question was revoked. If that is the case, you can opt to take the following actions:

    • Do nothing.
    • Remove the corresponding configuration from the device; that is, the configuration the certificate in question was deployed as part of.
    • Revoke the enrollment and wipe the device.

    In addition to the action you chose, you can choose to have a notification sent by selecting a notification template for the appropriate event type. The external revocation and the internal revocation configured in the tab preceding this tab are complementary. If the external revocation check yields a revoked status and you have opted, for instance, to revoke the entire enrollment, the settings you have specified on the Revocation XenMobile tab will apply to all other certificates present on the device. The same situation holds true for all certificates that were part of the same configuration, if you have chosen to remove the configuration the certificate was deployed as a part of.

  8. Click the Renewal tab.
    Configure the renewal of certificates obtained through this configuration. You can configure the following basic operations:
    • Renewing the certificate, optionally sending a notification when this is done (notification on renewal), and optionally excluding already expired certificates from the operation. Note that "already expired" in this case means that their NotAfter date is in the past, not that they already have been revoked. XenMobile will not renew certificates once they have been internally revoked.
    • Issuing a notification for certificates that near expiration (notification before renewal).

    To have notifications sent for either case, simply specify a Notification Template for the appropriate event type. The event type for the former is Certificate is renewed; for the latter, Certificate will expire. XenMobile will create default Notification Templates for both these event types, but you can modify them or create new ones.

    It is important to note that renewal takes precedence over notification before renewal. That is, if XenMobile determines that a certificate must be renewed, it will not also send a notification before renewal (instead, the notification on renewal, if any configured, will be used). You should configure a greater period for the notification before renewal if you imperatively need both to be sent. Notifications before renewal will only be sent at most one time for a given certificate.

  9. Click Create.