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
- 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.
- 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.
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.
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.
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)
- Copy the following into a text file. Adjust values as appropriate.
[NewRequest]
Subject = "CN=YourServerName.uoregon.edu,o=University of Oregon,S=Oregon,C=US"
KeySpec=1
Exportable = True
Keylength=4096
KeyUsage = 0xA0
MachineKeySet = True
Providername = "Microsoft RSA SChannel Cryptographic Provider"
HashAlgorithm = SHA512
EncryptionAlgorithm = aes
EncryptionLength = 256
RequestType = PKCS10
SMIME=False
;Omit this section if you don't need multiple hostnames (aka SANs) on a single certificate
[Extensions]
2.5.29.17 = "{text}"
_continue_ = "dns=fake.uoregon.edu&"
_continue_ = "dns=flimflam.uoregon.edu&"
_continue_ = "dns=hogwash.uoregon.edu&"
_continue_ = "dns=bs.uoregon.edu&"
_continue_ = "dns=horsefeathers.uoregon.edu&" |
- Save the file as servername.inf
- From an admin command prompt (or admin Powershell), go to the directory with the servername.inf file
- Run:
certreq -new servername.inf servername.req
- Open servername.req in Notepad.
- 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 . 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
organizationName = University of Oregon
commonName = yourservernamegoeshere.uoregon.edu
[ req_ext ]
subjectAltName = @alt_names
[alt_names]
DNS.1 = san1-goes-here.uoregon.edu
DNS.2 = san2-goes-here.uoregon.edu
|
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 -sha512 -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.
After you have generated a CSR, you can verify it using one of the tools below:
Use the TDX Certificate request form
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 |
Instructions on how to install SSL certificates on common platforms are available below.
After you install your certificate, you can verify it using one of the tools below:
For questions or comments regarding the UO SSL Certificate Service, please use the contact information below: