Tech Services, Service Management Office, SSL Certificate Best Practices

Service Offering Administrators must understand how SSL certificates work in their specific service environments and renew them prior to expiration. This knowledge should be documented so others working with the service can be aware of how SSL certificates interact with the rest of the service. This includes knowledge of the entire certificate chain, not just the service's SSL certificate.


Secure Sockets Layer (SSL) certificates are necessary to provide trust between endpoints.  They provide all clients (software as well as customers) assurance of the authenticity and integrity of our SSL enabled services.

This document outlines common uses and tips for the creation and management of SSL certificates.  The information is distilled from the advice of Tech Services Service Administrators and Service Owners and is based on practical every-day experiences as well as unplanned service events (e.g. service outages).  Effective management of SSL certificates will help minimize service downtime as well as negative customer impact.

An introduction to what SSL is and how it works is available at:

SSL certificates play a significant role in securing institutional data.  More information about data classification is available in the Knowledge Base article: Security, Data Classification.  The DAT01-Institutional Data Security Standard is available at:

Best Practice - Timeframe

To ensure cryptographic integrity, certificates must be rotated (replaced by a new certificate) on a regular basis.  Many certificates are time bound with expiration dates of 2 years or less from the time they are issued.
Tip: Expired certificates have caused service degradations as well as service outages.  It is best to rotate certificates before they expire.  There is often a delay from the time a new certificate is requested to the time it is issued.  Plan ahead and start early!

Best Practice - Places were SSL certificates are commonly used

SSL certificates are commonly used to secure web traffic (HTTPS).  There are more places where they may be utilized.  These are some of the common places:

Web Front End

Web pages should have an SSL certificate.  They should conform to Securitys guidance on strength and origin.  Since these are public facing and externally available, their lifecycle is the easiest to monitor (and prevent outages due to expiration).


Shibboleth authentication commonly uses a self-generated certificate.  It is used to validate the endpoint is the Service Provider (SP) that the Identity Provider (IDP) expects during communication.  This certificate is stored separately from Web Front End certificates, and they often have a long expiration time-frame.

More information about Shibboleth is available in the Knowledge Base article: Shibboleth, What is it?

Application to Application

Application components may require their own certificates and are usually not required to be enterprise trusted.  They will often be self-signed by a common certificate authority. 
Example:  Splunk agent to Splunk infrastructure
Example:  Web Front End to a back-end application
In addition, vendors may include certificates as a part of their installation package.  

Application-to-Application certificates may not be obvious points of potential failure.  Applications may go for long periods of time without an update, during which the certificate may expire.  It is important to be aware of these certificates and update them prior to expiration.

SSH and SFTP Certificates

Public and private key certificates are used for authenticating to servers and SFTP traffic.  They rarely expire on a regular time-frame.  They must be closely guarded and stored in a secure location.  The loss, or reset, of the private key may impact the ability to manage services.  This is especially important for cloud-based services such as Amazon AWS and EC2 SSH keys.  They are single issuance keys and are not easily reset.

Types of Certificates

This list outlines some of the certificate types you may encounter at Technology Services.  It is not an exhaustive list.

University Issued - Incommon/Comodo/Sectigo

These certificates are commonly used on Web Front End servers.  They are requested via the SSL Certificates service provided by Technology Services.  Their time-frame is 1-2 years, which means Service Admins may make multiple SSL requests for a service throughout its lifecycle.
Tip: Certificates may be requested through this webform:
More information about the Tech Services SSL Certificates service is available in this Knowledge Base article: SSL Certificates, Certificate Service.

3rd Party SSL Certificate Vendors

The Chief Privacy and Security Officer has approved the use of commodity SSL vendors such as AWS Certificate Services and Lets Encrypt for all SSL services.  More information is available in this Knowledge Base article: [Link for document 92484 is unavailable at this time].


It is technically trivial to generate a self-signed certificate with open source tools (e.g. OpenSSL).  However, it is the least universally trusted way to secure an SSL connection.  These certificates should not be used for any University, or customer-facing, service.
Tip:  The use of self-signed certificates should be only be used for internal purposes.  However, the best practice is to use SSL certificates from approved sources, and to avoid the use of self-signed certificates altogether.


Services may rely on other certificate authorities or methods of deploying certificates.
Example: Appliances - cPanel Web Hosting Service
Example: Vended solutions certificates from AWS
Prior to using these certificates, you must consult with Privacy and Security:

Certificate Lifecycle Management

The following are tips to better manage the lifecycle of SSL Certificates.


When requesting an SSL certificate, use a distribution list (or Campus Mailing List) as a backup communication method.  This ensures that multiple people will receive alerts that may come from Sectigo.
Tip: Make sure the email list does not have any restrictions that will prevent the receipt of automated, or vendor, messages.
Tip: Make sure the email list membership is kept current and, whenever possible, has more than one member.


Store certificates and certificate chains in locations such as Box are great for ensuring continuity.  This allows the entire service team access to the information.
Tip: Ensure the permissions on the storage location are not overly permissive.
Securely store copies of private keys and certificate passwords in a University approved solution (KeePass).  More information is available in this Knowledge Base article: 69104.
Tip: Private keys may be stored securely on the server/infrastructure where they are deployed.


Tech Services offers a no-cost Campus Monitoring service, which leverages Nagios.  It may be used to monitor certificate expirations for web services.
Tip: The Config Wizard named Website allows you to quickly set up a probe that will watch certificates and warn of its expiration at a configurable interval.  You may configure as many probes as necessary.
More information on how to use monitor SSL certificate expirations with Campus Monitoring is available in this Knowledge Base article: Campus Monitoring, Monitoring SSL/TLS Certificates.


This is a time tested, low tech, method to manage SSL expirations.  Set up an Outlook calendar invite, allowing for plenty time to request and implement a new SSL certificate.
Tip: Invite your service team or create a team calendar.

Dedicated Management/Monitoring Products

A couple products are available to monitor (for validity) and manage both internal and external certificates.

KeywordsSMO, SSL, Standards, Secure Sockets Layer, HTTPS   Doc ID96631
OwnerSMOGroupUniversity of Illinois Technology Services
Created2019-12-13 15:44:42Updated2021-01-08 12:58:12
SitesUniversity of Illinois Technology Services
Feedback  0   0