Information Security Information Services home

About the UO SSL Certificate Service

Information Services, via the InCommon Certificate Service, provides unlimited organization validation (OV) SSL/TLS certificates to University of Oregon departments and units. This program is centrally funded by Information Services and is provided at no additional cost to campus units.

SSL organization validation (OV) certificates and code signing certificates are now available via InCommon. As the service matures the service offering will expand to include extended validation (EV) SSL/TLS certificates. Additional service component, as they are added, will be announced to the campus community.

A Brief Overview on SSL Certificates

  • An SSL Certificate has two parts: a private key and a public certificate. The private key sits on your server and is used to decode the SSL encrypted network traffic. KEEP THIS KEY IN A SAFE PLACE, and DO NOT SHARE IT WITH ANYONE. The public certificate is presented to the client machine during the initialization of the SSL connection.
  • The process of creating a SSL Certificate is started by creating a Certificate Signing Request (CSR). Commonly OpenSSL is used to generate the CSR.
  • Once you generate your SSL certificate you need to get it signed. At this point you have two options, you may sign the certificate yourself (not advised except for limited use test environments), or you may send the CSR to a Certificate Authority (CA) to sign.

Certificate Classes Explained

  • Organization Validation (OV) certificates are recommended when the data being exchanged over SSL is financial, medical or otherwise extremely sensitive in nature. These certificates require a greater amount of verification of the requester's identity. We have gone through the organizational vetting required for these and the majority of certificates we process are OV certificates.
  • Extended Validation (EV) certificates are used when security is critical, and involves a greater degree of trust between with the CA. EV certificates are used by most banks and e-commerce sites. When your browser bar turns green, this is due to one of these "Extended Validation" certificates.
  • Code Signing certificates are used by developers on all platforms to digitally sign the applications and software they distribute over the Internet. Code Signing Certificates use a unique cryptographic hash to bind the identity of the publisher to the software. Security warnings that appear with unsigned code are replaced with notifications containing the software publisher's information, preventing users from abandoning the install and increasing download rates. Signing code adds an essential layer of trust to the installation process.

Self-Signed Certificates

Using self-signed certificates is less secure and not advisable. SSL is built on trust between a certificate authority and the SSL clients. If your certificate is self-signed, it gives the client machines no reason to trust that the proceeding connection is authentic. It will result in browser warning messages that the user must accept before proceeding to the website.

If you are currently using self-signed certificates in your production environment please request an OV SSL certificate to replace any self-signed certificates in use.

Subject Alternative Names (SANs)

Certificates are usually issued for a single domain name. We also have the ability to add aliases to a certificate, so the certificate will validate for multiple names. For example, a webserver may host multiple websites.

Generating a Certificate Signing Request (CSR)

CSRs should have an RSA (3072-bit or better) or ECDSA (P256 or better) key pair with a SHA256 (or better) hash. Instructions on how to generate a CSR are available below.

To make the CSR process as painless as possible, we offer the following advice for generating CSRs on the following platforms:


A Powershell script to create a CSR for Windows/IIS/RDP can be found on ISFiles:
This script will create and submit a simple CSR for the machine that it is run on.  This script requires admin rights.  For those who are curious, the SHA256 hash of this file is C09E273BEF0B8A21B04B3C29EF7709908FBE9934D21A59BD49B96016752875C9.  When in doubt, feel free to contact the InfoSec group to verify the integrity of any publicly shared script.

For a more complex CSR, the Certificates MMC snap-in can be used.  Please let us know if you would like assistance with the MMC method.


Verify that you have a supported version of OpenSSL ( 

Follow the instructions here, but use '4096' in place of '2048':

Other OSes


  • The State field of the CSR should be fully spelled out ("Oregon", instead of "OR"). This is for maximum browser compatibility and compliance with CA/Browser Forum specs.


If you have any Certificate questions, please don't hesitate to contact us at

Verifying a Certificate Signing Request (CSR)

Submitting a Certificate Request

Step 1: Send an email to with the following information (Please have the Subject line contain the words "SSL certificate request for" for our ease of handling purposes):
  • Contact E-mail Address: Identify a role or group email address, not a personal email address, to use for certificate communications.

    Using an role account (group email address) will allow your organization to continue to receive timely communication regarding certificate expiration, even if you change positions within the organization.

  • Server Software Type: Identify the Server Software Type. Most often this will be either "Apache/ModSSL" or "Microsoft IIS 5.x and later". Server Software Type options are:
Java Web Server (Javasoft / Sun)
Microsoft IIS 5.x and later
RedHat Linux
  • Validity Period: Identify how long the certificate should be valid. Most services will use a one (1) year validitiy period. Exceptions include internal-only systems that are not visible to the Internet and that do not accept/require any authentication.
  • Subject Alternative Names (SANs): Identify all SANs that should be on the SSL certificate in the RT ticket. This can prevent errors and delays in processing your request. Desired SANs must be included when generating the CSR for the SSL certificate.
  • Certificate Signing Request (CSR): Include or attach the CSR that was created for the certificate request. The key-bit strength for a CSR must be at least 3072-bits in strength.

Step 2: When the request has been approved, InCommon will send you an email with instructions on how to retrieve the certificate. This email will originate from the InCommon Certificate Services Manager, using email address

Service Expectations for Obtaining SSL Certificates

Below are the expected times for completion of work upon receipt of a service request. Some types of service requests, such as adding a new domain, have dependencies that need to be in place prior to submitting a request. Please allow for time in project timelines to accommodate for any dependency requirements.
Service Request
Expected Completion Time

Issue OV SSL certificate
1-3 business days
Add new domain
7+ business days

Installing an SSL Certificate

Instructions on how to install SSL certificates on common platforms are available below.

Verifying an SSL Certificate

After you install your certificate, you can verify it here: Other online resources for testing SSL certificates and webserver SSL configuration are available below.

Contact Information

For questions or comments regarding the UO SSL Certificate Service, please use the contact information below:
UO Information Security

Search Info Services