SSL Certificates - KBA

General Information

SSL certificates are used to secure web traffic. SSL certificates can be used with any object using SSL or TLS to encrypt traffic. For example, SSL certificates encrypt:

  • traffic between a browser and web server
  • traffic between client software and servers (i.e., Outlook mail client and CWRU mail servers)

SSL certificates are tied to specific domains. CWRU has authority over the following domains (and no others):

  • cwru.edu
  • case.edu
  • clevelandactu.org

Policies

Who may request a certificate

CWRU provides SSL certificates free of charge to CWRU faculty and staff, affiliates (e.g., contractors and temporary employees) acting on behalf CWRU faculty or staff, and CWRU faculty or staff organizations.

CWRU does NOT provide SSL certificates to students or student organizations.

As of May 2011, CWRU no longer provides self-signed server certificates.


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.

All CSRs have several things in common:

  1. CSR Requirements
    • MUST have a common (server) name. (ex., common name for web server "https://www.case.edu" would be "www.case.edu".
    • MUST have a domain as part of the common name.
    • Organization is Case Western Reserve University.
    • State is Ohio.
    • Locality is Cleveland.
    • Every CSR (and the certificate created from it) is tied to a private key.
    • Key MUST be 2048 bits or greater or greater.

      NOTE: Performance impact to your web server increases as the size of the key increases due to greater complexity in encrypting and decrypting the data streams.

  2. Signing requirements

    To comply with with National Institute of Standards for Technology (NIST) guidelines, CWRU stopped issuing certificates using the SHA1 signing algorithm. Existing SHA1 certificates CANNOT be renewed and must be requested as new certificates.

  3. When you request a certificate either by the self enrollment form or by contacting certificate-admin@case.edu you MUST provide a contact address that allows multiple recipients (e.g., Google Group address or email list.)

    The certificate management system will use this address to contact you with instructions on how to download your certificate and send you notices when your certificate is expiring.


InCommon Certificate Authority

As certificate security needs change, the intermediate certificates can also change. For that reason we no longer provide intermediate and root CA certificates for pages. Use the certificate "chains" provided in the email issued by Comodo instead.

One chain certificate is created for every server certificate issued under the new service. 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.

CWRU subscribes to the InCommon Certificate Authority service. The service is mediated by InCommon/Internet2 but the actual certificate authority is Comodo.


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

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). You may not secure multiple sites using this type of certificate, even if they all run on the same web server. You may, however, secure multiple pages running on the same site (for example https://oursites.case.edu/mypages/, https://oursites.case.edu/yourpages/).

Request an InCommon SSL (SHA-2) certificate. Please note:

  • Email certificate-admin@CWRU.edu to get the access code for this page if you don't have it already
  • Do not share the access code with anyone except CWRU faculty, staff, or a contractor acting on behalf of one
  • Use your standards-conforming contact email in the self-enrollment form, NOT be your personal email address

Complete the form:

  1. Choose a 1, 2, or 3 year term for the certificate. The term indicates when the certificate will expire and must be renewed.
  2. Choose "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.
  3. 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, click UPLOAD CSR to upload your file.
  4. Enter the server/site name (for example mysite.case.edu) in the "Common Name" field.
  5. 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.
  6. Enter any comments you feel necessary either for you to remember the purpose of the certificate or for the Certificate Administrators.
  7. 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 or multiple domains running on the same server. InCommon Multi-Domain SSL (SHA-2) certificates are also known as Subject Alternative Names (SAN) certificates. A SAN certificate cannot be added to or removed from an existing 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 a CSR as you normally would, and attach it in an email request to certificate-admin@case.edu. Please include:

  1. Certificate Signing Request (CSR)
  2. Certificate term (1, 2, or 3 years)
  3. A comma-separated list of SANs: (ex., for common name [CN] 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.
  4. Contact email address for the certificate.

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:

SSLChecker.com

The SSLChecker.com checks how secure are the certificate and the server on which it is installed. The URL for the analyser is https://www.sslchecker.com/sslchecker. 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 Comodo SSL analyzer, but also gives a letter grade from A to F to the security of the web server. The only drawback of this particular analyser 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.

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.

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

  2. 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 CWRU.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@CWRU.edu
    	data
    	Subject: Hi There!
    
    	[Text of message ended by a "." alone on a line. ]
    	.
  3. To exit and close the connection enter:

    quit

Creating a CSR Using OpenSSL

  1. Create the key
    • Create a new private key (encrypted)

      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
    • Create a new private key (unencrypted for pubcookie)

      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
    • 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. Copy the entire CSR (including the “—–BEGIN...” and “—–END...” lines) into the appropriate form field at the URL above (example text below).

      	
      	-----BEGIN CERTIFICATE REQUEST-----
      	MIIDEDCCAfgCAQAwgZ8xCzAJBgNVBAYTAlVTMQ0wCwYDVQQIEwRPaGlvMRIwEAYD
      	VQQHEwlDbGV2ZWxhbmQxKDAmBgNVBAoTH0Nhc2UgV2VzdGVybiBSZXNlcnZlIFVu
      	aXZlcnNpdHkxKzApBgNVBAsTIlRlY2hub2xvZ3kgSW5mcmFzdHJ1Y3R1cmUgU2Vy
      	dmljZXMxFjAUBgNVBAMTDXRlc3QuY2FzZS5lZHUwggEiMA0GCSqGSIb3DQEBAQUA
      	A4IBDwAwggEKAoIBAQC8VAWrM8D6N5PfSqg3lILrF7Aip93TNRMw6t5PrA06QTlN
      	CyDqbH7TxPvweEr2QevW5gnUbjduAwl9DDeweRTBFlFvDSJDiF7DsO6IzXCPAwcd
      	+DL3OXyuxchRpyrrw//Onyu+7y7SIOUBCN7UJaE3J0owo52vvVGytL9AegMFA9la
      	Cq78I12j2Om9gsvvm4B8RRjtIykWi7O/rjiNM++gxNlDxoA5MYDrgNAQGAQKr6HO
      	KyvJWNhYIJbuL+nVblYjEvTnllqYs0K04acL6uFA8AAo4MjKTFgZezfdcRi+EHz2
      	2pGFwoiqs+u5GDeJKYyUfrP0eUKzM9DVV8T+MRF1AgMBAAGgKzApBgkqhkiG9w0B
      	CQ4xHDAaMBgGA1UdEQQRMA+CDXRlc3QuY3dydS5lZHUwDQYJKoZIhvcNAQEEBQAD
      	ggEBAKziDMnZUuIbZI0BltRVo9HGuq+X+l+KJ1+O70iO/yUeYoIORqNaGSYNs888
      	OgBy1pFFlr1TcoLkx2pfpaQyNAxAPIF0m0JeS2tOjbHQfwv5FMai/sJxNGNgAjBp
      	0IEjDI2xvscIH8BBGX0WZxuXgGX/bCIJnHgeHp24gdzLyfmLudUDky1OoZdMjLzq
      	1TcZWWaBKU9m2fr+GglHK4DpAgjzzt11Ire7NE8Utsadj7yeSYLIiHNAfTNo7i/p
      	y95wDKLZgb4opjb7fEYKqWoR5VyvlM/xWrKjYfymdeD7FuofhRmtycQ4vOMidc2c
      	m9m0iwZ4ZucnwcQjQ2YY5dGSYGA=
      	-----END CERTIFICATE REQUEST-----
  2. Check the request using command

    openssl req -in <Apache server dir>/conf/ssl.csr/<server name>.csr -noout -text
  3. 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=CWRU Western Reserve University, OU=Technology Infrastructure Services, CN=test.CWRU.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
  4. To digitally sign (but not encrypt) a message use

    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
  5. To digitally sign and encrypt

    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