(SSL) Server Certificates at UIC

• Introduction
• What is InCommon? Why do we need it?
• Intermediate InCommon Server Certificate Authority (CA) Request
• Requesting an InCommon Comodo Server Certificate Through ACCC
• Generating a Certificate Signing Request (CSR)
• Cautions and Tips

A server certificate is needed to enable SSL operation on a Web or other server. To avoid alarming warning dialogues issued by Web browsers, the certificate must be digitally signed by a trusted third party, a Certificate Authority (CA) such as Comodo, VeriSign, or Thawte, whose signatures are recognized by the browser. Certificate authorities will only issue a certificate after taking steps to verify that the requesting party is authorized to use the name that appears in the Organization field of the certificate.

ACCC has enrolled on behalf of the campus in the InCommon Cert Service, which uses Comodo certificates, a.k.a certs. Under this program, senior ACCC employees are authorized to approve certificate requests for servers in the uic.edu domain. Certificates requested under this program are processed faster (normally 2 business days or less rather than 3-5) and cost less, so the ACCC is able to provide these certs to the campus as a free service. It is usually less hassle as well, since ACCC has already gone through the pains of certifying UIC as a legitimate organization, one step that you will not have to do again.

InCommon is a federation of US educational and research institutions, formed to simplify the process of online trust. An excerpt from InCommon's InCommon Basics page is a good introduction.

"InCommon serves the U.S. education and research communities, supporting a common framework for trustworthy shared management of access to on-line resources. Through InCommon, Identity Providers (IPs, which is the ACCC in this case) can give their users single sign-on convenience and privacy protection, while online Service Providers (SPs, which is anyone using the UIC InCommon certs in their servers) control access to their protected resources."

and

"InCommon's value is based on federated identity management.

"A user clicks on a Service Provider’s resource. Using federating single sign-on software, the user is authenticated by his or her Identity Provider, which releases only enough identity data to allow the Service Provider to make an access decision.

"The Service Provider uses the minimum identity information necessary to control access to the resource.

"InCommon provides a framework of shared policies, trust-establishing processes, and technology standards for IdPs and SPs to follow. This greatly streamlines collaboration with multiple organizations.

"InCommon participants could spend time establishing operating principles, technology hooks, and agreed-upon data exchange elements with each partner; or they could do it once through InCommon and then leverage these common elements for many relationships."

InCommon allows end-user access to a wide variety of protected resources using standards-based Shibboleth® as its single sign-on software. (Shibboleth has similar functions as Bluestem, which has been used at UIC for many years. Bluestem was developed at UIUC.)

For more information, see the InCommon FAQ.

Something that is different about InCommon Server certificates is that they require using intermediate certificates (as of February 1, 2011). 

You can get this cert at: https://www.incommon.org/cert/repository/incommon-ssl.ca-bundle

For more info, see InCommon Certificate Types.

1. Login to the WebStore: http://webstore.illinois.edu/ and place an order for "SSL InCommon Comodo Certificate." We offer 1 and 3 year new requests and renewals.
   
   
2. Email certmgr@uic.edu with the following information:
   • Fully qualified domain name of the server (eg. www-s.department.uic.edu)
   
   
   • Secure HTTP server vendor and version (eg. Apache modssl 1.3.20,  Microsoft IIS 4.0)
   
   
   • Certificate signing request (CSR) generated by your secure server. A CSR is an ASCII text file that includes something that looks like this:

     -----BEGIN NEW CERTIFICATE REQUEST-----
     MIIBuzCCASQCAQAwezELMAkGA1UEBhMCVVMxETAPBgNVBAgTCElsbGlub2lzMQ8w
     ...[etc]
     +fj2LwNBrBaZo+ZFYput
     -----END NEW CERTIFICATE REQUEST-----
             

   See below for instructions on generating a CSR.

• See your secure server's documentation for detailed instructions on how to generate a certificate server request (CSR), created from a 2048-bit or larger key pair. 

  For help with generating a CSR and other certificate issues, consult the Comodo Knowledge Base for your web-server type. Note that for UCC or Multi-Domain SAN certificates the CSR you generate only needs to be for the single Common Name domain, aka the Primary Domain Name. Additional domains that you may require in the Subject Alternative Name will be added at the time of provisioning the certificate, but in any case should always be listed in your written request to calnet-pki@lists.b.e or to your Departmental Certificate Administrator. Note also that you must create at least 2048-bit key pairs as in the examples listed below.
  

• At some point during the process, you will be prompted to enter values for six fields that will be encoded in your certificate. Here is a template for the fields:

  *Common-name : www-s.department.uic.edu
   Organization : University of Illinois at Chicago
  *Organizational Unit : Department of Redundancy Department
   Locality : Chicago
   State : Illinois
   Country : US

  For fields marked with an asterisk, enter the appropriate values for your server and department. All other fields should be entered exactly as shown (no abbreviations, punctuation, capitalization changes, extra spaces, etc.)
  
• If you are prompted for webmaster email address, phone number, or challenge phrase, enter any reasonable values. These three items are not used.
  
  
• If during the process your server prompts you for a Certificate Authority, enter certmgr@uic.edu.
  
  
• Your server will either store the certificate request in a file or email it to certmgr@uic.edu. (It should tell you which of these things it did.) If it stored the request in a file, email the contents of that file to certmgr@uic.edu.
  

• A defect in Microsoft IIS 5 prevents the key management software from being able to request a certificate with a new FQDN while another certificate with a different FQDN exists. Attempting to reload a backup of the old certificate while waiting for the new certificate to arrive has destroyed private key information for the new certificate and rendered it unusable. If you need to change the FQDN in the certificate of an existing server, you will need to delete the current certificate and run without a certificate until the new certificate is received.
  
  
• To correctly generate a CSR for a renewal of a Microsoft IIS 5 server certificate, Windows 2000 must be updated to Service Pack 2 or later.
  
  
• Defects in Microsoft Visual InterDev 1 and 6 and FrontPage 97/98 prevent recognition of Thawte certificates. See KnowledgeBase article Q238662. If you require a certificate recognized by these Microsoft products, you will need to order a certificate directly from VeriSign rather than ordering a Thawte certificate through ACCC.
  
  
• Part of an initial request for a certificate involves generating a public/private keypair that is stored on your server. Since the public key from this keypair is encoded in your certificate, loss of the keypair on your server will render your certificate worthless.
  • Care should be taken to backup your keypair data on another computer, a floppy disk, or perhaps both. Information on keypair backup can be found in Thawte's instuctions for key and CSR generation.
  • Also, part of generating a keypair is specifying a password used to encrypt it. (This prevents someone with access to the keypair data from extracting the private key and using it to decrypt SSL traffic to and from your server.) Forgetting this password could also render your certificate worthless, so pains should be taken to remember it, perhaps writing it down in some hidden place, or sharing it with one or two other people in your department.
  • Note that Thawte, unlike VeriSign, does not have a liberal 30 day no-cost no questions asked certificate reissue policy to cover key or password loss.
    
    
• Your server's fully qualified domain name (FQDN) is encoded in your certificate. This means if you need or want to move your server to a different machine (one with a different FQDN), you will need to request (and pay for) another certificate. You might consider setting up a special DNS alias (CNAME) to use for your secure server and its certificate, for example www.department.uic.edu. This would allowing moving your secure server and its certificate to another machine with only a DNS change (provided the same vendor's HTTP server is used on the new machine.) See your REACH member to arrange for such an alias.