SSL Certificates are used to create secure connections between a user and the server they are trying to reach, using encryption. This encrypted connection is created through the use of public key cryptography, which is a set of well-established techniques and standards for protecting communications from eavesdropping, tampering, and impersonation attacks. Certificate configuration involves the creation of a certificate request (CSR) on the server using a private key. The CSR is then submitted to a Certificate Authority (CA), which converts the certificate request into a certificate. CSU, Chico, uses InCommon Comodo for SSL certificates.
When requesting a certificate, there are three common certificate types used:
- InCommon SSL (SHA-2) – required for single system certificates on public facing servers
- InCommon Multi Domain SSL (SHA-2) - required for multi-domain servers
- InCommon Intranet SSL (SHA-2) –required for internal servers
Note: Wildcard certificates (i.e. *.csuchico.edu) are generally issued on a restricted basis. Contact the Information Security Office if a Wildcard certificate is necessary.
Additional Information (*Restricted Access – credentials required*)
Private Key Security
Public and private key pairs are comprised of two cryptographic keys, which are uniquely related. The public key is made available within the server certificate located on the server, while its owner confidentially holds the private key. Public key length should be a 2048-bit length minimum.
IMPORTANT: Private key files must be protected at all times
- Store in a safe location
- Ensure file permissions are set appropriately, such that the private key is never accessible outside of the system
Some ways to protect a private key are as follows: minimize access to private keys, use physical security to protect keys, use cryptographic hardware modules, and use test-signing versus release-signing.
Information Security will send server admins a notice of expiration; however, it is the administrator’s responsibility to keep track of their server’s certificate status. Expired certificates can result in service outages, and should prompt users that the service is insecure and not to be trusted.
Certificate Signing Request (CSR)
A CSR can be generated in multiple ways depending on the structure of the server. Java Key Store, OpenSSL, and Microsoft Certificate Manager are all tools that can be used to generate CSR’s and manage private keys:
- A Java Key Store is a repository of security certificates consisting of public key certificates and authorization certificates. Java-based applications use this repository for encryption, authentication and serving over HTTPS. Commands for generating keys, CSR’s, self-signed certificates, and much more, can be found at Java Keytool Essentials.
- OpenSSL is an open source implementation of the SSL protocol, which is commonly used for generating CSRs and private keys for many platforms. Commands used to generate CSRs, Certificates, and Private Keys can be found on SSL Shopper.
- Microsoft’s Certificate Manager Tool is used to manage certificates, certificate trust lists, and certificate revocation lists. It is a command-line utility that is automatically installed with Visual Studio (for more information, see Visual Studio Command Prompt). A list of commands to be used within Certificate Manager can be found on Microsoft’s website.
Initiating a Self-Enrollment Process for obtaining an SSL Certicate
System administrators can make a request for certificates by utilizing the Self-Enrollment page within InCommon Certificate Manager. On successful submission of a Certificate Request to InCommon CA, the certificate will be issued and a notification email will be sent to the requester. The requester can download the certificate and install it onto their respective server. For more information on the self-enrollment process, please visit the Information Security Offices Wiki.
The application form for SSL certificates is hosted, by default, at: