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".

Types of SSL certificates offered via the request portal:

• A SSL or TLS certificate with 1-20 hosts.
• Certificate FQDNs must not be in any of the following domains: uillinois.edu, the domain of another University campus (uic.edu, uis.edu), or any domain where you cannot prove domain ownership by adding a DNS TXT record on request (such as amazon.com or google.com).

Can a SAN certificate be used on multiple devices?

Yes, as long as they share the same private key. However, we do not recommend doing this unless it is absolutely necessary (for example, an high-availability cluster).

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. You will need to supply all of the FQDNs you need in a certificate in the CSR (certificate signing request) for that certificate if you want to use our service.

Do you offer wildcard SSL Certificates?

Yes, wildcard 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 from our service, please send email to securitysupport@illinois.edu and CC certmgr@illinois.edu with a brief justification of why a wildcard certificate is needed. You're more likely to get a wildcard certificate approved if you can show that your use is sufficiently similar to any of the following:

• 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

Your request for wildcard certificate approval is likely to be rejected if it is merely less effort or cost to maintain one certificate. 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 (including S/MIME certificates used with email clients)

What are the required key algorithms and key lengths for getting signed certificates from your service?

RSA (2048, 3072, 4096) or ECC (curves P-256, P-384).

How long will certificates last and when will certificate lengths change?

We don't have a clear an understanding of what the maximum certificate length will be or when the maximum certificate length will change. We will always issue the maximum certificate length that we can get. If you would like a shorter-term certificate than our service issues, consider either using another authorized CA (see Security, 3rd-party SSL certificate services, guidance and usage) or issue a new certificate when you wish to switch certificates.

What should I supply for contact information?

Please ensure that the email address given as a contact point is correct and that it will accept incoming email. It is highly recommended that role or service accounts (not personal accounts, not University-assigned NetID-based email addresses) are used.

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.

How do I get a certificate in another format than what I was issued?

You are on your own to convert to another certificate format. We have less control for certificate formats than we used to and we issue what we can get.

How do I get self-service for myself or other members of my IT team?

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 our service. Certificate revocation for other services (such as Let's Encrypt) must be dealt with via that service.

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.

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.
• Visit UIC's documentation (https://help.uillinois.edu/TDClient/37/uic/KB/ArticleDet?ID=772) or contact certmgr@uic.edu for help requesting signed certificates for uic.edu hostnames and hostnames owned by that campus.
• Contact UIS (certmgr@uis.edu) to request signed certificates for uis.edu hostnames and hostnames owned by that campus.
• Contact AITS (certmgr@uillinois.edu) to request signed certificates for hostnames that span campuses and non-AD uillinois.edu hostnames.
• Publicly-signed certificates shouldn't be issued for Active Directory hosts (ad.uillinois.edu domain FQDNs).

Why did my last certificate request take so long before I received a signed certificate?

Perhaps you requested a certificate with a hostname that is a DNS CNAME record pointing to an unresolvable FQDN like a CNAME pointing to a FQDN in ad.uillinois.edu. Active Directory (AD) hosts are not suitable choices for publicly-signed certificates because the AD DNS is not public. AD hostnames can't be resolved off-campus, so those queries timeout and turn into either large issuance delays or not issuing at all.

To fix this you have options:

• Point your hostnames at non-AD, fully resolvable DNS entries—Make your preferred service name an A (IPv4) or AAAA (IPv6) record with the IP or IPs of the server instead of a CNAME pointing to an AD hostname. This won't make your server reachable from outside the University, but it might speed up certificate issuance.
• Give your server a second IP address in a different firewall group—pick a firewall group which exposes the ports you need for your service and add a DNS A or AAAA record with the more exposed IP address. Learn how to move a computer into another firewall group. Consult a list of Networking, Firewall, Special Ports for Mostly Open, Mostly Closed, and Web Only Categories to see which ports are exposed in which firewall groups.

I have another question not answered here!

Please email certmgr@illinois.edu.