Product Documentation

To create a credential provider using discretionary CA entities

Dec 21, 2015

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 Credential Provider using an internal entity, such discretionary, and those using an external entity, such as Microsoft CA or GPKI.

This task shows you how to create a discretionary entity. 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 administration console.
    2. Description. An optional description for the configuration.
    3. Issuing method. The method that the system should obtain certificates from the configured entity. Select a discretionary entity.
  4. On the CSR tab, you configure the parameters for the key pair that will be created during issuance, as well as the parameters of the new certificate. Enter the following information:
    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 which values 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 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 on New alternative name and then click on the first column to select the type of alternative name from those available. Last, 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. Next, click on 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 mere 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 if you desire (but that the constraints on RA certificates still apply).

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

  6. Next, click on the Revocation tab. In this tab, you can configure under what conditions Devce 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. Do this by selecting 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 on the Renewal tab. In this tab, you can 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 once for a given certificate.

  8. Click Create.