has been upgraded to Confluence 6.6.0. If you have any questions and/or concerns, please contact us at
Page tree
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 12 Next »

Client Certificates: A Technical Perspective

This document gives a technical perspective on client certificates for account administrators, campus support personnel, and others involved in the management, deployment, and support of client certificates. For a high-level perspective on client certificates, please visit our web site. See the InCommon Certificate Types wiki page for detailed information on all types of certificates, including client certificates, issued by the InCommon Certificate Service.


Technical Considerations

Initially, one or more RAOs from each organization will be given the ability to manage client certificates. Before a RAO can issue client certificates, a decision regarding key escrow must be made. Key escrow (also known as "key recovery" in the CSM) is available to all subscribers of the InCommon Certificate Service for no additional fee.

Important Note

All current organizations have key escrow enabled. The only way to change this is to create a new organization instance in the CSM.

InCommon made the decision about key escrow many months in advance of deploying client certificates, when SSL was the only service in operation and the key escrow functionality in CSM was still in its infancy. Since we didn't want to disable potentially useful functionality for an entire organization's life cycle, we chose to enable escrow for all organizations.

Enabling or disabling key escrow for organizations or departments has the following consequences:

  • The decision whether to enable or disable key escrow for an organization (resp., department) is made when the organization (resp., department) is created. The decision regarding key escrow is final and cannot be subsequently modified.
  • If key escrow is enabled for an organization, client certificates can not be issued until a RAO initializes the key escrow database for the organization. The importance of this one-time operation can not be overemphasized.
  • As RAOs create new departments, an independent decision is made whether or not to enable key escrow for the department. If key escrow is enabled for the department, client certificates can not be issued until a DRAO initializes the key escrow database for that department. The initialization process for the department is exactly the same—and just as important—as it is for the organization.

A Note about Organizations and Departments in the CSM

In the CSM, the organization and department constructs do not constitute a parent/child hierarchy. Organization settings are settings that apply to issued certificates when no department is specified. Department settings are independent of organization settings. Consequently, for example, an organization may or may not have key escrow enabled, but this is completely independent of whether or not any particular department has key escrow enabled. As another example, just as only one key usage template may be applied to a department, so only one key usage template may be applied to an organization. In many ways, an organization is just another department, at least in the CSM.

Key Usage

Three key usage types of Standard Assurance Client Certificates are available to subscribers:

  1. signing-only client certificates
  2. encryption-only client certificates
  3. dual-use client certificates

The key usage type of a particular Standard Assurance Client Certificate is specified in the critical X509v3 Key Usage certificate extension (Digital Signature, Key Encipherment, or both). Other than that, all Standard Assurance Client Certificates are structurally identical.

The various key usage types permit different approaches to key escrow, which is applicable to encryption keys but not signing keys. In addition to signing and/or encryption, any Standard Assurance Client Certificate may be used for SSL/TLS client authentication regardless of the key usage type. Be aware, however, that we expect dual-use client certificates to work with the widest variety of software implementations. Consequently, organizations are strongly encouraged to test the compatibility of Standard Assurance Client Certificates, especially signing-only and encryption-only client certificates, with relevant devices and software prior to deployment.

Key Usage Templates

If an organization is to issue client certificates, the MRAO assigns one key usage template (KUT) to that organization. Likewise if a department is to issue client certificates, the RAO assigns one KUT to that department. Thus only one KUT can be configured per organization or department. This means, for example, that if your Physics department wishes to use two types of certificates (e.g., signing-only and encryption-only), then you will have to create two departments in the CSM, something like "Physics-Signing" and "Physics-Encryption." Alternatively, depending on your deployment requirements, you may wish to architect your departments by function rather than by academic unit. For example, you could create three departments for the entire campus, say, "Standard Signing Cert," "Standard Encryption Cert," and "Standard Dual-Use Cert." How you create your departments is of course up to you.

Key Escrow

Key escrow provides for offline storage of users' private keys in an encrypted database for the purposes of backup and recovery. Once an escrow database is created for an organization or department, it cannot be removed from the system or made inactive.

Initializing Key Escrow

If an RAO is given permission to issue client certificates, and the organization is configured for key escrow, the next time that RAO logs into the CMS, s/he will be prompted to initialize a database of encryption keys. Upon doing so, a master decryption key will be issued to the RAO. The RAO should immediately take steps to secure the master decryption key. Failure to do so will render the key escrow feature useless.

By all means protect your master decryption key! If the master key is compromised, the confidentiality of all encrypted data may likewise be compromised. If the master key is lost or stolen, you will lose the ability to recover individual decryption keys and may therefore be unable to decrypt previously encrypted data. Neither InCommon nor Comodo have access to the encrypted escrow databases. The decryption key that the campus administrator takes possession of at the time of creation is the sole copy. No master key is the same as no key escrow at all!

If the RAO does not initialize the database of encryption keys upon first login, s/he will be prompted to do so every time s/he logs into the CMS. If multiple RAOs are given permission to issue client certificates, all of them will be prompted to initialize the database of encryption keys. The first RAO that does so will be issued the master decryption key.

Key escrow for organizations has no bearing on whether or not key escrow is subsequently enabled for departments. Consequently, if a DRAO is given permission to issue client certificates, and the department is configured for key escrow, exactly the same initialization process as described above will take place. Moreover, this will happen for every department that is configured for key escrow.

Issuing Client Certificates

There are numerous ways to issue client certificates:

  1. As an RAO/DRAO using the web-based Certificate Services Manager
  2. Via CSV upload
  3. Via web-based Enrollment form
  4. Via the API
  5. Via Active Directory linkage

These methods are described in the Administrator Guide.

  • No labels