Product Documentation

PKI Entities

Apr 16, 2015

A XenMobile Public Key Infrastructure (PKI) Entity configuration represents a component performing actual PKI operations (issuance, key escrow, revocation, status information). These components may either by internal to XenMobile, in which case they’re called discretionary, or external to it, 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 is said to have 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, 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 XenMobile ’s internal OCSP Responder located at:


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’s private key (recommended), you will have to create a delegate OCSP signing certificate, signed by the CA certificate and including 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’s key algorithm (DSA, RSA or ECDSA).

Generic PKI (GPKI)

The Generic PKI (GPKI) protocol is a proprietary XenMobile protocol running atop a SOAP Web Service layer for purposes of uniform interfacing with various PKI solutions. The GPKI protocol defines three fundamental PKI operations:
  • sign The adapter is capable of taking Certificate Signing Requests (CSR), 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, being 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 using SSL client authentication.

Microsoft Certificate Services

XenMobile interfaces with Microsoft Certificate Services through its web enrollment interface. It only supports issuing 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 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 these in 8.0 without changes, but if you wish 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 ready 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 the CA certificate(s) for the entity.