Policy #: IT0006
Effective Date: 9/25/14
Last Revision Date: 3/16/15
UCSC Digital Certificate Policy
Vice Chancellor, Information Technology
- I. Introduction/Overview
- II. Detailed Policy Statement
- III. Conditions Requiring Additional Approval
- IV. Policy Authority
- V. Getting Help
- VI. Appendix: Configuration and Certificate Authority Requirements
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.
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
- 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) after appropriate consultation on risk with System Stewards/Data Owners and Service Providers
- Units should obtain Subject Alternative Name (SAN) or Unified Communication Certificate (UCC) (aka Multi-Domain certificates) instead of wildcard certificates, where feasible
- Requirements for management of private keys are listed under Sec II.C, "Private Key Management".
B. Self-Signed Certificates 
- Self-signed certificates are not allowed on systems with restricted data
- 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
- 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
- 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.
- 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
- Certificates must be renewed or replaced before expiration
- See Appendix A for specific renewal requirements
- 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 Digital Certificate Service. Additional approval is required for certificates issued outside of this service. Please see Section III, below.
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.
This policy has been issued under the authority of the campus Information Security Officer. Original issue date was 1/7/2010. Last update was March 2014. Next review date is March 2019.
For information about the ITS Digital Certificate Service, or to request a certificate, please see the Digital Certificate Service Page.
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
An exception is required if an implementation cannot meet these standards. Compensating controls may be required if an exception is granted.
- Implementations must meet Qualys SSL Labs "SSL/TLS Deployment Best Practices" described at https://www.ssllabs.com/downloads/SSL_TLS_Deployment_Best_Practices.pdf
- Note: The InCommon certificate service meets the CA requirements outlined in these Best Practices.
- Servers that achieve a "Grade A" or higher rating on the Qualys SSL Labs Server Test at https://www.ssllabs.com/ssltest/analyze.html are considered to meet these Best Practices.
IMPORTANT: Always check: "Do not show the results on the boards" when running the SSL Labs Server Test so results are not posted publicly.
- Re-validation/re-testing should be done at least annually.
- Significant findings from UCSC security scans must be addressed.
- 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.
B. Certificate Authorities (CA) must meet the following requirements:
- 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 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.
Last Rev. 3/16/15