Internet2

InCommon is operated by Internet2

InCommon

About            Participants            Join InCommon

Certificate Service

Subscribe

Need Help?

Fee Schedule

Certificate Manager Login

Password Reset

Changing Exec/RAO

Documentation and Resources

Choosing the Right Type of Certificate

Client Certificates

Code Signing Certificates

Extended Validation (EV) Certificates

IGTF Server Certificates

ECC (Elliptical Curve Cryptography) Certificates

Subscribers

FAQ



Choosing the Right Type of Certificate

10 Quick Questions and Answers

As InCommon increases the range of certificates it offers, some may wonder about the sort of certificate they should be using. This page is designed to help you easily sort this out for yourself via a question and answer format.

Q1. Begin by asking yourself, "Am I getting a certificate for a web server?"

Note that *most* of the certificates that InCommon issues via its partner Comodo are SSL/TLS certificates for web servers.

These sort of certificates will normally be associated with a fully qualified domain name, such as www.example.org

InCommon currently has four (4) broad types of web server certificates available:

  • Regular organization validation (OV) certificates. This is the most common type of web server certificate.

  • Extended validation ("green bar") certificates for high security web servers that merit extra care. If your site uses and extended validation certificate, the address of your web site literally will appear "green"    in some browsers, a special signal to users that the site they're visiting is trustworthy.
  • Extended Validation (EV) certificates are bundled with your InCommon Certificate Service subscription at no additional cost, but getting EV certs does involve additional paperwork, typically including a "lawyer letter." See our EV Certs page for complete details.
  • IGTF server certificates, a new type of certificate specially tailored to meet the unique requirements of the International Grid Trust Federation (see http://www.gridpma.org/). Unless you are administering a system that's part of the IGTF, do not request an IGTF server certificate. They're more tightly constrained (e.g., have a shorter lifetime) than normal web server certificates, just to mention one difference.

Q2. If you're not looking for a certificate for use on a web server (or other server), are you a developer looking for a certificate that you can use to cryptographically sign applications you've created?

If so, you want a code-signing certificate. Those are also available as part of your InCommon Certificate Service subscription at no additional charge. See our code signing cert page for more information

Q3. The third type of certificate that may be of interest to you is a so-called "client certificate."

Do you need to be able to digitally sign emails with cryptographic signatures? Would you like to be able to encrypt sensitive content before sending it through email? If so, you may want to get a client certificate (sometimes also called a "personal certificate" or an "S/MIME certificate" or a "PKI certificate.")

Unlike server certificates, which are associated with a domain name, client certificates are associated with an email address. See our information about getting started with client certificates.

You may also find it helpful to review the client cert tutorial [PDF] that was delivered at the Security Professionals meeting in 2012.

Q4. "I'm told that I need a multidomain certificate. What's that? Can I get one of those from InCommon?"

A multidomain certificate is a specific type of server certificate, and can be useful in cases where a single system services multiple domains, or you want to use the same certificate on a related set of systems.

For example, maybe example.com, example.net and example.org are all served from the same system. A multidomain certificate could be obtained from InCommon covering all of those domains with one cert.

Or perhaps you have a cluster of ssh-accessible systems that are behind a DNS round robin load balancer. You might want ssh1.example.org, ssh2.example.org, ssh3.example.org and ssh4.example.org to all be able to use the same certificate. A multidomain certificate will let you use the same certificate on all of those systems.

A multidomain certificate can have up to one hundred domains on it, but as you add hostnames and the list of systems becomes longer, multidomain certificates can become awkward to work with.

Q5. "I think I need a UCC (unified communication certificate) rather than a multidomain certificate."

They're the same thing. Request a multidomain certificate. See the table on PDF page 40 of the InCommon Certificate Manager RAO Administrator Guide.

Q6. "I want to just get a single certificate that will work for all the systems in my domain, such as all hosts matching the pattern *.example.org"

That's called a wildcard server certificate. While InCommon offers them, we urge you to avoid using wildcard certificates whenever possible. To understand why, consider the following scenario:

A wildcard certificate is obtained for *.example.org and installed on numerous systems, including a security sensitive health care-related system, operationally critical teaching and learning management systems, the campus identity management system, and the campus student bridge club's server. Those systems have widely varying security profiles.

Assume the bridge club server, run by a volunteer with little or no server administration experience, ends up gets compromised and the wildcard certificate and its associated private key gets stolen. This undercuts the security of all the other systems that rely on that certificate, and because the Bridge Club system was compromised, the wildcard certificate will need to be revoked and replaced on ALL systems using that wildcard cert. This can be a real potential "fire drill."

If you'd used system specific certificates, the compromise of a single system (such as the Bridge Club server) would have had no effect on the security of the other servers, and only that single private key and associated certificate would have needed to be replaced. Do yourself a favor and avoid wildcard certificates when you can.

Q7. I want or need certificates that meet the requirements of RFC 6460, "Suite B Profile for Transport Layer Security", see http://tools.ietf.org/html/rfc6460 and http://en.wikipedia.org/wiki/NSA_Suite_B_Cryptography

Suite B certificates are still relatively uncommon because, for example, there are currently only four trusted roots in Firefox that can be used to issue these. Fortunately, Comodo has a trusted root certificate that uses the elliptic curves specified in that profile, and thus we can issue extended validation certificates using a suitable profile upon request. When requesting such certificates through InCommon and Comodo, be sure to emphasize that you need a Suite B certificate, and recognize that you will need to jump through all normal extended validation paperwork in order to get that certificate.

Q8. While virtually all SSL/TLS certificates currently use SHA-1 hashes, I understand that Microsoft will be requiring SHA-2 hashes for certificates after January 1st, 2016 (see "Deprecation of SHA-1 Hashing Algorithms for Microsoft Root Certificate Program," November 12, 2013). Can I get certs from InCommon that use SHA-2 hashes?

InCommon is working with Comodo to offer SHA-2 versions of its current SHA-1 certificate offerings. We anticipate offering new SHA-2 profiles of currently available certificates by the fall of 2014.

Q9. I've got a Microsoft Active Directory implementation, and want an on-premises "sub-ca"/"root signing" certificate as discussed here. Can I get that sort of certificate through the InCommon Certificate Service?

A domain-constrained on-premises sub-ca/root-signing certificate for client certificates is potentially available directly from Comodo, consistent with the requirements of the Certificate and Browser Forum and Mozilla, and the requirements of the Mozilla Certificate Program.

Due to the substantial requirements around issuance of such a certificate, and the ongoing monitoring and auditing required, a substantial additional fee will apply. Sites will also need to meet specific technical requirements including use of an approved hardware security module. For more information and an appropriate referral, please contact admin@incommon.org

Q10. I need a certificate for use in the InCommon Federation. What sort of certificate should I use from the InCommon Certificate Service for that purpose?

That depends. If you are deploying a SAML Identity Provider (IdP) or a SAML Service Provider (SP) in the InCommon Federation, and you need an SSL/TLS certificate for an ordinary browser-facing SAML endpoint, you should use a web server certificate as described in Q1.

If, on the other hand, you need a public/private key pair for XML Signature and/or XML Encryption, you should use a long-lived self-signed certificate, which is the preferred type of certificate inserted into InCommon metadata. For more information about certificates in metadata, see: https://spaces.internet2.edu/x/boY0

 

Copyright 2004-2017 InCommon LLC. All rights reserved. admin@incommon.org. InCommon is operated by Internet2.