SSL Certificates

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.

OV SSL 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 of SSL Certificates
  • Certificate Classes Explained
  • Self-signed SSL Certificates
  • Subject Alternative Names (SANs)
  • Generating a Certificate Signing Request (CSR)
  • Verifying a Certificate Signing Request (CSR)
  • Submitting a Certificate Signing Request (CSR)
  • Service Expectations
  • Installing an SSL Certificate
  • Verifying an SSL Certificate
  • Contact Information

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. Some browsers may display additional information about the organization the website is connected to when the website is using an Extended Validation certificate.
  • 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 resultant 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 (P384 or better) key pair with a SHA512 hash.

Note: 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..

Windows (Certreq)

  • Simple
    • A Powershell script to create a CSR for Windows/IIS/RDP can be found on our internal file server. Please contact Information Security Consulting for this location. This script will create and submit a simple CSR for the machine that it is run on. This script requires admin rights. 
  • Advanced
    • Copy the following into a text file. Adjust values as appropriate.
Subject = ",OU=Your Organizational Unit,o=University of Oregon,L=Eugene,S=Oregon,C=US"
Exportable = True
KeyUsage = 0xA0
MachineKeySet = True
Providername = "Microsoft RSA SChannel Cryptographic Provider"
HashAlgorithm = SHA512
EncryptionAlgorithm = aes
EncryptionLength = 256
RequestType = PKCS10
;Omit this section if you don't need multiple hostnames (aka SANs) on a single certificate
[Extensions] = "{text}"
_continue_ = ""
_continue_ = ""
_continue_ = ""
_continue_ = ""
_continue_ = ""
  1. Save the file as servername.inf
  2. From an admin command prompt (or admin Powershell), go to the directory with the servername.inf file
  3. Run:   certreq -new servername.inf  servername.req
  4. Open servername.req in Notepad.
  5. Copy the contents of that file into the TDX Certificates request form.

Linux/Unix/Mac (OpenSSL)

Verify that you have a supported version of OpenSSL. You can view your OpenSSL version by running openssl version on your CLI.  You should get back something like this:

$ openssl version
OpenSSL 1.1.0f-fips  25 May 2017

Now, it's time to create an auto-config file. Open up your favorite editor (vi, emacs, etc.) and add the following. You will need to edit the organizationalUnitName to match your Unit and edit the commonName to match your server's hostname (FQDN). Alternate names (SANs) are added at the bottom under [alt_names]. If you don't have any alternate names, remove the req_extensions line and everything below the commonName line.

[ req ]
prompt = no
default_bits       = 4096
distinguished_name = req_distinguished_name
req_extensions     = req_ext
[ req_distinguished_name ]
countryName                 = US
stateOrProvinceName         = Oregon
localityName               = Eugene
organizationName           = University of Oregon
organizationalUnitName           = Your Unit Name goes here
commonName                 =
[ req_ext ]
subjectAltName = @alt_names
DNS.1   =
DNS.2   =

Save this file as server.cnf. This will be the OpenSSL auto-config file.

To generate the CSR, run the following commands

mkdir ~/server.ssl/
cd ~/server.ssl/
openssl genrsa -out ~/server.ssl/server.key 4096
openssl req -new -sha256 -key ~/server.ssl/server.key -out ~/server.ssl/server.csr -config ../server.cnf

Copy the contents of the server.csr file into the TDX Certificates request form

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

Verifying a Certificate Signing Request (CSR)

After you have generated a CSR, you can verify it using one of the tools below:

Submitting a Certificate Request

Use the TDX Certificate request form

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 using one of the tools below:

Contact Information

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

Contact:   UO Information Security
Phone:   541-346-5837
Online:   Information Security Consulting Request
0% helpful - 1 review


Article ID: 32229
Fri 6/16/17 4:07 PM
Fri 11/12/21 10:03 AM