SSL Certificates, Certificate Service
SSL certificates provide two features for online services: 1) Provides host validation and assurance to those who use your SSL-enabled facility, and 2) Enables encryption. This page contains information about SSL certificates, the Technology Services offering, and specifics on SSL certificate types.
SSL certificate solutions available to campus IT Pros and solutions stewards:
The Technology Services request portal gives you a way to request SSL Certificates to be generated for you, by us.Turnaround time is (max) 72 hours (3 business days).Support contact is: firstname.lastname@example.org
This refers to your ability as an IT Pro or campus solution steward to leverage such services as Let's Encrypt, AWS Certificate Services, cPanel, or others.
IT Pros and solutions stewards may use the Campus Monitoring Service to monitor their SSL certificates. See the guidance from the service to get started (Internal KB only)
Types of SSL certificates offered via the request portal:
A single-host certificate to required for SSL functionality on your server.
Multi-Domain SSL Certificate (SAN Certificate)
A SAN (Subject Alternate Name) certificate specifies the main FQDN (Common Name, or CN) and also alternate FQDNs in use by services upon the host where the certificate is installed.
SAN certificates allow for up to a maximum of 20 fully qualified alternate domain names (FQDNs) to be secured using a single certificate.
Common SAN questions:
Q: Can a SAN certificate be used on multiple devices?
A: Yes, as long as they share the same web server OS version and private key. However,not recommend doing this unless it is absolutely necessary (for example, an HA cluster).
Q: Can we add/remove FQDNs to an existing SAN certificate or can this only be done at the time of creation?
A: No, this can only be done at the time of creation. The certificate will need to be re-generated to reflect the SAN FQDN changes desired.
Special-requirements SSL certificates (restricted, only available via special approval):
Wildcard SSL Certificates
Wildcard SSL certificates (example: *.application.unit.illinois.edu) may be requested, but they are normally only issued only in cases where there is a validated and appropriate technical need, and where security risks have been addressed. To obtain a wildcard certificate, please send email to email@example.com with a brief justification of why a wildcard certificate is needed.
Commonly approved use-cases
The dynamically scalable application: The first commonly approved case is where an application generates scalable infrastructure dynamically, and needs an SSL certificate to enable that. In this case, since this is still a single application, there is no dilution of authenticity and it is appropriate to issue. The format is commonly *.application.unit.illinois.edu
The testing lab: This is where a lab is testing, developing with scratch infrastructure, or some other non-production effort. Since the lab has no intention of creating a customer trust relationship, it is appropriate to issue a general-use wildcard certificate that any node in the lab may use to test SSL functionality with a real CA-signed SSL certificate. The format is commonly *.labname.unit.illinois.edu
Commonly rejected use-casesLess effort or cost to maintain one cert: It is true that using one SSL certificate on one's entire infrastructure might be less effort to maintain. However doing so dilutes the first value of a certificate, host validation and authenticity, multiplied by the number of separate solutions or services using the certificate. It simultaneously creates a situation where if any one piece of infrastructure suffers a security incident, the entirety of that infrastrucutre would suffer impact. This risk is generally not acceptable, and therefore requests such as this are refused. This decision can only be overridden if all risk stakeholders (unit executives, legal, and/or data stewards, as determined per context) performs risk acceptance.
Code Signing Certificates
Code Signing certificates may be issued in cases where there is a technical need and security concerns have been addressed. Code-signing certificates can not be issued per-unit unfortunately. This means that all code signed with a UIUC Code Signing Certificate is signed by "University of Illinois at Urbana-Champaign". The risk is that mishandling could cause external entities to declare that all code signed by our fair institution should not be trusted. Because of this risk, the requesting entity should be ready to provide managed, controlled infrastructure to host the Code-Signing certificate.
To obtain a Code Signing certificate, please send email to firstname.lastname@example.org with a brief justification of why a Code Signing certificate is needed.
SSL certificates not available:
Not currently available.
Personal X.509 certificates
Not currently available.
Minimum Key Size
Certificate requests must have a key size of 2048 bits or higher. The self-service web interface will not accept CSRs with key sizes less than 2048-bit.
Maximum Certificate Duration
Our vendor and SSL Certificate Authority, Sectigo will no longer offer two-year public certificates. This is in reaction to a defacto requirement recently set by Apple and Google, stating that any two-year TLS certificate issued after August 30, 2020 will be treated as "untrusted" in Chrome and Safari browsers.
Beginning August 19, 2020, the SSL Certificate Service will only process and issue one-year TLS certificates.
Please ensure that the email addresses given as contacts are correct and that they will accept incoming email from Sectigo (Comodo). It is highly recommended that role or service accounts (not personal accounts) are used as business contacts.
Q: Why am I getting browser errors after installing my new certificate such as "This certificate cannot be verified up to a trusted certification authority", "The certificate is not trusted because the issuer certificate is unknown" or "This Connection is Untrusted" and/or server-side errors such as "Windows does not have enough information to verify this certificate", "keytool error:java.lan.Execption: Failed to establish chain from reply" and/or "The issuer of this certificate could not be found"?
A: Some SSL clients require CA root or intermediate certificates to be obtained and installed.
Comodo/Sectigo's root and intermediate certificates can be found on in the Comodo Knowledgebase.
InCommon's (UserTrust) intermediate certificate bundle can also be found in the Comodo Knowledgebase.
Q: How do I get a PKCS#7 cert?
A: Although we typically issue certs in x.509 format, the InCommon interface gives us the ability to manually pull down other versions, such as PKCS #7. Email email@example.com to request this.
Q: There is no option on the web form to revoke a certificate. How do I request this?
A: From the account of the authoritative contact on the existing certificate, send email to firstname.lastname@example.org with the FQDN and expiration date of the certificate you want to revoke. The Certificate Manager will call back, validate the action, and coordinate the revocation.
NOTE: The Certificate Manager cannot revoke SSL certificates that were not issued via the Sectigo/InCommon console.
Q: Isn't SSL a deprecated protocol? Why are we still using it?
A: The term "SSL" in this article is broadly used to refer to the best practice public-key cryptography. It is true SSL is deprecated and the latest version of TLS should be used whenever possible.
If you have other questions that are not covered here, please email to email@example.com.