Two-Factor Authentication
Free Antivirus
Report an Incident
Contact Us
UCIT Homepage
Information Security Review

Security Certificates

Public Key Certificates are electronic documents used to provide identification by using a digital signature and binding it to a public key. In order to properly identify a person or resource using a certificate, they must be validated against an issuing Certificate Authority (CA). Most Web browsers and other Internet applications hold trust lists for the most common Certificates Authorities on the Internet.

All new personal and server electronic certificates used at the University of Cincinnati are issued through InCommon, a federation organized to provide trust frameworks and standards in order to share resources between education and research institutions in the United States. Implementation of InCommon certificates allows for consistent issuance, revocation, and management of the certificates and ensures that all certificates are of the same standard. There is no per unit charge for use of these certificates by UC staff, faculty and systems as the certificates are deployed as part of our enterprise license agreement with InCommon. 

Request Personal or Server Certificate

To request a Personal (digital) or Server certificate, please click the red "Request Personal or Server Certificate" button above and fill out the appropriate information. 


SSL Certificates

Secure Socket Layer (SSL) Certificates are used to ensure authentication, non-repudiation and privacy for applications.  When an application is secured with an SSL certificate, users can be assured they are using a reputable site that is, in fact, the site it claims to be.  Personal certificates ensure a person is who they claim to be.  If a certificate is never replaced, however, it also runs the risk of being stolen or otherwise misused.  Certificates may also be expired or revoked.  Implementation of InCommon certificates allows consistent issuance, revocation and management of the certificates and ensures that all certificates are of the same standard.

Full SSL Listing for System Admins

A listing of all SSL certificates at the university may be viewed by clicking the button above.

This listing will be updated on a monthly basis.

 

Types of Certificates Offered

SSL Certificate

A SSL Certificate is a single-domain webserver certificate needed to enable SSL operation on a server. 

Multi-Domain SSL Certificate (SAN Certificate)

A SAN (Subject Alternative Name) certificate has a field that specifies alternate FQDN’s that can use the certificate on the same domain. These certificates will secure up to 100 different FQDN’s on a single certificate.

Comodo EV SGC SSL Certificate

Extended Validation certificates provide the highest levels of encryption, security and trust and immediately reassure web site visitors that it is safe to conduct online transactions by turning the address bar green on next generation browsers.

Client (personal) or S/MIME Certificate

Also known as personal certificates or digital signatures, these certificates are associated with a person using their UC e-mail address for the following purposes:

  • Signed Email - A campus certificate infrastructure like Microsoft Exchange Global Address List (GAL) makes it possible to promote S/MIME-based digital signing of electronic mail messages. Many modern email clients support signed email messages as do some webmail applications (e.g., Outlook Web Access). Highlight: official announcements, mailing list issues, client interoperability, webmail, client configuration, etc.
  • Encrypted Email - Many email clients support the ability to use digital certificates to encrypt messages. While this facility can be useful for the short term transport of sensitive data, the use of encryption is easily achieved using the Microsoft Exchange Global Address List (GAL) in conjunction with the Microsoft Outlook client.
  • Digital Signatures - Signing other documents, such as in the Microsoft Office Suite and Adobe products. This could include protocols for being able to verify signatures after the signing certificate expires. Another use case might be signed Web pages to ensure readers that the content was produced by the supposed source. Browsers that can accommodate "extensions" (Firefox, Safari) could make use of this capability.
  • Web Authentication - Most Web servers and browsers make certificate-based authentication easy to implement and use. A typical campus implementation might prefer the use of certificates over passwords for authentication to the central campus Web SSO system. Application owners should always consider if part of their user community (e.g., guests) may not have certificates. The use of certificates eliminates the risk associated with phishing attacks. While Web authentication to local campus systems can work seamlessly because the Subject DN or other content can be understood, Web authentication to external systems is more problematic. 

For instructions on installation of personal certificates, use this tutorial.

 
Wildcard Certificates

In many industries there are time and cost considerations when purchasing digital certificates, thus making wildcard certificates more appealing as they cover an unlimited number of sub-domains. Since UC is a member of the InCommon Federation, the individual cost per certificate is not a concern. 

There is also a security consideration when using a wildcard certificate: if the private key associated with that wildcard certificate is compromised, then all servers using that wildcard certificate are vulnerable. Due to these concerns, UC has implemented the following restrictions on wildcard certificates:

  • Cannot be used for one of UC’s top-level domains (e.g., *.uc.edu)
  • Must be limited to a period of 1 year
  • Are not permitted on sub-domains that handle, transmit, or store Export Controlled/Restricted/Controlled data
  • Are not permitted on sub-domains with production data
  • Are not permitted on sub-domains that handle, transmit, or store production credentials
  • Must be recreated with new keypairs, not renewed
  • May only be used when more than 100 FQDNs are involved. (If fewer than 100 FQDNs are needed, request a Multi-Domain SSL certificate instead).
Exceptions to Restrictions on Wildcard Certificates

It is recommended that a multi-domain certificate be used rather than a wildcard certificate. In the event that a multi-domain certificate is not appropriate, an exception may be granted. However, exceptions to these restrictions require approval by the Office of Information Security who will require a documented and approved RAF.

 

Renewing, Replacing, and Revoking Certificates

Certificates must be renewed or replaced before expiration.

  • See the Digital Certificates Standard for specific renewal requirements

Certificates must be revoked if any of the following occur:

  • Private key has been compromised
  • The service is being retired or decommissioned
  • When the private key is no longer in use
  • An employee with access to the certificate/private key leaves the university
 

Turnaround Time

Standard turnaround time for certificate requests submitted via the webapp form is four (4) business days.

 

OIS Certificate Service

All University-related certificates must be issued by the Office of Information Security. Additional approval is required for certificates issued outside of this service.

 

Questions

Contact the IT@UC Office of Information Security.

To view PDF files, you will need Adobe Acrobat Reader, a free download.