Date: Fri, 29 Mar 2024 00:06:03 +0000 (UTC) Message-ID: <937606518.7233.1711670763247@ip-10-10-7-29.ec2.internal> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_7232_1818035419.1711670763245" ------=_Part_7232_1818035419.1711670763245 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
InCommon Certificate Service SSO and M= FA Available
The use of single sign-on and multifactor authentication for accessing t= he Comodo Certificate Manager is available to any subscriber that also oper= ates an Identity Provider in the InCommon Federation. See this wiki pa= ge for details.
This is a list of frequently asked questions (FAQ) about the InCommon Ce= rtificate Service. See the excellent CA/Browser Forum FAQ for answers to more= general questions.
The InCommon Certificate Service, created by and for the higher educatio= n community, provides unlimited SSL/TLS and client certificates for one low= membership fee. This includes unlimited Organizational Validation (OV) SSL= /TLS certificates, Extended Validation (EV) SSL/TLS certificates, client (o= r personal) certificates, and code-signing certificates.
The higher education community developed this service to reduce the cost= of certificates to campuses. Because InCommon is a non-profit, community-d= riven organization, the program provides value and benefits to the subscrib= ers (rather than providing profit for the certificate provider). The progra= m offers unlimited certificates for a single annual fee, which is expected = to reduce the cost of certificates for many institutions.
Comodo is the certification authority and InCommon has contracted with C= omodo for deep discounts that are made available to colleges and universiti= es. As a commercial certification authority, Comodo has extensive knowledge= of the marketplace and attractive features. Comodo has been operating a si= milar service with TERENA, the Trans-European Research and Education Networ= king Association. TERENA's positive association with Comodo, and its signif= icant software development using the Comodo APIs, made this partnership att= ractive to InCommon and Internet2.
Any higher education institution with its primary location in the United= States, who qualifies for a domain in the .edu name space, may subscribe, = as well as not-for-profit regional research and education networking organi= zations in the United States. Subscribers must be InCommon participants or = must join InCommon to be eligible for the Certificate Service.
Not-for-profit regional research and education networking organizations = with primary offices in the United States that are not housed within an oth= erwise eligible educational institution may join this program by paying an = annual fee of $2,000. No further discounts are applicable to this fee. In a= ll 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 explicit= ly excludes the ability for the organization to issue certificates to membe= rs of the organization or to resell the service to members of the organizat= ion. This fee also applies to any non-Carnegie classified organizations who= qualify for participation (i.e., organizations in the United States who cu= rrently have a .edu domain). All participating organizations must still joi= n InCommon as is required for all participants in this program.
Yes. You must join InCommon but you don't need to use the feder= ated identity services.
Not at the moment, but you will find = it much more secure and convenient to take advantage the SSO/MFA feature fo= r accessing the Certificate Manager (CM).
This program is an extension of the trust services already being provide= d and managed by InCommon, and will require InCommon resources, including s= taff time and effort. In particular, implementation of this program will ta= ke advantage of the Registration Authority (RA) already managed by InCommon= for establishing a trust services infrastructure with participants.
Please see the official fee schedule. Internet2 members receive = a 25 percent discount.
InCommon is wholly owned by Internet2, and Internet2 is providing the in= itial capital required to launch the program.
There is a Certificate Service Subscriber Agreement stored in o= ur document repository. The Subscriber Agreement is an addendum to th= e InCommon Participation Agreement. InCommon = participation is required to take advantage of the certificate service.
Initially, institutions are required to commit to participation for an i= nitial term of three (3) years, with the certificate service fee billed ann= ually.
InCommon operates the Registration Authority, leveraging its current pro= cesses for verifying organizations and identity proofing officials authoriz= ed to act on behalf of an institution for certificate issuance. These indiv= iduals may be the same or different than the current InCommon administrator= s. It is expected that at each institution a small number of people (typica= lly two or three) will be authorized to manage the overall institutional ce= rtificate program.
Once an institution authorizes specific individuals, they will use the I= nCommon Certificate Manager (or the API) for requesting individual certific= ates. InCommon is, by design, not in the path of certificate issuance or re= vocation (or even in the path of authorizing second-level personnel), only = the vetting of the top-level certificate program administrators and the dom= ains they are authorized to administer.
Comodo hosts both a GUI (called the InCommon Certificate Manager, or CM)= and an API to their service for certificate issuance, management of second= -level personnel and institutional policies for certificate structure, as w= ell as support in matters such as certificate revocation.
The CM is the web-based interface used to request and manage your certif= icates.
An RAO is not permitted to create another RAO account. Only an MRAO may = create an RAO account.
Typically, the RAOs for an organization are appointed at the time the or= ganization subscribes to the Certificate Service. To later add another RAO = account (up to a maximum of three RAOs), the vetting process described on t= he Certificate Service subscription page is followed.
The following certificate = types are available to participants:
Yes, private label CAs for user certificates are available under our agr= eement with Comodo. Intermediate CAs are hosted by Comodo, but with ca= mpus-specific names, profiles, and practice statements (if desired). = They are available to subscribers who desire this functionality for an= additional cost. The fees for this service are $3500 for the first y= ear and $2400 in subsequent years.
InCommon does not offer intermediate CAs hosted by members or third part= ies other than Comodo.
This functionality is anticipated for a later release of the program bas= ed upon demand from the InCommon community. Our agreement with Comodo allow= s for cross-signing of other CAs at an additional cost.
Yes, if your organization has an identity provider in the InCommon Feder= ation (you can check here), then your RAOs and DRA= Os can use SSO. In addition, Multifactor Authentication is required f= or RAOs to use SSO.
The InCommon Certificate Service provides for unlimited Organizational V= alidation (OV) SSL/TLS certificates and unlimited Extended Validation (EV) = SSL/TLS certificates.
See the CA/Browser Forum FAQ for definitions of these general terms.
No, the InCommon Certificate Service does not issue Domain Validation (D= V) SSL/TLS certificates, which are the lowest form of SSL/TLS certificate. = Instead, we issue Organizational Validation (OV) SSL/TLS certificates and E= xtended Validation (EV) SSL/TLS certificates.
Note that all OV SSL/TLS certificates are domain validated. Likewise, al= l EV SSL/TLS certificates are organizationally validated. So in that sense,= all SSL/TLS certificates issued by the InCommon Certificate Service are do= main validated.
Any domains administered by the institution (e.g., a professional societ= y with a .org domain or even a .com domain) can qualify, as long as the ins= titution can prove that it is the administrative manager for that domain. T= he key requirement is that the institution be the administrator of record f= or these domains and organizations.
The certificate program allows institutions to issue so-called wild-card= certificates. Traditionally, a primary advantage of wild-card certificates= has been to allow a reduction of the number of certificates purchased. Giv= en that in this program there is no longer a price penalty for issuance of = additional SSL/TLS certs, institutions may wish to reconsider the use of wi= ld-card certificates, as it is generally believed that such certificates re= duce security due to the extra burden of managing private keys in multiple = locations.
A browser would reject an SSL/TLS certificate if the root certificate wa= s not contained in the browser's trusted certificate store. Certificates is= sued by the InCommon Certificate Service are rooted in a CA certificate tru= sted by all known browsers. Therefore this is almost certainly not<= /strong> the problem.
Is your SSL/TLS certificate rejected by multiple browsers, say, three or= more browsers not all on the same platform? Then most likely the SSL/TLS c= ertificate and its private key have not been installed on the server, at le= ast not correctly. Read your server documentation carefully, paying special= attention to any recommended security practices.
Is your SSL/TLS certificate rejected by some browsers and not by others?= Then it's almost certainly the case that the intermediate CA certificate i= n the certificate chain has not been configured correctly on the server. (A= certificate issued by the InCommon Certificate Service has a chain length = of three, with one intermediate CA certificate.) Consult your server docume= ntation how to install the intermediate CA certificate on the server.
As it turns out, you can save yourself some time by not= using a browser for testing purposes. The reason for this is discussed in = subsequent FAQ entries. Some tools that have been found useful for testing = are also mentioned.
See the InCommon Certifica= te Types for answers to this and similar questions.
No, you do not need to install any certificates in the = browser. The AddTrust External CA Root certificate, which is required for b= rowser access, ships with all known browsers. In general, intermediate CA c= ertificates are passed from the server to the browser as needed, so yes, th= ere is a CA certificate bundle that needs to be installed on the server, bu= t not in the browser.
If you are a site administrator testing a new server configuration, ther= e is one caveat, however. Some browsers (such as Firefox) will store interm= ediate CA certificates received from a server in the browser's certificate = store, so unless you're careful, you may be tricked into believing your ser= ver is configured correctly when in fact it's not. Be sure to remove in= termediate CA certificates from your browser's certificate store before tes= ting your server configuration.
Be wary of using a browser to test your server configuration. Some brows=
ers (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 definitiv=
ely test your server configuration:
openssl s_client -connect server:port -CApath /etc/ssl/certs/
= pre>If the client machine does not have an /etc/ssl/certs/ directory, downlo= ad the AddTrust External CA Root certificate, and try the following comma= nd instead:
openssl s_client -connect server:port -CAfile AddTrustExternalCARoo= t.crt
In either case, if certificate validation succeeds, you know your server= is configured correctly. Let's try a specific example:
$ opens= sl s_client -connect www.incommon.org:443 -CAfile AddTrustExternalCARoot.cr= t ---=20 Certificate chain 0 s:/C=3DUS/postalCode=3D48104/ST=3DMI/L=3DAnn Arbor/street=3D1000 Oakbroo= k Drive, suite 300/O=3DInCommon CA/OU=3DPlatinumSSL/CN=3Dwww.incommon.org i:/C=3DUS/O=3DInternet2/OU=3DInCommon/CN=3DInCommon Server CA 1 s:/C=3DUS/O=3DInternet2/OU=3DInCommon/CN=3DInCommon Server CA i:/C=3DSE/O=3DAddTrust AB/OU=3DAddTrust External TTP Network/CN=3DAddTru= st External CA Root 2 s:/C=3DSE/O=3DAddTrust AB/OU=3DAddTrust External TTP Network/CN=3DAddTru= st External CA Root i:/C=3DSE/O=3DAddTrust AB/OU=3DAddTrust External TTP Network/CN=3DAddTru= st External CA Root ---In the example above, note that there are three certificates in the cert= ificate chain. This means that both the intermediate CA certificate (In= Common Server CA) and the root CA certificate (AddTrust External C= A Root) are configured on the server. Only the intermediate CA certifi= cate is required, however. The root certificate does not have to be configu= red on the server.
You can also use the COMODO SSL Analyzer to test a server installation.= p>
What are the supported browsers, devices and application su= ites?
Web Browsers:
Extended Validation (EV) Browsers:
Email Clients (S/MIME):
Micro Browsers / PDAs:
Application Suites:
Document Security Platforms:
Server Platforms:
A subscriber to the InCommon Certificate Service may issue unlimited cli= ent certificates for no additional fee.
Three key usage types of Standard Assurance Client Certificates are avai= lable to subscribers: signing-only, encryption-only, and dual-use client ce= rtificates.
Use cases that involve the long-term encryption of data or documents rai= se the issue of key backup and recovery. Accordingly, key escrow, a service= offered for no additional fee to subscribers of the InCom= mon Certificate Service, provides for backup storage of users' private keys= .
Currently, we offer only Standard Assurance Client Certificates= . The InCommon PKI subcommittee will ensure that future client certificate = types align with emerging InCommon Identity Assurance Profiles (Bronze/Silv= er).
Yes, code-signing certificates are available, and they are included in t= he base price as well.
Unfortunately, no, not all browsers handle client certificates or code-s= igning certificates equally well. For example, Google Chrome can not be use= d to retrieve a client certificate or code-signing certificate. Instead, Ch= rome gives the following error message:
The server returned an invalid client certificate. Error 207 (net::ERR_C= ERT_INVALID)
This issue is discussed further in the Comodo knowledgebase.=
Please visit http://www.trustlogo.com/install