Obtain a Digital Certificate
Last Updated April 29, 2016
Certificates are issued by the InCommon Certificate Service. InCommon, a subsidiary of Internet2, has contracted with a commercial provider, Comodo, to implement the service.
For some certificates, users may manage their own requests. You may also choose to have IT staff enter certificate requests. This document describes the options.
Terminology
In order to understand the InCommon Certificate Service, some definitions are useful.
- PKI
- Public Key Infrastructure is the collection of hardware, software, vendors, people, policies, procedures, … which supports the use of digital certificates.
- CAB Forum
- Certification Authority/Browser Forum is a voluntary PKI industry organization of certification authorities (CAs) and web browser maufacturers. One of the functions is to determine best practice in issuing SSL certificates. The term “voluntary” is deceptive. This organization sets standards and significant players in the industry participate.
- CM
- Certificate Manager is the graphical user interface for the certificate service. It may be found at Certificate Manager Login Page.
- CSR
- Certificate Signing Request is the block of data presented to a Certificate Authority when requesting a certificate. It includes the public key which will be embeded in the certificate. Your CSR must be generated with a key length of at least 2048 bits. This is required to meet minimum security standards established by the CAB Forum and required by some government agencies.
- Domain
-
Identifies one or more servers. DNS name(s).
- iastate.edu is a domain
- abc.iastate.edu is a domain contained within iastate.edu
- x.abc.iastate.edu is a domain contained within abc.iastate.edu
- *.x.abc.iastate.edu is a domain that includes all systems contained within x.abc.iastate.edu but does not include x.abc.iastate.edu
- Department
- An entity that has administrative control over one or more domains. This might be a university department, but could also be a college or other unit.
- RAO
- Registration Authority Officer. A person who has the authority to manage digital certificates for the institution (ISU) and, hence, the institution’s domains.
- DRAO
- Department Registration Authority Officer. A person who has the authority to manage digital certificates for a department and, hence, the department’s domains. A DRAO is not required in order to use certificates. One or more may be designated if you wish to have your certificates managed by somone within your unit.
Certificate Types (and how to get ’em)
There are tools provided in ASW to aid with some of the steps described here. See the “Tools” section below. Please do keep reading, however, so that you will have a clue about what the tools do.
In order to begin issuing certificates, some setup needs to be done. Certificates may be “owned” either by a department or by an individual. Ownership typically depends on the certificate type.
SSL or TLS
SSL (Secure Socket Layer) certificates are the ones that supply information needed to create encrypted communication paths between client and server. SSL, per se, is now being replaced by TLS (Transport Layer Security) which is a more secure implementation than SSL. TLS uses the same kind of certificate as SSL, and, in general, the certificates are still called SSL certificates.
An SSL certificate is generally assigned to a server and, hence, is likely to be department owned. Any SSL certificate issued within a domain (e.g., iastate.edu) controlled by the university can simply have ownership assigned to the university. (Think of it as a “department” encompassing all other departments.) However, it makes the system more manageable to have ownership assignment parallel the hierarchy of the DNS system. That is, certificate ownership is assigned to the department that owns the corresponding qualified DNS domain.
The service provides for an ownership hierarchy with department and domain objects defined in the CM. The domain entries are delegated to departments. Each SSL certificate resides in the corresponding CM domain. To get a department entry, an email requesting the entry should be sent to Certificate-Request@iastate.edu. The email must include the name of the unit and the physical address. If the entry is being established for a recognized university unit (college, department, etc.) the official university name should be used. If the requesting unit is part of another “official” university unit, please include that name as well.
For domain entries, the request is also via email to Certificate-Request@iastate.edu. The email must identify the owning department. Department and domain entries may be requested in the same email. There may be multiple domain entries for a department. Domain entries can be added to a department entry as needed.
Finally, you need to decide whether you wish to handle your own certificate orders in the CM or want to have ITS staff enter the orders for you. A DRAO account can be created in the CM and designated to be responsible for certificates for one or more departments.
If you wish to obtain a DRAO account, read on. Otherwise, you may skip this paragraph. A DRAO entry cannot be created until the department entry exists. A DRAO may have authority over more than one department. Again, the request is by email to Certificate-Request@iastate.edu. It must include name, email address, phone number, desired login name, and department(s) for which the person is to be DRAO. (Note that more than one DRAO may be created for a department.) Normally, the login name will be the same as the person’s ISU email address. Email requesting creation of a DRAO account may be combined with the other requests noted above. Once the DRAO account is created, the person will be contacted by phone with the temporary password for the new account.
If you wish to have ITS staff generate your SSL certificates, please send requests to Certificate-Request@iastate.edu.
You must include:
- System name (e.g., mysys.mydept.iastate.edu)
- Software platform (e.g., Apache/Mod SSL, MS IIS 5, …)
- Name, address, email address, and phone number of the responsible person
- Appropriate CSR (Certificate Signing Request)
- Certificate characteristics (e.g., duration (typically one, two, or three years), wild-card, etc.)
Please note that if your university unit has designated a DRAO to handle certificate needs, you should make your requests to that person.
ITS staff may ask for validation of any request for service or record creation under this system. Such validation would normally be by telephone call to the appropriate college or department office.
SSL Types
For most uses, the standard SSL certificate is probably what you want. However, if needed, there are several types of certificate available.
Subject Alternative Name
SAN certificates (also called UCC) have domain names specified in addition to the principal name. These Subject Alternative Names allow the certificate to be used for more than a single domain.
Wildcard
Wildcard certificates allow the lowest level of the domain name to be “wildcarded”. Like the SAN certificates, wildcard certificates can cover multiple systems. However, SAN names are individually specified and are independent of each other. Wildcard names share a common root.
Multi-domain certificates are necessary for some applications. They are convenient. Unless needed, they are not recommended. If any system covered by a multi-domain certificate is compromized, all systems covered by the same certificate become vulnerable. They all share the same cryptographic key-pair.
Extended Validation
EV certificates are issued by a certificate authority only after the identity of the requestor has been validated. ISU has been vetted against independent business data sources. University ownership of the iastate.edu domain has been legally certified. As a result, we can obtain EV certificates under the InCommon service.
EV certificates do not confer enhanced cryptographic security. They do provide enhanced assurance to web site users. An EV certificate recognized by any of the major browsers will result in green highlighting of the address bar. EV certificates are recommended for any site handling the exchange of sensitive data and for sites asking users to present login credentials.
The use of EV certificates makes it much harder for someone to create a spurious replica of your site. People fishing for credentials or other data will often try to create a false copy of a site and use it to trick users into divulging information. Without a valid EV certificate, the green address bar does not appear.
A DRAO who requests an EV certificate through the CM must notify the RAOs after he or she has approved the request. This may be done by email to Certificate-Request@iastate.edu. This is because additional documents must be filed by an RAO to complete EV requests.
Code Signing
In signing code, you accept responsibility for the integrity of the code. Please understand that if you sign malicious software, the fact of the signature makes it traceable.
Code Signing certificates are requested through a process different from that used for SSL certificates. While a Code Signing certificate has a department name associated with it, it is issued to an individual. ( Here, “individual” is defined as someone having a name and a valid ISU email address. Hence, “individual” could be a work group.) The person making the request sends email to Certificate-Request@iastate.edu.
The email must include:
- Name of requestor
- Email address of requestor
- Requested duration (one, two, or three years)
- Reason why the certificate is needed
A request for a certificate will be entered. The result will be an email to the requestor with a link to a site that will complete the CSR and create the request to the vendor. The person requesting the certificate must follow the supplied link and complete the process. Otherwise, the request is incomplete and no certificate will be issued.
Client or Personal
Three types of personal certificates are available. They are described below followed by instructions for ordering. It is important to note that the types are mutually exclusive. That is, you can have only one type of certificate. This is due to a limitation in the creation process.
Signing Certificates
The key-pair associated with a signing certificate is used to digitally sign documents. If your email client supports signing (Outlook, for example, does), you may use a client certificate to digitally sign outgoing mail. Some applications also can create signed documents. Microsoft Word (on Windows systems only) can create signed documents. Adobe Acrobat can create signed PDFs.
Encryption Certificates
The key-pair associated with an encryption certificate is used to encrypt files.
Dual Use Certificates
The key-pair associated with a dual use certificate can be used either for signing or encryption. Because of the restriction to a single certificate type mentioned above, if you need to both sign and encrypt, you should choose this type.
The process for obtaining a Client certificate is similar to that for Code Signing certificates. The person making the request sends email to Certificate-Request@iastate.edu.
The email must include:
- Name of requestor
- Email address of requestor
- Type of Certificate (i.e., Signing, Encryption, or Dual)
A request for a certificate will be entered. The result will be an email to the requestor with a link to a site that will complete the request to the vendor. The person requesting the certificate must wait for the process to complete and then save the resulting certificate bundle. Otherwise, the request is incomplete and no certificate will be issued.
Avoiding Confusion
The certificate generation site will ask for a PIN (optional) and a Password (required). The PIN, if suppled, will need to be entered when you import your certificate into your system. If you do not fill it in, just hit enter when asked for it at import. The Password value is used if, at some time, you want to revoke the certificate.
Specifying the PIN increases security, though it is not wise to leave your personal certificates where others can get them. Some email software for smartphones supports digital signing and encryption. Some of these email packages will not install a certificate unless it is protected by an install password (i.e., PIN ).
If you acquire one type of certificate and discover you need another, you may simply send another request. You should be aware that your original certificate will be revoked when the new request is entered. This should normally not cause a problem, though you may have to configure software to recognize and use the new certificate.
Key Escrow
The vendor for the certificate service (Comodo) provides an escrow facility for client certificate private keys. Escrowed keys are stored in an encrypted database.
To protect against potential loss of business information, keys for encryption certificates issued at ISU are placed in escrow. This means that escrow is done for either encryption or dual use certificates. Signature certificate keys are not escrowed.
The people who can retrieve escrowed keys are the institution Registration Authority Officers (RAOs). The retrieval will only be done at the request of the certificate owner, upon legal order, or upon order from a university officer (VP or above). The retrieval process requires the use of a credential which is kept in a secure location and which the RAOs do not normally possess. When a key is retrieved, the retrieval process automatically revokes the corresponding certificate.
Tools
For your convenience, forms have been created in ASW for some requests. Sign on to ASW, select the “Request for Services” item and then the “Certificate” item. There, you will find four choices.
SSL Web Server Certificate
This will take you to a form which will collect the information and generate the email to request an SSL digital certificate. (As noted above, if your unit has a DRAO, your requests should be made to that person.) If you have a CSR, you will be able to paste it into the form. You may also allow the form to generate the CSR.
Personal Certificate
This form will gather the information and generate a request for one of the three types (signing, encryption, or dual use) of personal certificate.
Code Signing Certificate
This form will generate a request for a code signing certificate.
Request to be a DRAO
The form will generate a request to become a DRAO. You may request to be authorized at either the department or college level. ASW will, based on your University records, also generate the information required for the “department” entry and the “domain” entry, if these are needed. If your request is out of the ordinary (e.g., requesting to become DRAO for a department or college not your own), you should simply send email as described above.
Site Seal
Web pages protected by SSL often carry a seal from the authority which issued the certificate. Should you wish to use such a seal, Comodo’s can be obtained from Trust Logo.
More Information
The present configuration covers systems within iastate.edu and any of its subdomains. If there is a need to add other domains, that can be done with one caveat. Iowa State University must be the administrative authority of record for the domain. When an InCommon registration officer calls the phone number listed in the WHOIS information for the domain in question, they must find that ISU staff have the authority to act for the domain.
At this point, you may ask “So now that I’ve been made a DRAO, what do I do?” Documentation and demos can be found at the InCommon Certificate Service web site. Go to InCommon Federation and select Certificate Service from the menu.
The CM is at Certificate Manager Login Page.
As soon as you have your id and temporary password, you should login to the CM and change your password.
Last Updated April 29, 2016
Copyright © 1999-2011, Iowa State University of Science and Technology. All rights reserved.