This document provides guidance on the selection of providers of trusted server-side third-party certificates, their implementation within University systems, applications, appliances and sites, and encryption of related communications.
The need for parties to communicate securely over an insecure medium such as the Internet necessitated the creation of the Public Key Infrastructure (PKI) framework. PKI frameworks utilize public-key cryptography and digital certificates in order to provide integrity and/or confidentiality to communications between parties.
Trusted authorities, known as Certificate Authorities (CA), sign and distribute certificates for use by entities that need to assure identities and when establishing encrypted communications. Certificate Authorities are typically third-party commercial service providers.
Certificates are most commonly used for secure (HTTPS) Web sites. Web browsers inspect signed server-side certificates to verify that a Web server is authentic, using a specific Uniform Resource Locator (URL), and that the URL has been publicly verified with the identity of the institution it has been issued against (this verification is performed by the CA). Using a server certificate in this manner helps assure the integrity and confidentiality of the encrypted communications through use of cryptographic protocols more commonly known as SSL (Secure Sockets Layer) and its successor TLS (Transport Layer Security).
Other types or classes of certificates may be installed on the client side web browser and used for the legal non-repudiation of transactions and multi-factor authentication, such as when the specific identity of individuals needs to be validated when connecting the server.
Acknowledging that all vendors are “not equal”, this policy recognizes those providers that are professional and prevalent within the market place.
The audience for this policy is managers, administrators and/or technical staff that are responsible for University systems, applications, appliances, and sites that utilize SSL/TLS as any part of a PKI framework.
|Certificate Authority (CA):||An authority in a network that issues and manages security credentials for message encryption.|
|Certificate, also Digital Certificate:||An electronic document used to bind together a public key with an identity.|
|HTTPS:||A combination of the Hypertext Transfer Protocol (HTTP) with the SSL/TLS protocol to provide encryption and secure identification of the server.|
|Legally/Contractually Restricted:||University information that is required to be protected by applicable law or statute (e.g., HIPAA, FERPA, or the Illinois Personal Information Protection Act), or which, if disclosed to the public could expose the University to legal or financial obligations.|
|Public Key Infrastructure (PKI):||A set of hardware, software, people, policies, and procedures needed to create, manage, distribute, use, store, and revoke digital certificates.|
|SSL/TLS, also Secure Socket Layer and Transport Layer Security:||Protocols used to authenticate servers and clients and to encrypt messages between the authenticated parties.|
|Wildcard Certificate:||Allows you to secure multiple sub domains on one domain on the same server using *.domain.com pattern for the common name.|
Any University system, application, appliance or site that uses the NetID/password combination for purposes of authentication, or that transmits/receives data classified as “Legally/Contractually Restricted” is required to:
- Employ Secure Sockets Layer (SSL), Transport Layer Security (TLS) or their equivalent cryptographic protocols for authenticating and establishing identities, and maintaining encrypted communications channels between endpoints; and
- Use a Secure Hypertext Transport Protocol (HTTPS) connection based on server-side SSL certificates signed by a recommended trusted third-party certificate provider (see Certificate Authorities - Appendix B).
Self-signed certificates are permitted for these systems and conditions:
- Development and Testing systems, with no “Legally/Contractually Restricted” data, segregated from the production network and resources, and prohibited from connecting to external resources;
- Application server to database server connections behind an approved firewall;
- Internally hosted infrastructure systems (e.g. LDAP servers, load balancers, etc.).
- Northwestern participates in the InCommon certificate program. This allows departments to obtain certificates at no cost. Details are available at http://www.it.northwestern.edu/security/ssl-certificate/.
- Certificate Authorities are reviewed by Information and Systems Security/Compliance (ISS/C) and approved for use in University systems according to their certificate issuance procedures and criteria (see Certificate Authorities - Appendix B for a list of providers).
- Solutions must be installed and maintained in strict adherence to the providers instructions to help ensure that the security and integrity of the certificate processes are preserved. Any deviation from provider instructions or recommended use must be approved by ISS/C before implementation or changes are effected.
- Version 3.0 of the Secure Sockets Layer (SSL V3.0) protocol is the minimum installation permitted. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. Note: This policy should be consulted at the time of certificate renewal to ensure subsequent installations comply with the published standard.
- The use of wildcard certificates for one or more subdomains within the northwestern.edu domain is permissible under the following conditions:
- The service provided by the system may not be used to store or access data categorized as “Legally/Contractually Restricted”, and
- All requests for wildcard certificates for northwestern.edu are approved by ISS/C prior to certificate purchase, acquisition or assignment.
- NU systems that participate as Certificate Authorities must implement appropriate security controls in order to ensure their integrity in the role of facilitating encrypted Web communications. See References - Appendix A, “Server Security Requirements and References” for server configuration recommendations.
- System administrators must track certificate expiration dates to ensure that certificates are kept current to avoid adverse impact to operations.
Strict adherence to provider instructions for implementation and maintenance is required. Contact ISS/C to discuss any deviation from intended use or implementation and maintenance instructions.
NUIT’s Cyberinfrastructure Service Operations offers a certificate administration service for NUIT only. Any non-NUIT department requiring SSL Certificate services should contact ISS/C for assistance.
Individuals who discover or strongly suspect a violation of this policy or standards must promptly notify their management and/or any of the following:
- NUIT Support Center, (847) 491-HELP (1-4357)
- NUIT Service Operations Center: (847) 467-6662
- NUIT Information and Systems Security/Compliance
- Ethics and Compliance (for anonymous reporting), (866) 294-3545
Last Review Date:
Original Issue Date:November 2009
References - Appendix A
- MD5 considered harmful today: creating a rogue CA certificate
- Generally Accepted Principles and Practices for Securing Information Technology Systems
- Recommendation for Key Management - Part 1: General (Revised)
- Guidelines for the Selection and Use of Transport Layer (TLS) Implementations
- Erroneous VeriSign-Issued Digital Certificates Pose Spoofing Hazard
- Server Security Requirements and References
- Domain Name Services
- Data Access Policy
Recommended Certificate Authorities - Appendix B
Policy Review Date:
NUIT Information and Systems Security/Compliance(847)467-1512
NUIT Service Center
611 or 847-467-6662
Last Updated: 9 December 2013