<h2>Frequently Asked Questions</h2>
    <p>The FAQ is subject to change  as the cert service is refined. </p>
    <p>      1.    <a href="#1">What is the InCommon Certificate Program?</a> What types of certificates are available? <br>
      &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;1a. What does the service cost? What if I'm with a system? <br>
      &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;1b. Are personal certs and code-signing certs included in the cost? <br>
    2.    <a href="#2">Who can subscribe to the InCommon Cert Service?</a><br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2a. Can we take advantage of the certificate service without participating in federated identity services?<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2b. Is Shibboleth a technical requirement for using the Certificate Service?<br>
      3.    <a href="#3">When will this program be available?</a><br>
      4.    <a href="#4">Why is this program attractive to my institution?</a><br>
    5.    <a href="#5">What is Comodo&rsquo;s role in this service?</a></p>
    <p>6.    <a href="#6">Are there any types of certificates excluded from this program?</a><br>
      7.    <a href="#7">How do I sign up for this program?</a><br>
      8.    <a href="#8">What if my campus operates domains other than their primary institutional .edu domain?</a><br>
      9.    <a href="#9">What is the required term of participation?</a><br>
    10.    <a href="#10">Why are Internet2 members being given a 25 percent discount for participation?</a></p>
    <p>11.    <a href="#11">Why is InCommon membership required for participation?</a><br>
      12.    <a href="#12">How does an institution actually acquire certificates?</a><br>
      13.    <a href="#13">What types of interfaces will an institution have to Comodo for certificate issuance and general program administration?</a><br>
      &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;13.a. What is the Certificate Services Manager (CSM)? <br>
      14. <a href="#14">    How many certificate profiles will be supported and what do they cover? </a><br>
    15.    <a href="#15">Can I have my own Campus Root issued under the InCommon hierarchy?</a></p>
    <p>16.    <a href="#16">Will the certificates issued via this program be recognized in other federations?</a> <br>
      17.    <a href="#17">What are the supported browsers, devices and application suites?</a><br>
    18.    <a href="#18">Are non-profit regional research and education networks and other organizations within the .edu domain eligible?<br>
    </a>19. <a href="#19">What is the certificate chain for SSL certificates issued by the InCommon Certificate Service? </a><br>
    20. <a href="#20">I'd like a seal - are those available? <br>
    </a>21. <a href="#21">Will certificates issued by the Certificate Service comply</a> with the emerging InCommon Identity Assurance Profiles (Bronze/Silver)?<br>
    22. <a href="#22">What is the certificate chain for Extended Validation (EV) Certificates</a> issued by the InCommon Certificate Service?<br>
    23. <a href="#23">Do I need to install any certificates in my browser to access web sites</a> that use SSL or EV certificates issued by the InCommon Certificate Service?<br>
    24. <a href="#24">What is the best way to test a server configured with an SSL or EV certificate</a> issued by the InCommon Certificate Service? </p>
    <hr>
    <p><strong><a name="1"></a>1.    What is the InCommon Certificate Program?</strong></p>
    <p>The InCommon Cert Service, created by and for the higher education community, provides unlimited server and personal certificates at one low fee. This includes unlimited SSL, personal signing (coming soon), EV, (coming soon), encryption, code signing PKI, Unified Communications Certificates, SAN certificates, and wildcard certs.</p>
    <p> Internet2 members receive a 25 percent discount. </p>
    <blockquote>
      <p><strong>1a. What does the service cost?</strong> <strong>What if I'm with a system? </strong></p>
      <p>Please see the <a href="cert_fee.html">fee schedule.</a></p>
      <p><strong>1b. Are personal certs and code-signing certs included in the cost? </strong></p>
      <p>Yes, both are included in the base price, but are not yet available. We expect them to be available during the first quarter of 2011.</p>
    </blockquote>
    <p><strong><a name="2"></a>2.    Who can subscribe to the InCommon Cert Service?</strong></p>
    <p>Any higher education institution with its primary location in the United States, and that qualifies for a primary domain name in .edu, may subscribe, as well as not-for-profit regional research and education networking organizations in the United States. Subscribers must be InCommon participants or must join InCommon.</p>
    <blockquote>
      <p><strong>2a. Can we take advantage of the certificate service without participating in federated identity services?</strong></p>
      <p>Yes. You must <a href="../join.html">join InCommon,</a> but you don't need to use the federated identity services. </p>
      <p><strong>2b. Is Shibboleth a technical requirement for using the Certificate Service?</strong></p>
      <p>No. But we are investigating using federated identity management to simplify access to the Certificate Services Manager. </p>
    </blockquote>
    <p><strong><a name="3"></a>3.    When will this program be available?</strong></p>
    <p>The SSL (or server cert) portion of the program is available now. Unlimited person certs will be available&nbsp;during the first quarter of 2011.</p>
    <p><strong><a name="4"></a>4.    Why is this program attractive to my institution?</strong></p>
    <p>The higher education community developed this service to reduce the cost of certificates. Because InCommon is a non-profit, community-driven organization, the primary drivers are to provide value an benefits to the subscribers (rather than providing profit for the certificate provider). The program offers unlimited certs at one annual fee, which is expected to reduce the cost of certificates for many institutions. </p>
    <p><strong><a name="5"></a>5.    What is Comodo&rsquo;s role in this service?</strong></p>
    <p>Comodo is the certificate authority and InCommon has contracted with Comodo for the deep discounts available to colleges and universities. As a commercial CA, Comodo has extensive knowledge of the marketplace and attractive features. Comodo has been operating a similar service with TERENA, the Trans-European Research and Education Networking Association. TERENA&rsquo;s positive association with Comodo, and its significant software development for the Comodo APIs, made this partnership attractive to InCommon and Internet2.</p>
    <p><strong><a name="6"></a>6.    Are there any types of certificates excluded from this program?</strong></p>
    <p>This program includes all certificates listed in #1 above. The program allows institutions to issue so-called wild-card certificates. A primary attraction of wild-carts certs has been to allow a reduction of the number of certs purchased. Given that in this program there is no longer a price penalty for issuance of additional SSL certs, institutions may want to reconsider the use of wild-card certs, as some security experts believe that such certs reduce security due to the extra burden of managing private keys in multiple locations. </p>
    <p><strong><a name="7"></a>7.    How do I sign up for this program?</strong></p>
    <p>There is a <a href="repository/index.html">Certificate Service Subscriber Agreement</a> that is an addendum to the <a href="../docs/policies/participationagreement.pdf">InCommon Federation participation agreement</a>. The subscriber agreement, including the associated terms and conditions, is available at www.incommon.org/cert. InCommon participation is required to take advantage of the certificate service.</p>
    <p><strong><a name="8"></a>8.    What if my campus operates domains other than their primary institutional .edu domain?</strong></p>
    <p>Any domains administered by the institution (e.g., a professional society with a .org domain or even a .com domain) can qualify, as long as the institution can prove that it is the administrative manager for that organization. The key requirement is that the institution be the administrator of record for these domains and organizations. </p>
    <p><strong><a name="9"></a>9.    What is the required term of participation?</strong></p>
    <p>Initially, institutions are required to commit to participation for an initial term of three (3) years, with the cert service fee billed annually. </p>
    <p><strong><a name="10"></a>10.    Why are Internet2 members being given a 25 percent discount for participation?</strong></p>
    <p>InCommon is wholly owned by Internet2 and Internet2 is providing the initial capital required to launch the program.</p>
    <p><strong><a name="11"></a>11.    Why is InCommon membership required for participation?</strong></p>
    <p>This program is an extension of the trust services already being provided and managed by InCommon, and will require InCommon resources, including staff time and effort. In particular, implementation of this program will take advantage of the Registration Authority (RA) already managed by InCommon in establishing the trust services structure with participants. </p>
    <p><strong><a name="12"></a>12.    How does an institution actually acquire certificates?</strong></p>
    <p>InCommon operates the Registration Authority, leveraging its current processes for verifying organizations and identity proofing officials authorized to act on behalf of an institution for certificate issuance. These individuals may be the same or different than the current InCommon administrators. It is expected that at each institution a small number of people (typically two or three) will be authorized to manage the overall institutional certificate program. </p>
    <p>Once an institution authorizes individuals, they will deal directly with the Comodo CA (via either a GUI or API) for requesting individual certificates. InCommon is, by design, not in the path of certificate issuance or revocation (or even in the path of authorizing second-level personnel), only the vetting of the top-level certificate program administrators and the domains they are authorized to administer. </p>
    <p><strong><a name="13"></a>13.    What types of interfaces will an institution have to Comodo for certificate issuance and general program administration?</strong></p>
    <p>Comodo offers both a GUI (called the Comodo Certificate Services Manager, CSM) and an API to their service for certificate issuance, management of second-level personnel and institutional policies for certificate structure, as well as support in matters such as certificate revocation.</p>
    <blockquote>
      <p><strong>13.a. What is the Certificate Services Manager (CSM)? </strong></p>
      <p>The CSM is the web-based interface used to request and manage your certificates. </p>
    </blockquote>
    <p><strong><a name="14"></a>14.    How many certificate profiles are supported and what do they cover? </strong></p>
    <p>There are seven (7)  profiles available to participants. Please note that user certificates are not yet available.</p>
    <ol>
      <li>SSL Server certificate (standard TLS cert &ndash; includes certs with SANs)</li>
      <li> SSL Wildcard certificate (TLS cert with a wildcard CN)</li>
      <li>    EV Server Certificate - issued directly by Comodo and subject to Comodo&rsquo;s domain vetting processes, terms and conditions and CPS, but at no extra charge beyond the base InCommon cert service fee. Please note: EV certs are not yet available, but expected by the end of 2010.</li>
      <li> Code Signing certificate (for signing software that can be trusted when distributed with, e.g., jar files, etc.)</li>
      <li> User certificate (Digital Signature) (for signing email, documents, or authenticating to PKI based services)</li>
      <li> User certificate (Encryption) (for encrypting email, documents, or symmetric keys used to secure data). Comodo has made available a centralized key escrow service, but this is not part of the basic set of services offered in this program at this time. It is available as an add-on. </li>
      <li> User certificate (Dual Use) (a combination of the above two)  &ndash; Comodo has made available a centralized key escrow service, but this is not part of the basic set of services offered in this program at this time. It is available as an add-on.  escrow of dual use certificates is potentially problematic however because it does eliminate the non-repudiation characteristic of signing certificates.</li>
    </ol>
    <p><strong><a name="15" id="15"></a>15.    Can I have my own Campus Root issued under the InCommon hierarchy?</strong></p>
    <p>The initial release of this program does not provide this functionality, but this option is available under the agreement with Comodo. When the GUI for certificate life cycle management has the capability of supporting this option, it is anticipated that institution-based subordinate CAs (and campus-specific profiles and practice statements) will be made available to members who desire this functionality for an additional cost. </p>
    <p><strong><a name="16" id="16"></a>16.    Will the certificates issued via this program be recognized in other federations? </strong></p>
    <p>This functionality is anticipated for a later release of the program based on the demand from the InCommon community. The agreement with Comodo allows for cross-signing of other CAs at an additional cost. </p>
    <p><strong><a name="17" id="17"></a>17.    What are the supported browsers, devices and application suite?</strong></p>
    <p>Extended Validation Browsers:<br>
      Microsoft Internet Explorer 7 +<br>
      Opera 9.5+<br>
      Firefox 3+<br>
      Apple Safari 3.2+<br>
      Google Chrome 1+<br>
      &nbsp;<br>
      Web Browsers:&nbsp;<br>
      Microsoft Internet Explorer 5.01 +&nbsp;<br>
      Mozilla Firefox 1.0+&nbsp;<br>
      Opera 8.0+&nbsp;<br>
      Apple Safari 1.2 +&nbsp;<br>
      Google Chrome AOL 5 +&nbsp;<br>
      Netscape Communicator 4.77 +&nbsp;<br>
      Camino 1.0+&nbsp;<br>
      Konqueror (KDE) Mozilla 0.6 +<br>
      &nbsp;<br>
      Email Clients (S/MIME):&nbsp;<br>
      Microsoft Outlook 99+&nbsp;<br>
      Microsoft Entourage (OS/X)&nbsp;<br>
      Mozilla Thunderbird 1.0+&nbsp;<br>
      Microsoft Outlook Express 5+&nbsp;<br>
      Qualcomm Eudora 6.2+&nbsp;<br>
      Lotus Notes (6+)&nbsp;<br>
      Mail.app (Mac OS X)&nbsp;<br>
      Microsoft / Windows Mail 1.0+ (Vista)&nbsp;<br>
      The Bat 1+<br>
      &nbsp;<br>
      Micro Browsers /PDAs&nbsp;<br>
      Apple iPhone<br>
      iPod Safari 1.0+&nbsp;<br>
      Microsoft Windows Mobile 5* / 6 +<br>
      ACCESS NetFront Browser v3.4 +&nbsp;<br>
      RIM Blackberry v4.2.1 +&nbsp;<br>
      KDDI Openwave v6.2.0.12 +&nbsp;<br>
      Opera Mini v3+&nbsp;<br>
      Opera Mobile 6+&nbsp;<br>
      Sony Playstation Portable Sony Playstation 3&nbsp;<br>
      Netscape Communicator 4.77+&nbsp;<br>
      Nintendo Wii NTT / DoCoMo<br>
      &nbsp;<br>
      Application Suites:&nbsp;<br>
      Microsoft Authenticode Visual Basic for Applications (VBA)&nbsp;<br>
      Adobe AIR Sun&nbsp;<br>
      Java SE 1.4.2+&nbsp;<br>
      Mozilla Suite 1.0+&nbsp;<br>
      Sea Monkey&nbsp;</p>
    <p>Document Security Platforms:&nbsp;<br>
      Microsoft Office (Word, Excel,Powerpoint, Access, InfoPath)&nbsp;</p>
    <p>Server Platforms&nbsp;<br>
      All SSL-Capable Server Platforms</p>
    <p>* Windows Mobile 5 certificates will be issued from a Non InCommon / Internet2 branded subordinate Root.</p>
    <p><strong><a name="18" id="18"></a>18.    Are non-profit regional research and education networks and other organizations within the .edu domain eligible?</strong></p>
    <p>Not for profit regional research and education networking organizations with primary offices in the United States that are not housed within an otherwise eligible educational institution may join this program by paying an annual fee of $2,000. No further discounts are applicable to this fee. In all cases, participation in this program is solely to allow the organization to acquire certificates for staff within that organization and for servers and services operated directly by the organization.  Participation explicitly excludes the ability for the organization to issue certificates to members of the organization or to resell the service to members of the organization.  This fee also applies to any non-Carnegie classified organizations who qualify for participation (i.e., organizations in the United States who currently have a .edu domain).  All participating organizations must still join InCommon as is required for all participants in this program. </p>
    <p><strong><a name="19"></a>19. What is the certificate chain for SSL certificates issued by the InCommon Certificate Service? </strong></p>
 <p>SSL certificates issued prior to February 1, 2011 chain up to the AddTrust root CA in the following way: AddTrust External Root CA:COMODO High Assurance Server CA:End-Entity Certificate  
 <p>SSL certificates issued on February 1, 2011 or later also chain up to the AddTrust root CA, but with a different intermediate CA: AddTrust External Root CA:InCommon Server CA:End-Entity Certificate   
 <p>This intermediate CA is known as the InCommon Intermediate CA, which was deployed on February 1, 2011.
 <p><strong><a name="20"></a>20. I'd like a seal. Are those available?    
    </strong>
    <p>Yes &mdash; go to http://www.trustlogo.com/install
    <p><strong><a name="21"></a>21. Will certificates issued by the Certificate Service comply with the emerging InCommon Identity Assurance Profiles (Bronze/Silver)?    </strong>
    <p> The InCommon PKI subcommittee will ensure that the certificates align with the Identity Assurance Profiles.
    <p><strong><a name="22"></a>22. What is the certificate chain for Extended Validation (EV) certificates issued by the InCommon Certificate Service? </strong>    
    <p>EV certificates chain up to the AddTrust root CA in the following way: AddTrust External Root CA:COMODO Certification Authority:COMODO Extended Validation Secure Server CA:End-Entity Certificate
    <p><a name="23"></a><strong>23. Do I need to install any certificates in my browser to access web sites that use SSL or EV certificates issued by the InCommon Certificate Service?</strong>     
    <p>No, you do not need to install any certificates in the browser. The AddTrust root CA certificate, which is required for browser access, ships with all known browsers. In general, intermediate CA certificates are passed from the server to the browser as needed, so yes, there is a certificate bundle that needs to be installed on the server, but <strong>not</strong> in the browser.    
    <p> If you are a site administrator testing a new server configuration, there is one caveat, however. Some browsers (such as Firefox) will store intermediate CA certificates received from a server in the browser's certificate store, so unless you're careful, you may be tricked into believing your server is configured correctly when in fact it's not. <em>Be sure to remove intermediate CA certificates from your browser's certificate store before testing your server configuration.</em>
    <p><strong><a name="24"></a>24. What is the best way to test a server configured with an SSL or EV certificate issued by the InCommon Certificate Service?     </strong>    
    <p>Be wary of using a browser to test your server configuration. Some browsers (such as Firefox) will store intermediate CA certificates received from a server in the browser's certificate store, so unless you're careful, you may be tricked into believing your server is configured correctly when in fact it's not. To avoid this pitfall, use openssl to definitively test your server configuration:    
    <pre> $ openssl s_client -connect server:port -CApath /etc/ssl/certs/    </pre>
    <p> If the client machine does not have the /etc/ssl/certs/ directory, try the following command instead:    
    <pre> $ openssl s_client -connect server:port -CAfile comodoroot.crt     </pre>
    <p>In either case, if certificate validation passes, you know your server is configured correctly. Note that /etc/ssl/certs/ and comodoroot.crt contain root certificates only; no intermediate CA certificates are included.</p>
  </div>
</div>