SSL Certificates, Certificate Service

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:

Tech Services SSL Request Portal

The Technology Services request portal gives you a way to request SSL Certificates to be generated for you, by us.
Current turnaround time is 72 hours.
Support contact is:
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)
NOTICE: The old Jira-based automation will be retired on January 7, 2020

Types of SSL certificates offered via the request portal:

SSL Certificate

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, we do 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 available:

Wildcard SSL Certificates

Wildcard SSL certificates (example: * may be requested, but they are normally only issued only in cases where there is a technical need and security concerns have been addressed. To obtain Wildcard certificates, please send email to 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 *

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 *

Commonly rejected use-cases

Less effort or cost to maintain one cert: It is true that using one SSL certificate on one's entire infrastructure would be less effort to maintain. However doing so dilutes the 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 using the one certificate would suffer impact. This risk is generally not acceptable, and therefore requests such as this are refused. This solution can only be reversed if a unit executive 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 with a brief justification of why a Code Signing certificate is needed.

SSL certificates not available:

EV certificates

These are not currently available but may be offered at a later date.

Personal X.509 certificates

These are not currently available but may be offered at a later date.

General SSL Certificate and Service Information

Key Size Requirement

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. 

Contact Information

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 to field notifications.

Common Errors Questions

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: Comodo/Sectigo's correct intermediate certificate chain must be installed per their information in the Comodo Knowledgebase

Q: How do I install this as a PKCS 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 to request this.

Q. There is no option on the web form to revoke a certificate. How do I request this?

A. Send email to with the FQDN and expiration date of the certificate you want to revoke.

NOTE: The Certificate Manager cannot revoke SSL certificates that were not issued via the Sectigo/InCommon console.


If you have other questions that are not covered here, please email to

Keywords:SSL certificate SAN CSR security wildcard domain FQDN incommon sectigo comodo   Doc ID:47662
Owner:Security S.Group:University of Illinois Technology Services
Created:2015-02-26 12:25 CDTUpdated:2019-10-15 14:07 CDT
Sites:University of Illinois Technology Services
Feedback:  1   0