SSL Certificates - KBA | University Technology, [U]Tech

General Information

SSL certificates are used primarily to secure web sites by encrypting the traffic between a user's browser and the web server it is accessing. They are also used to encrypt traffic between client software and servers (for example between an Outlook mail client and the Case mail servers) for anything that can use SSL or TLS to encrypt traffic.

SSL certificates are tied to specific domains (for instance case.edu). Case has authority over the following domains and no others:

cwru.edu
case.edu
clevelandactu.org

This means that Case CAN provide an SSL certificate for something like my-server.case.edu but can NOT provide an SSL certificate for something like my-server.somedomain.com or even something like my-server.case.edu.hosted.somedomain.com.

Policies

Case provides SSL certificates free of charge to the following:

Any Case faculty or staff member, or any affiliate (for example contractors or temporary employees) acting on behalf of a Case faculty or staff member.
Case faculty/staff-run organizations

Case does NOT provide SSL certificates to the following:

Students
Student-run organizations

As of May 2011, Case no longer provides self-signed server certificates. Since we are now able to provide unlimited, free, nationally recognized certificates, there is little point in offering self-signed certificates which are not recognized or trusted by modern browsers "out of the box."

3rd-Party Vendors

Many organizations may choose to delegate responsibility for setting up and maintaining a web server and its services to a 3rd-party vendor who provides the web server/site as a service. In those instances, as long as the site URL uses a hostname in the domain of case.edu or cwru.edu then the vendor MUST use a CWRU-provided InCommon SSL certificate. It is the vendor's responsibility to provide a valid Certificate Signing Request as described below and to install the resulting CWRU-provided certificate in the web service they are hosting. Some examples of sites that MUST use CWRU-provided InCommon certificates are:

https://mysite.case.edu/myApplication
https://ridealong.case.edu/hosted-by-some-vendor-service

Examples where a CWRU-provided InCommon certificate is not required (and cannot be used) are:

https://cwru.myvendor.com/cwru-application
https://case.edu.some-company.com/my-application

Some 3rd-party vendors may offer certificates as part of their service. It is NOT permissible to use a vendor-provided certificate if the hostname of the site is in the domain of case.edu or cwru.edu. If the vendor asserts that ONLY their certificates can be used with their service, the validity of the assertion will be verified and an exemption to the rules MAY be granted. The process of validating the vendor assertion and properly authorizing the vendor's certificate to be used in the case.edu/cwru.edu domains will add time to the amount needed to secure the site.

The easiest method of using an InCommon SSL certificate to secure a site hosted by a 3rd-party vendor is to put the vendor in touch with certificate-admin@case.edu.

Requirements for requesting a certificate

In order to request an SSL certificate you must provide a Certificate Signing Request (CSR). There are various ways to generate a CSR, depending on the web server or system you are securing. Most servers have utilities for generating them, but all CSRs have several things in common:

CSR Requirements:
1. Every CSR MUST have a common (server) name. For example: The common name for web server https://www.case.edu would be www.case.edu.
2. Every CSR (and the certificate created from it) is tied to a private key. The key is generated when the CSR is created and may or may not be directly accessible to you, depending on the server and the mechanism used to generate the CSR. The key MUST be 2048 bits in length or greater. While there is nothing to prevent you from generating a key GREATER in length than 2048 bits, the larger the key size, the greater the performance impact on your web server due to the greater complexity in encrypting/decrypting the data streams.
3. Every CSR MUST have a domain as part of the common name. See above for the domains over which Case has authority.
4. Every CSR has an organization. That organization MUST be Case Western Reserve University.
5. Every CSR has a state or province. The state MUST be Ohio (spelled completely out not abbreviated as OH).
6. Every CSR has a locality (generally a city). The locality MUST be Cleveland (spelled completely out and not abbreviated).
Signing requirements: In compliance with National Institute of Standards for Technology (NIST) guidelines, Case stopped issuing certificates using a signing algorithm called SHA1 in favor of the more secure SHA2 (also called SHA256) signing algorithm. All self-service request tools are restricted automatically to the more secure algorithm, but existing "SHA1 certificates" still exist. On expiration, those certificates can NOT be renewed (because they use the SHA1 signing algorithm) and must be requested as new certificates.
Contact email address: When requesting a certificate either by the self enrollment form or by contacting certificate-admin@case.edu (see below) you MUST provide a contact address for the certificate management system to contact you with instructions on how to download your certificate. The same address is used to send you notices when your certificate is expiring. The email address you provide MUST allow for multiple recipients or for the recipient to be easily changed so that staffing/responsibility changes do not cause a certificate expiration notice to be missed. In the case of a certificate being used in a site hosted by a 3rd-party vendor, it is recommended to have an email address for the vendor and REQUIRED to have CWRU recipient(s) both present in the contact email address list.

