Topics Map > Safety and Security
SSL Certificates, Certificate Service
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. Turnaround time is (max) 72 hours (3 business days). Support contact is: certmgr@illinois.edu.
Security, 3rd-party SSL certificate services, guidance and usage
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.
Please see additional guidance: "Security, 3rd-party SSL certificate services, guidance and usage".
[Link for document 89497 is unavailable at this time]
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:
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?
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?
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 securitysupport@illinois.edu and CC certmgr@illinois.edu 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-case
Less 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 infrastructure 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 securitysupport@illinois.edu with a brief justification of why a Code Signing certificate is needed.
SSL certificates not available:
- EV certificates
- Personal X.509 certificates
General SSL Certificate and Service Information
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.
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 as business contacts.
Common Errors and 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", "This Connection is Untrusted", 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", or "The issuer of this certificate could not be found"?
Some SSL clients require CA root or intermediate certificates to be obtained and installed. You can download such certificates from InCommon Certificate Types page. Certificates requested via our service will also generate an email containing download links. This email is sent to the certificate's contact address. Certificates may also be requested either at the time one requests a signed certificate from our service or later by following up on the request ticket or requesting via email to certmgr@illinois.edu.
Q: Where can I get the Sectigo V2 root and intermediate certificates?
Download any of the following certificates:
Q: How do I get a PKCS #7 certificate?
Although we typically issue certificates in x.509 format, the InCommon interface gives us the ability to manually pull down other versions, such as PKCS #7. Email certmgr@illinois.edu to request this and specify the serial number of the certificate for which you'd like PKCS #7. If you're about to request a signed certificate via the request form, request a certificate in PKCS #7 certificate in the last field of the request form.
Q: How do I get self-service for myself or other members of my IT team?
The self-service pilot is over and we are no longer accepting applications for self-service users. Unfortunately, providing console access to the Sectigo/InCommon tool was not found to be a viable solution due to identity/group support scaling and supportability issues. Please see the SSL Certificates, Certificate Service for current options.Q: There is no option on the web form to revoke a certificate. How do I request this?
From the account of the authoritative contact on the existing certificate, send email to certmgr@illinois.edu 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?
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.
Q: The University has multiple parties or groups which can sign certificate requests. Which should I choose?
Select a certificate signing service depending on which hostnames are in your request.
- Visit https://go.illinois.edu/sslrequest to request a signed certificate for any hostnames owned by the Urbana-Champaign campus as well as hostnames in the Active Directory domains *.ad.uillinois.edu and *.addev.uillinois.edu.
- Visit UIC's documentation (https://help.uillinois.edu/TDClient/37/uic/KB/ArticleDet?ID=772) for instructions to request signed certificates for *.uic.edu hostnames and hostnames owned by that campus.
- Contact UIS (tllos1@uis.edu) to request signed certificates for *.uis.edu hostnames and hostnames owned by that campus.
- Contact AITS (tech@uillinois.edu) to request signed certificates for hostnames that span campuses or include *.uillinois.edu hostnames (except *.ad.uillinois.edu and *.addev.uillinois.edu hostnames as described above).
If you have other questions that are not covered here, please email certmgr@illinois.edu.