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

One or more RAOs from each organization will be given the ability to manage client certificates. If a department is to issue client certificates, the RAO assigns one key usage type template to that department. If the organization is configured for key escrow, the RAO delegates escrow capabilities to DRAOs on a department by department basis.

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 (KUT) 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, a service typically applies 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.

KUT Templates

Only one KUT template can be configured per Department (or Organization, for that matter). 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 certificate function rather than by academic unit. An example of this would be to 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 up to you of course.

Key Escrow

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

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.

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.