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.
Overview
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.
An introduction to what SSL is and how it works is available at:
https://medium.freecodecamp.org/https-explained-with-carrier-pigeons-7029d2193351.
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: https://go.illinois.edu/secstd-DAT01.
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 Security’s 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).
Authentication
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
Example: Splunk agent to Splunk infrastructure
Example: Web Front End to a back-end applicationIn 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: https://go.illinois.edu/sslrequest.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 “Let’s Encrypt” for all SSL services. More information is available in this Knowledge Base article: Security, 3rd-party SSL certificate services, guidance and usage.Self-Signed
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.
Others
Services may rely on other certificate authorities or methods of deploying certificates.Example: Appliances - cPanel Web Hosting Service
Prior to using these certificates, you must consult with Privacy and Security: securitysupport@illinois.edu.Example: Vended solutions – certificates from AWS
Certificate Lifecycle Management
The following are tips to better manage the lifecycle of SSL Certificates.
Requests
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.
Storage
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: Security, Password Manager, Why You Should Use One.
Tip: Private keys may be stored securely on the server/infrastructure where they are deployed.
Monitoring
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 Certificates.
Calendar
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.- Qualys Certview: https://www.qualys.com/certview/
- UIUC already owns the Qualys product for host/service scanning. Certview is free to use for external certs, but requires a subscription for internal hosts.
- More information regarding Qualys can be found in the internal Knowledge Base article, Qualys, Run On-Demand Vulnerability Scans.
- Globalsign Certificate Inventory: https://www.globalsign.com/en/lp/certificate-inventory-tool-sign-up/
- This is a free product that can be automated to collect info and report against a baseline.