UCSC Digital Certificate Policy

DRAFT       DRAFT       DRAFT

UCSC Digital Certificate Policy - 2013 Revision
Updated 4/24/13

CONTENTS:

I. INTRODUCTION/OVERVIEW
The purpose of this policy is to identify the appropriate use and implementation of digital certificates at UCSC [1].

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.

Requests for certificates that do not meet the requirements in this policy may be denied or subject to revocation.

II. DETAILED POLICY STATEMENT
This section outlines the acceptable use of digital certificates at UCSC. Additional strength, configuration, and validity requirements are included in Appendix A. Certificate Authority requirements are included in Appendix B. Requests for certificates that do not meet these requirements may be denied or subject to revocation. Application or vendor requirements shall not result in a reduction to the minimum requirements stated in this policy.

A. Wildcard 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) (e.g. *.mydomain.ucsc.edu)
  4. Units may not install the same private key on multiple hosts
  5. Units should obtain Subject Alternative Name (SAN) or Unified Communication Certificate (UCC) instead of wildcard certificates, where possible
  6. The same certificate should only be used with one set of restricted data (e.g., payment data versus authentication data), in order to reduce the risk of compromise across multiple data sets
  7. 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

B. Self-Signed Certificates
Self-signed web server certificates are only allowed when all the following apply:

  • Installation is on a non-production system, or on a production system with a constrained user base that can be informed of certificate requirements and changes. Examples of the latter include a system accessed by a small number of users, or a web server with client access restricted to a specific subdomain.
  • Clients must be instructed to install the certificate in their browser.
  • Users must be advised that a self-signed certificate is in use and provided with sufficient information to know how to respond to certificate errors or warnings
  • Restricted data is not involved

System/application administrators intending to use a self-signed certificate shall coordinate with the IT Security Team or the ITS Design Review Board (DRB) for assistance and approval. Systems/applications utilizing a self-signed certificate must be reviewed with the IT Security Team annually to ensure ongoing compliance with UCSC policy and mitigation of security concerns. Escalation is to the campus Information Security Officer (see Section III, Exceptions).

C. Private Key Management
Private keys must be protected to same degree as IS-3 requires for the data the key is protecting. Protecting the device storing the private key is sufficient to meet this requirement. Passwords are strongly recommended for private keys protecting restricted data. See IS-3 Protection Matrix

D. Renewing, Replacing and Revoking Certificates

  1. Certificates must be renewed or replaced before expiration
  2. When an employee who manages private keys of certificates changes their role/responsibility or leaves the organization, private keys and associated certificates must be replaced
  3. Certificates must be revoked when one or more of the following occur:
    • A certificate has been compromised
    • The service is being retired or decommissioned
    • When the private key is no longer in use

E. Where web server certs are shared or span across multiple hosts, the security requirements of the most sensitive member prevail.

III. EXCEPTIONS
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.

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. Next review date is <<month>> 2014.

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.

To coordinate with the IT Security Team exception processing and related security reviews, open an IT Request ticket with the details and supporting documentation: itrequest.ucsc.edu

For information about UCSC’s Digital Certificate Service, please see the Service Page.

VI. APPENDICES
Please note: Requirements in these appendices are subject to change in response to changes in industry standards, law or UC/UCSC policy.

-----------
Appendix A: Certificate and Related Server Configuration Requirements

  1. Minimum required data encryption strength: 256-bit
  2. Minimum required certificate strength (modulus length): 2048-bit
  3. Null and Anonymous Diffie Hellman (ADH) cyphers are not allowed
  4. Keys for all systems should be regenerated and certs re-signed annually [2]
    • Annual renewal is required for systems handling restricted data
    • Vendor-issued certificates must expire after no longer than three years
  5. Servers must be configured to accept SSLv3 or higher. Weak cipher connections are not allowed. See IT Request Knowledge Base Articles "SSL disable" (KB #15882) and "SSLv2 disable" (KB #16570) or contact the ITS Support Center for configuration information.
  6. Certificates must have fully qualified domain names (FQDN)
  7. Contact email (subject DN email address) should be valid for the lifetime of the certificate

-----------
Appendix B: Certificate Authority Requirements

UC Santa Cruz is now participating in the InCommon Certificate Service, which entitles the campus to unlimited certificates at no cost to campus users. This new service is sponsored and funded through the office of the Vice Chancellor for Information Technology (VC IT). Managed by the ITS Certificate Team, this service paves the way for easy and cost-effective distribution and tracking of certificates across the campus.

Campus members are expected to use the InCommon Certificate Service for all University-related certificates.

Certificates issued through InCommon are provided by the Comodo Certificate Authority and meet the requirements listed in Appendix A, above. Please do not order through Comodo directly, but rather use the InCommon Certificate Service so that you are able to obtain certificates at no cost to you or your department.

Non-InCommon Certificates:

An exception is required for certificates issued by any other certificate provider. Exceptions may be granted if there are technical limitations or legal, regulatory or contractual reasons why an InCommon Certificate cannot be used. Please see Section III, "Exceptions", in the policy, above. If you order a certificate through another certificate provider, the administrative point of contact may deny the order outright, or forward it on to the Campus Registration Authority Officer (RAO) for review.

In addition to requiring an exception, non-InCommon Certificate Authorities (CAs) must meet the following requirements:

  1. CA will provide the following support through life of the certificate:
    • The ability to re-issue a certificate
    • Provide current installation and configuration information
    • Maintain a list of UCSC contacts authorized to administer or manage the cert (so a random person can't call and modify it)
    • Nice to have, but not a requirement: provide renewal notices
  2. CA credentials are included in the list of web browser trusted authorities within the ITS supported desktop and/or browser
  3. CA will not possess or retain private key information
  4. CA will verify an applicant's credentials (e.g., requester is affiliated with UCSC)

-----------
Appendix C: Obtaining Certificates

See "How to Request a Certificate" for instructions and a list of information necessary process a digital certificate request.

Order processing may take 3-5 business days to complete. Requests can take longer if information is missing or inaccurate, the Certificate is for a new domain or an existing domain not affiliated with UCSC, or a domain is not within the purview of the ordering Department Registration Authority Officer (DRAO).

By submitting a certificate request, you understand and agree to adhere to the draft UCSC Digital Certificate Policy, and have received approval from the Public Information Office for the Domain Name to which the certificate will be applied (see UCSC DNS and DHCP Service Requests).

Endnotes:
[1] Note: UCSC's Minimum Network Connectivity Requirements require secure transmission of restricted data and passwords.
[2] Note: A certificate will need to be re-signed after its key is regenerated.

Last Rev. 4/24/13

DRAFT       DRAFT       DRAFT

Privacy Policy and Terms of Use