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.

Table of Contents    Terminology
   Certificate Types (and how to get 'em)
      SSL or TLS
      SSL Types
         Subject Alternative Name
         Extended Validation
      Code Signing
      Client or Personal
         Signing Certificates
         Encryption Certificates
         Dual Use Certificates
         Avoiding Confusion
         Key Escrow
      SSL Web Server Certificate
      Personal Certificate
      Code Signing Certificate
      Request to be a DRAO
   Site Seal
   More Information


In order to understand the InCommon Certificate Service, some definitions are useful.

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.
Certificate Manager is the graphical user interface for the certificate service. It may be found at Certificate Manager Login Page.
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.

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
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.
Registration Authority Officer. A person who has the authority to manage digital certificates for the institution (ISU) and, hence, the institution’s domains.
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 (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.

Certificate Authority Intermediate Certificates

Several years ago, the CAB forum instituted the requirement that root CA servers not be used to sign end user certificates. It became necessary for vendors to introduce intermediate Certificate Authorities. In general, the root servers were well known. Web server software and browsers had a collection of default certificates that identified the globally trusted roots. However, these new intermediates were not known and there was now an unknown identity between the end certificate and the trusted root.

Because of this change, it is now important that servers present the intermediate certificates as part of the chain of trust. Server platforms provide a place to install the intermediate CA certificates and you should be careful to install the intermediates provided.

When you get the notice that your SSL certificate is ready to pick up, you will be given choices as to format and content. The format choice (PKCS#7 or X509) should be based on the requirements of your server software. The PKCS#7 and the first of the X509 bundles will include three certificates. One will be the certificate you requested. One will be a root certificate. One will be the Certificate Authority Intermediate Server certificate which will be signed by the root authority (AddTrust) identified by the root certificate.

For the X509 format, the option of retrieving your server certificate separately from the root and intermediate is also provided.

By the way, success in establishing a protected connection to a server with a browser is NOT sufficient to guarantee a valid installation. You don’t know where that browser has been and browsers remember what they have trusted in the past. You should validate your service using a checker. There are a lot of them to choose from (just use Google) and they are generally free. For example, SSL Checker will tell you explicitly if you have done a correct install.

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.

About the Use of the Chrome Browser

As of May 9, 2014, the Chrome browser did not support the type of certificate required for code signing. Until this problem is fixed, attempts to create a code signing certificate using Chrome will fail. The failure will be obvious, the reason not.

Signing Applications for Apple

While an InCommon Code Signing Certificate can indeed be used to sign code intended for Apple systems (e.g., OS X or IOS), the Apple system will not recognize the signature and will treat the code as unsigned. Apple requires that code be signed only with credentials issued by Apple.

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.

Signed Email

The signing of email and the verification of signatures on signed email that you receive is an email client function. Default Web clients for email services typically do not support the signed mail protocols or offer only limited support. For example, though Outlook supports signing, Outlook Web Access offers support only if you are a Windows user running IE as your browser. The Gmail Web interface does not support signing. For these and other services, you will have to choose other clients (e.g.,SeaMonkey) which do offer support if you wish to sign outgoing mail or validate signatures on incoming mail.

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


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