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

Instructions

Need detailed instructions on installing your personal (client) certificate?

SSL Certificates

Secure Socket Layer (SSL) is a security protocol used to secure Internet connections. It’s typically used as a secondary protocol that is layered on top on an existing unencrypted protocol such as FTP or HTTP. Although SSL provides two-way encryption, it doesn’t provide identification. Two parties know they’re communicating securely over SSL, but they have no way of making sure the other party truly is who it claims to be. Because SSL is built into all major browsers and Web servers, simply installing a digital certificate turns on their SSL capabilities. By convention, URLs that require an SSL connection start with https: instead of http:.

SSL Certificates are issued from a Certificate Authority (CA) and provide a way for clients to validate that the server they are connecting to is really what it claims to be. Several major CA certificates are built-in to modern Web browsers and SSL frameworks and those primary CAs may also grant validation abilities to secondary CAs as well.

There are two types of certificates, server and client (personal).

Server Certificates

The University of Cincinnati uses InCommon as our CA for all new server SSL certificates. You should request a certificate if you are responsible for running an Internet service for the University of Cincinnati that requires SSL. This can include, but is not limited to, Web servers (HTTPS), mail servers (SMTPS, IMAPS, POPS), secure file transfers (FTPS), etc.

Client (personal) Certificates

Through InCommon, UC also offers client certificates, known as personal certificates. These certificates are associated with a person using his or her 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 from InCommon.

Costs

UCIT pays for server and client certificates issued for the University of Cincinnati by InCommon; they are issued at no additional charge to departments.

To obtain certificates, use the following webapp to make your request. The UCIT Office of Information Security will verify your association with the university and, if approved, will forward the request to UCIT Systems and Operations for fulfillment.

https://webapps.uc.edu/idm/certissue/main                   

Questions

Contact the UCIT Office of Information Security.


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

  • University of Cincinnati UCIT Office of Information Security
  • University Hall
  • 51 Goodman Drive
  • Cincinnati, OH 45221