UCSC Digital Certificate Policy
DRAFT DRAFT DRAFT
UCSC Digital Certificate Policy - 2013 Revision
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, and validity 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.
- A. Wildcard, SAN, and UCC Certificates
- B. Self-Signed Certificates
- C. Private Key Management
- D. Renewing, Replacing and Revoking Certificates
- E. ITS Certificate Service
- No one may own or manage a wildcard certificate for the campus domain (*.ucsc.edu)
- Wildcard certificates are not permitted on sub-domains that handle restricted data
- Units may obtain wildcard certificates for their sub-domain(s) and servers (e.g. *.mydomain.ucsc.edu)
- 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.
- Units should obtain Subject Alternative Name (SAN) or Unified Communication Certificate (UCC) (aka Multi-Domain certificates) instead of wildcard certificates, where feasible
- 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
System Stewards/Data Owners, in consultation with Service Providers, are responsible for assessing the appropriateness of wildcard certificates for their systems/applications based on risk, sensitivity of information, and adherence to law, regulations, and policy.
Self-signed certificates are not allowed, except as defined in Section III, Exceptions.
- 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
- When an employee who has access to private keys protecting restricted data leaves the organization, private keys and associated certificates must be replaced
- Certificates must be renewed or replaced before expiration
- 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
All University-related certificates must be issued by the ITS Certificate Service. Exceptions may be granted for technical, legal, regulatory or contractual requirements. Please see Section III, "Exceptions".
A. The campus Information Security Officer (ISO) has the authority to approve exceptions to this policy. Proposed exceptions must be reviewed by the IT Security Team and their analysis submitted to the ISO along with exception requests.
B. Exceptions may be allowed based on one or more of the following:
- Technical, contractual, or vendor requirements
- Temporary development on a host that is not customer-facing
- Factory-installed certificates on devices that are not customer-facing
C. Where exceptions are requested to the use of the ITS Certificate Service, the requester will document in the exception request if the proposed Certificate Authority (CA) provides the following:
- 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
- CA root and intermediate certificates are recognized by ITS supported browsers and desktops
- CA verifies the applicant's credentials (e.g., requester is affiliated with UCSC)
For information about the ITS Certificate Service, to request a certificate, or to coordinate with the IT Security Team for exception processing and related security reviews, please see the Digital Certificate Service Page.
Server Certificate and Related Configuration Requirements
Please note: Requirements in this appendix are subject to change in response to changes in industry standards, law or UC/UCSC policy.
- Servers must be configured to require 256-bit encryption strength for session keys
- Minimum required certificate strength (modulus length): 2048-bit
- Servers must not allow Null or Anonymous Diffie Hellman (ADH) cyphers to be used in communication
- Keys for all systems should be regenerated and certificates re-signed annually
- Annual renewal is required for systems handling restricted data
- Certificates must expire after no longer than three years
- Servers must use SSLv3 or higher . TLS v1.0 or higher is preferred.
- The Common Name (CN) and the SAN must contain domain information
- The subject Distinguished Name (DN) email address should be valid for the lifetime of the certificate
Certificates issued through the ITS Certificate Service meet the applicable requirements in this appendix. The ITS Certificate Service enables you to obtain certificates at no cost to you or your department.
 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.
 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. 5/29/13