UCSC SSL Certificate Policy


This policy expands on UCSC's Minimum Network Connectivity Requirements, which require secure transmission of restricted data and passwords. Its purpose is to identify the appropriate use of SSL (secure socket layer) certificates at UCSC.

SSL certificates (certs) are used to confirm identity, secure communications between parties, and ensure integrity of transmissions. Requests for SSL certs that do not meet the requirements in this policy may be denied or subject to revocation.


This section outlines the acceptable use of SSL certificates at UCSC. Additional strength, configuration, and validity requirements are included in Appendix A. Certificate Authority requirements are included in Appendix B. Requests for SSL certs 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 SSL Certificates

Only ITS units may own or manage a wildcard cert for the *.ucsc.edu domain. Non-ITS units may obtain wildcard certs for their sub-domain(s) and servers only (e.g. *.mydomain.ucsc.edu). These cannot apply to ITS centrally provided hosts. See below for additional details.

Unless specifically disallowed above, wildcard SSL certs may be appropriate for a single server with more than one host sharing a single IP address.

UCSC does not permit wildcard certs for systems handling restricted data.

B. Self-Signed SSL Certificates

Self-signed SSL certificates are only allowed when all the following apply:

  • All clients can have the certificate manually installed
  • Installation is on development and test systems only; users should 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
  • The private key is password protected

Self-signed SSL certificates are not allowed in the following circumstances:

  • When data on the server is accessible by the public or via a public IP
  • On a production service deployed to a wide number of users
  • When restricted data is involved

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. IS-3 Protection Matrix

Where passwords are used to protect private keys, those passwords must comply with the campus Password Policy and Password Strength and Security Standards. Passwords are strongly recommended for private keys protecting restricted data.

D. Systems are not permitted to operate with expired certificates.

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


Exceptions to this policy must be approved by the campus Information Security Officer (ISO): itpolicy@ucsc.edu


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 January 2012.


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.



Appendix A: SSL Certificate Requirements

Please note: Requirements in this appendix are subject to change in response to changes in industry standards, law or UC/UCSC policy.

  1. Minimum required data encryption strength/certificate strength: 128-bit/1024-bit. 256-bit/2048-bit is required for certs issued after January 1, 2010.
  2. Null and Anonymous Diffie Hellman (ADH) cyphers are not allowed.
  3. Keys for all systems should be regenerated and certs re-signed annually [1].
    • Annual renewal is required for environments handling restricted data.
    • Vendor-issued certs must expire after no longer than three years.
  4. Servers must be configured to accept SSLv3 or higher. Weak cipher connections are not allowed. See IT Request FAQs SSL disable and SSL disable2 or contact the ITS Support Center for configuration information.
  5. SSL certs must have fully qualified domain names.

Appendix B: Certificate Authority Requirements

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 verify an applicant's credentials (e.g., requester is affiliated with UCSC).

Appendix C: Purchasing SSL Certificates

Certificates are to be requested using ITS' SSL Request Form and process. This allows access to UC pricing where available, enables ITS to coordinate validation requests from Certificate Authorities, and confirms requesters understand applicable policy.


[1] Note: A cert will need to be re-signed after its key is regenerated.

Last Rev. 1/7/10