What are Certificate Authorities & Trust Hierarchies?
Certificate Authorities, or Certificate Authorities / CAs, issue Digital Certificates. Digital Certificates are verifiable small data files that contain identity credentials to help websites, people, and devices represent their authentic online identity (authentic because the CA has verified the identity). CAs play a critical role in how the Internet operates and how transparent, trusted transactions can take place online. CAs issue millions of Digital Certificates each year, and these certificates are used to protect information, encrypt billions of transactions, and enable secure communication.
An SSL Certificate is a popular type of Digital Certificate that binds the ownership details of a web server (and website) to cryptographic keys. These keys are used in the SSL/TLS protocol to activate a secure session between a browser and the web server hosting the SSL Certificate. In order for a browser to trust an SSL Certificate, and establish an SSL/TLS session without security warnings, the SSL Certificate must contain the domain name of website using it, be issued by a trusted CA, and not have expired.
According to analyst site Netcraft (www.netcraft.com), in August 2012 there are almost 2.5m SSL Certificates in use for public facing websites. In reality there are probably as many as 50% more than this number in use that cannot be identified by Netcraft on public facing websites. This makes SSL one of the most prevalent security technologies in use today.
With all these SSL Certificates in use, who decides a CA can be trusted?
Browsers, operating systems, and mobile devices operate authorized CA ‘membership' programs where a CA must meet detailed criteria to be accepted as a member. Once accepted the CA can issue SSL Certificates that are transparently trusted by browsers, and subsequently, people and devices relying on the certificates. There are a relatively small number of authorized CAs, from private companies to governments, and typically the longer the CA has been operational, the more browsers and devices will trust the certificates the CA issues. For certificates to be transparently trusted, they must have significant backward compatibility with older browsers and especially older mobile devices – this is known as ubiquity and is one the most important features a CA can offer its customers.
Prior to issuing a Digital Certificate, the CA will conduct a number of checks into the identity of the applicant. The checks relate to the class and type of certificate being applied for. For example, a domain validated SSL Certificate will have verified the ownership of the domain to be included within the Certificate, whereas an Extended Validation SSL will include additional information on the company, verified by the CA through many company checks.
For more information about different classes of SSL Certificates, please see our related article: The Different Classes of Certificates and Their Use Cases
PKI & Trust Hierarchies
Browsers and devices trust a CA by accepting the Root Certificate into its root store – essentially a database of approved CAs that come pre-installed with the browser or device. Windows operates a root store, as does Apple, Mozilla (for its Firefox browser) and typically each mobile carrier also operates its own root store.
The Apple OSX store of trusted Root Certificates
CAs use these pre-installed Root Certificates to issue Intermediate Root Certificates and end entity Digital Certificates. The CA receives certificate requests, validates the applications, issues the certificates, and publishes the ongoing validity status of issued certificates so anyone relying on the certificate has a good idea that the certificate is still valid.
CAs usually create a number of Intermediate CA (ICA) Root Certificates to be used to issue end entity certificates, such as SSL Certificates. This is called a trust hierarchy, and will look something like this:
The GlobalSign Extended Validation CA - G2 is shown in this example as the ICA - it’s trust is inherited from the publicly trusted GlobalSign root (top of the hierarchy). This ICA is able to issue publicly trusted end entity certificates, in this example, the ICA issued an Extended Validation Certificate to www.globalsign.com.
CAs should not issue Digital Certificates directly from the root distributed to the carriers, but instead via one or more of their ICAs. This is because a CA should follow best security practices by minimizing the potential exposure of a Root CA to attackers. GlobalSign is one of the few CAs to have always (since 1996) utilized ICAs.
What goes into running a CA?
As a trust anchor for the Internet, CAs have significant responsibility. As such running a CA within the auditable requirements is a complex task. A CA’s infrastructure consists of considerable operational elements, hardware, software, policy frameworks and practice statements, auditing, security infrastructure and personnel. Collectively the elements are referred to as a trusted PKI (Public Key Infrastructure).
Certificates come in many different formats to support not just SSL, but also authenticate people and devices, and add legitimacy to code and documents. Visit the GlobalSign Products section for more information.