UCSC Digital Certificate Policy

DRAFT       DRAFT       DRAFT

UCSC Digital Certificate Policy - 2013/14 Revision
Updated 3/5/14

I. INTRODUCTION/OVERVIEW

The purpose of this policy is to identify the appropriate use and implementation of digital certificates at UCSC, in support of UCSC's Minimum Network Connectivity Requirements.

Digital certificates ("certificates") are used to confirm identity, secure communications between parties, and ensure integrity of transmissions. The use of certificates is one method of encrypting restricted data while in transit over the network. This policy applies to digital certificates used in UCSC communications to secure data in transit.


II. DETAILED POLICY STATEMENT

This section outlines the acceptable use of digital certificates at UCSC. Additional strength, configuration, validity, and Certificate Authority (CA) requirements are included in the Appendix.

Requests for certificates that do not meet the requirements in this policy may be denied. Certificates that do not meet the requirements in this policy may be revoked.

Acceptable Use Requirements:

A. Wildcard, SAN, and UCC Certificates

  1. No one may own or manage a wildcard certificate for the campus domain (*.ucsc.edu)
  2. Wildcard certificates are not permitted on sub-domains that handle restricted data
  3. Units may obtain wildcard certificates for their sub-domain(s) and servers (e.g. *.mydomain.ucsc.edu) after appropriate consultation on risk with System Stewards/Data Owners and Service Providers
  4. Units should obtain Subject Alternative Name (SAN) or Unified Communication Certificate (UCC) (aka Multi-Domain certificates) instead of wildcard certificates, where feasible
  5. Units may not install the same private key on multiple hosts, except for clustered and load-balanced services. Where certificates are shared or span across multiple hosts, the security requirements of the most sensitive member prevail.
  6. The same private key and certificate should only be used with one set of restricted data (e.g., payment data, student data, health records, etc.), to reduce the risk of compromise across multiple data sets

B. Self-Signed Certificates [1]

  1. Self-signed certificates are not allowed on systems with restricted data
  2. Self-signed certificates are only allowed on systems without restricted data under the following circumstances:
    • Technical, contractual, or vendor requirements preclude using a certificate issued by a trusted Certificate Authority
    • Temporary development on a host that is not customer-facing
    • Factory-installed certificates on devices that are not customer-facing

C. Private Key Management

  1. Private keys must be protected to the same standard as IS-3 requires for the data the key is protecting. See IS-3 Protection Matrix
  2. When an employee who has access to private keys protecting restricted data leaves the organization, private keys and associated certificates must be replaced

D. Renewing, Replacing and Revoking Certificates

  1. Certificates must be renewed or replaced before expiration
    • See Appendix A for specific renewal requirements
  2. Certificates must be revoked when one or more of the following occur:
    • A private key has been compromised
    • The service is being retired or decommissioned
    • When the private key is no longer in use

E. ITS Certificate Service

All University-related certificates must be issued by the ITS Certificate Service. Additional approval is required for certificates issued outside of this service. Please see Section III, below.


III. CONDITIONS REQUIRING ADDITIONAL APPROVAL

Uses of digital certificates that do not comply with Sections II and VI of this policy must be approved and documented by the campus Information Security Officer (ISO). The ISO may require additional review in order to evaluate requests and/or implementation of compensating controls.


IV. POLICY AUTHORITY

This policy has been issued under the authority of the campus Information Security Officer. It has been operational since 1/7/2010. Last update was <<month>> 2014. Next review date is <<month>> 2017.


V. GETTING HELP

For questions about this policy, contact the ITS Support Center at 459-HELP, help@ucsc.edu, itrequest.ucsc.edu, or in person M-F 8AM-5PM, 54 Kerr Hall.

For information about the ITS Digital Certificate Service, or to request a certificate, please see the Digital Certificate Service Page.


VI. APPENDIX:

Please note: Requirements in this appendix are subject to change in response to changes in industry standards, law or UC/UCSC policy, as identified by UCSC’s Digital Certificate Service Team. The affected community will be notified of significant changes.

Certificates issued through the ITS Digital Certificate Service meet or support the requirements in this appendix and are available at no cost to UCSC individuals or departments.

A. Server Certificate and Related Configuration Requirements

  1. Servers must be configured to require AES 128-bit encryption strength for session keys; AES 256-bit encryption strength is recommended. [2]
  2. Minimum required certificate strength (modulus length): 2048-bit
  3. Servers must not allow Null or Anonymous Diffie Hellman (ADH) cyphers to be used in communication
  4. Certificate Renewal:
    • Keys must be regenerated and certificates re-signed when renewing a certificate
    • Annual renewal is required for systems handling restricted data
    • Certificates for systems that do not handle restricted data must be renewed after no longer than three years. It is recommended that all certificates be renewed annually.
  5. Servers must use SSLv3 or higher [3]. TLS v1.0 or higher is preferred.
  6. The Common Name (CN) and the SAN must contain domain information
  7. The subject Distinguished Name (DN) email address should be valid for the lifetime of the certificate

B. Certificate Authorities (CA) must meet the following requirements:

  1. CA can provide the following support through life of the certificate:
    • The ability to revoke a certificate
    • Retain the Certificate Signing Request (CSR) and ability to reissue the Certificate
    • Maintain a list of UCSC contacts authorized to administer or manage the certificate
    • Provide renewal notices
  2. CA root and intermediate certificates are recognized by ITS supported browsers and desktops
  3. CA verifies the applicant's credentials (e.g., requester is affiliated with UCSC)

Endnotes:
[1] For the purposes of this policy, "self-signed certificates" are certificates that are self-signed, or pre-signed by factory installation or vendor installation, and are not issued by a trusted Certificate Authority.
[2] This standard is based on NIST Special Publication 800-131A.
[3] See IT Request Knowledge Base Articles "SSL disable" (KB #15882) and "SSLv2 disable" (KB #16570) or contact the ITS Support Center for configuration information.


Last Rev. 3/5/14

DRAFT       DRAFT       DRAFT