InCommon Certificate Authority

Certificate Authority

As of May 2011 we are subscribers of the InCommon Certificate Authority service. The service is mediated by InCommon/Internet2, however the actual certificate authority is Sectigo. There is a chain certificate for every server certificate issued under the new service. Essentially, each Certificate Authority (CA) sets up a Chain of Trust by issuing one or more intermediate, or "chain" certificates. Each intermediate is signed by the one immediately superior to it ending ultimately in a "root" CA certificate that is trusted by browsers and other devices as part of their certificate store of trusted CAs. As certificate security needs change, the intermediate certificates can also change, as happened recently with our InCommon/Sectigo certificates. For that reason we no longer provide pages with the intermediate and root CA certificates. Users should instead use the certificate "chains" provided in the email issued when a certificate has been successfully enrolled (issued by Sectigo).

SSL Certificates - Types, Uses, and Requesting

We currently offer two types of SSL certificates: InCommon SSL (SHA-2) and InCommon Multi-Domain SSL (SHA-2). In compliance with NIST recommendations we offer ONLY certificates using the SHA-2 signing algorithm.

InCommon SSL (SHA-2) Certificates:

InCommon SSL (SHA-2) certificates are used for securing servers that only require a single server name (for example https://mysite.case.edu). Since only a single name (the CN part of the CSR) becomes part of the certificate, attempting to secure multiple sites (for example https://mysite.case.edu, https://yoursite.case.edu) can NOT be done, even if they all run on the same web server. Note that you CAN secure multiple pages running on the same site (for example https://oursites.case.edu/mypages/, https://oursites.case.edu/yourpages/). Note also that the DOMAIN of the server is considered different in regards to SSL certificates (for example https://mysite.case.edu and https://mysite.cwru.edu are considered different).

An InCommon SSL (SHA-2) certificate may be requested from a self-service enrollment page located at https://cert-manager.com/customer/InCommon/ssl?action=enroll. The page requires an access code which we do not make publicly available. If you need to request a certificate and do not have the access code, please contact certificate-admin@case.edu to obtain it. Please do not give out the access code to anyone other than a Case faculty or staff member or contractor acting on behalf of a Case faculty or staff member. The email address you enter in the self-enrollment form should NOT be your personal email address, but rather the address of a mail list or Google Group, following the "Contact email address" guidelines above.

Fill in the form:

Select 1 year term for the certificate. The term indicates when the certificate will expire and must be renewed.
Select "Server Software" from the drop-down list. Popular web server software is included in the drop-down. If you are unsure what software to choose, "Apache/ModSSL" is generally a good choice.
Enter the CSR in the space provided (including the -----BEGIN CERTIFICATE REQUEST----- and -----END CERTIFICATE REQUEST----- lines). If the CSR is in a file on your computer you may also upload it by clicking the "UPLOAD CSR" button.
Enter the server/site name (for example mysite.case.edu) in the "Common Name" field (in many cases this is filled in automatically from the CSR when it is entered, or by clicking the "GET CN FROM CSR" button).
While a pass-phrase is not required, if you wish to revoke or renew your certificate using the self-enrollment form, you will need one.
Enter any comments you feel necessary either for you to remember the purpose of the certificate or for the Certificate Administrators (who will have to approve the request before a certificate is issued by Sectigo).
Click "ENROLL" to submit your request.

InCommon Multi-Domain SSL (SHA-2) Certificates:

InCommon Multi-Domain SSL (SHA-2) certificates are used to secure multiple sites (for example https://mysite.case.edu, https://yoursite.case.edu) or multiple domains (for example https://mysite.case.edu, https://mysite.cwru.edu) running on the same server. InCommon Multi-Domain SSL (SHA-2) certificates are also known as Subject Alternative Names (or SAN for short) certificates. While the SANs can be entered as part of the CSR if you know how to do so, it's most often easier to just create the CSR as you would for the other certificate type, and include your SANs "after the fact" when requesting the certificate. Once the certificate is approved by the Case Certificate Administrator, SANs can not be added to or removed from the certificate until the certificate is up for renewal or a new certificate from the existing CSR is requested.

To request an InCommon Multi-Domain SSL (SHA-2) certificate, create your CSR as you normally would, and attach it in an email request to certificate-admin@case.edu. Please include:

The CSR
The certificate term (1 year)
A comma-separated list of SANs: (for example for a request with a CN of mysite.case.edu, you might have a SAN list of (mysite.cwru.edu,yoursite.case.edu,yoursite.cwru.edu,theirsite.case.edu,theirsite.cwru.edu). The limit of SANs per certificate is 100 but the odds of a typo increase as the number of SANs increases, so only include those SANs you feel you will need for the duration of the certificate.
The email address (again, a mail list or Google Group please) that is the "contact address" for the certificate.

Auto-Renewing Certificates:

Certificates may now be set to automatically renew a certain number of days, for example, 30 days before the current certificate expires. The auto-renewal option and the date on which auto-renewal happens can be selected as part of the certificate request process. The existing CSR is reused to request the new certificate in an auto-renewal, so the auto-renew function is only going to be useful if none of the certificate information has changed, including the SANs to be used with it. Note that although the certificate request is automatic with an auto-renewal, the process of having the Certificate Administrators approve the request, receiving the issued certificate and installing it on your site are all the same as if you had requested a new certificate "from scratch".

Checking Your Certificate Deployment

Once your certificate has been requested, issued, and installed, you will probably want to check the installation to verify that the new certificate was installed properly. There are several useful sites and tools to allow you to gather information not only about the certificate, but also about the web server on which the certificate is installed:

Sectigo SSL Checker

The Sectigo SSL Checker is Sec's own tool for checking how secure are the certificate and the server on which it is installed. The URL for the checker is at: https://sectigostore.com/ssl-tools/ssl-checker.php You use the tool by entering a host, followed by a ":" and the port on which to test (eg: mpv7.case.edu:25). This analyzer is good for allowing you to check the certificate and encryption services on things other than just web servers due to the ability to specify a port number on which to test.

Qualys SSL Labs Server Test

The Qualys SSL tester is not only more comprehensive than the Sectigo SSL checker, but also gives a letter grade from A to F to the security of the web server. The only drawback of this particular analyzer is that it supports HTTPS (port 443) ONLY. The URL for the Qualys analyzer is https://www.ssllabs.com/ssltest/.

OpenSSL

OpenSSL is in many ways the "go to" SSL utility: it is available on nearly every flavor and version of Unix, can be used to manipulate certificate as well as test them (see below), and the libraries on which it is build are the same libraries which are used to build the SSL modules of most web servers (and many, many, other SSL services). In a pinch the program and SSL library sources can be freely downloaded and compiled without great difficulty. The only drawback to OpenSSL is that it is a command-line interface (CLI) program, and like many low-level CLIs its use and commands are somewhat cryptic. It IS very powerful for testing certificates and for creating CSRs however.

Using OpenSSL to Test Certificates

To test a certificate deployment in a browser agnostic way, you can use the openssl s_client command to open an SSL or TLS connection (additionally printing certificate chains and verifications). The command may also be used to test SMTP encrypted connections using the second code example.

To test a web server (default SSL port is 443) use the command:

openssl s_client -connect [hostname]:[port] -CAfile [CA Root Certificate file] </dev/null

After the connection is opened you may issue commands such as “GET /”, which “gets” the top-level web page of the server in the example above. The connection will close automatically if a command is issued, or you can terminate the session by entering Ctl-D.

To test a mail server connection (default send port is 25) use the command:

openssl s_client -connect [hostname]:[port] -starttls smtp -CAfile [CA Root Certificate file]

After the connection is opened you may issue commands such as "ehlo case.edu", which returns the services that are enabled on the mail server in the example above. You can even send mail by entering "raw" SMTP commands:

mail From: me@me.com
rcpt To: anyone@case.edu
data
Subject: Hi There!

[Text of message ended by a "." alone on a line. ]
.

To exit and close the connection enter

quit

Creating a CSR Using OpenSS

NOTE: As of December 31,2010 the National Institute of Standards for Technology (NIST) has strongly recommended that all keys used for generating CSRs be created using 2048-bit encryption instead of the former 1024-bit encryption. Every vendor has complied with that recommendation and as of 12/31/2010 no vendor will accept a CSR created using a 1024-bit encrypted key. I’ve updated the two openssl commands below to show key generation using 2048-bit encryption (the -newkey rsa:2048 part of the command), however in the command to create the CSR using an existing key, be aware that if the existing key has been generated using 1024-bit encryption, a NEW key and CSR must be generated using one of the first two commands below or the vendors will not accept the CSR you create.

To create a new private key (encrypted) at the same time:

openssl req -newkey rsa:2048 -keyout <Apache server dir>/conf/ssl.key/<server name>.key -keyform PEM \
          -out <Apache server dir>/conf/ssl.csr/<server name>.csr -outform PEM

To create a new private key (unencrypted for pubcookie) at the same time:

openssl req -newkey rsa:2048 -nodes -keyout <Apache server dir>/conf/ssl.key/<server name>.key -keyform PEM \
          -out <Apache server dir>/conf/ssl.csr/<server name>.csr -outform PEM

To create a CSR using an existing key:

openssl req -new -key <Apache server dir>/conf/ssl.key/<server name>.key -keyform PEM \
          -out <Apache server dir>/conf/ssl.csr/<server name>.csr -outform PEM

If the key you are using is encrypted, you will be asked to provide the password with which it was generated when openssl goes to generate the CSR.

This will give you something that looks similar to the following:

Copy this entire thing (including the “—–BEGIN...” and “—–END...” lines) into the appropriate form field at the URL above.

You can also check the request using the command:

openssl req -in <Apache server dir>/conf/ssl.csr/<server name>.csr -noout -text

This will generate text output similar to (note that in this updated example, the RSA Public Key is set at 2048-bit encryption:

Certificate Request:
    Data:
        Version: 0 (0x0)
        Subject: C=US, ST=Ohio, L=Cleveland, O=Case Western Reserve University, OU=Technology Infrastructure Services, CN=test.case.edu
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
            RSA Public Key: (2048 bit)
                Modulus (2048 bit):
                    00:bc:54:05:ab:33:c0:fa:37:93:df:4a:a8:37:94:
                    82:eb:17:b0:22:a7:dd:d3:35:13:30:ea:de:4f:ac:
                    0d:3a:41:39:4d:0b:20:ea:6c:7e:d3:c4:fb:f0:78:
                    4a:f6:41:eb:d6:e6:09:d4:6e:37:6e:03:09:7d:0c:
                    37:b0:79:14:c1:16:51:6f:0d:22:43:88:5e:c3:b0:
                    ee:88:cd:70:8f:03:07:1d:f8:32:f7:39:7c:ae:c5:
                    c8:51:a7:2a:eb:c3:ff:ce:9f:2b:be:ef:2e:d2:20:
                    e5:01:08:de:d4:25:a1:37:27:4a:30:a3:9d:af:bd:
                    51:b2:b4:bf:40:7a:03:05:03:d9:5a:0a:ae:fc:23:
                    5d:a3:d8:e9:bd:82:cb:ef:9b:80:7c:45:18:ed:23:
                    29:16:8b:b3:bf:ae:38:8d:33:ef:a0:c4:d9:43:c6:
                    80:39:31:80:eb:80:d0:10:18:04:0a:af:a1:ce:2b:
                    2b:c9:58:d8:58:20:96:ee:2f:e9:d5:6e:56:23:12:
                    f4:e7:96:5a:98:b3:42:b4:e1:a7:0b:ea:e1:40:f0:
                    00:28:e0:c8:ca:4c:58:19:7b:37:dd:71:18:be:10:
                    7c:f6:da:91:85:c2:88:aa:b3:eb:b9:18:37:89:29:
                    8c:94:7e:b3:f4:79:42:b3:33:d0:d5:57:c4:fe:31:
                    11:75
                Exponent: 65537 (0x10001)
        Attributes:
        Requested Extensions:
            X509v3 Subject Alternative Name: 
                DNS:test.cwru.edu
    Signature Algorithm: md5WithRSAEncryption
        ac:e2:0c:c9:d9:52:e2:1b:64:8d:01:96:d4:55:a3:d1:c6:ba:
        af:97:fa:5f:8a:27:5f:8e:ef:48:8e:ff:25:1e:62:82:0e:46:
        a3:5a:19:26:0d:b3:cf:3c:3a:00:72:d6:91:45:96:bd:53:72:
        82:e4:c7:6a:5f:a5:a4:32:34:0c:40:3c:81:74:9b:42:5e:4b:
        6b:4e:8d:b1:d0:7f:0b:f9:14:c6:a2:fe:c2:71:34:63:60:02:
        30:69:d0:81:23:0c:8d:b1:be:c7:08:1f:c0:41:19:7d:16:67:
        1b:97:80:65:ff:6c:22:09:9c:78:1e:1e:9d:b8:81:dc:cb:c9:
        f9:8b:b9:d5:03:93:2d:4e:a1:97:4c:8c:bc:ea:d5:37:19:59:
        66:81:29:4f:66:d9:fa:fe:1a:09:47:2b:80:e9:02:08:f3:ce:
        dd:75:22:b7:bb:34:4f:14:b6:c6:9d:8f:bc:9e:49:82:c8:88:
        73:40:7d:33:68:ee:2f:e9:cb:de:70:0c:a2:d9:81:be:28:a6:
        36:fb:7c:46:0a:a9:6a:11:e5:5c:af:94:cf:f1:5a:b2:a3:61:
        fc:a6:75:e0:fb:16:ea:1f:85:19:ad:c9:c4:38:bc:e3:22:75:
        cd:9c:9b:d9:b4:8b:06:78:66:e7:27:c1:c4:23:43:66:18:e5:
        d1:92:60:60

Here’s an interesting one. The following is what you need to digitally sign (but not encrypt) a message:

openssl smime -in <message body> -sign -text -CAfile /apps/pkg/CWRU/files/ca-bundle.crt \
        -signer <signer PEM certificate> -inkey <unencrypted key for cert> -from <from field> \
        -to <to field> -subject <subject field> | sendmail -t

If you don’t want to have an unencrypted key floating around:

openssl smime -in <message body> -sign -text -CAfile /apps/pkg/CWRU/files/ca-bundle.crt \
        -signer <signer PEM certificate> -inkey <encrypted key for cert> -passin pass:<password> \
        -from <from field> -to <to field> -subject <subject field> | sendmail -t