Understanding Root Certificates
A Root Certificate is a digital certificate that belongs to a certificate authority (CA) and is used to sign other certificates. It is the top-most certificate in the certificate chain of trust. Root certificates are pre-installed in web browsers and operating systems by default so users can verify the authenticity of websites and software.
When a website or software presents its certificate, the root CA signature on the certificate is checked against the pre-installed root certificates to verify it hasn’t been tampered with. Root certificates form the foundation of trust online as they validate the identity of entities like websites. Having the correct root certificates installed is critical for secure internet use.
How Do Root Certificates Work?
Root certificates work by establishing a chain of trust that allows entities to verify the identity and validity of other entities in the hierarchy. Here is a high-level overview of how root certificates establish trust:
Why Are Root Certificates Important?
Root certificates are a foundational security mechanism that underpins authentication and encrypted communication across the internet. Here are some reasons why they are important:
Without widely trusted root CAs, much of the encrypted web and PKI-based identity verification would not be possible. Entities depend on root certificates to establish secure connections and authenticate other parties.
Types of Root Certificates
There are two main types of root certificates:
Publicly Trusted Root Certificates
These root certificates are issued by public CAs that are trusted by default in operating systems and browsers. Examples include roots operated by VeriSign, DigiCert, GoDaddy, and GlobalSign. Publicly trusted roots can issue SSL certificates to any website or service. All major browsers and OSes trust hundreds of these roots by default.
Private Root Certificates
These are root certificates that are not widely trusted by default. Private roots are deployed within internal PKI environments like enterprise networks and issue certificates to internal services and devices. Private roots provide the same function as public roots but only for establishing trust within a private context. Private root CAs often chain up to public roots.
Some operating systems like Windows allow manually installing and trusting additional root certificates, but most public roots are trusted automatically. In general, publicly trusted roots are widely distributed, while private roots are localized to specific private networks and devices.
What’s in a Root Certificate?
A root certificate contains standard X.509 certificate information, including:
As a self-signed certificate, the issuer and subject are the same identity, and the signature is generated with the private key matching the public key embedded in the certificate.
How are Root Certificates Created?
Root certificates are generated during the setup and initialization of the root CA. Here is the general process:
The entire environment where keys are generated, and root certificates created should adhere to carefully controlled IT security policies. After the root CA is established, it can begin issuing intermediate and issuing certificates.
How are Root Certificates Distributed?
For a root certificate to do its job, it must be available to relying parties like operating systems, browsers, and devices. Here are some of the common ways root certificates are distributed:
Public CAs must pass audits and meet policy requirements in order to have their root certificates trusted by default in major software. This facilitates seamless certificate validation for end users. Private roots must be manually installed where needed.
Chains of Trust and Path Validation
A certificate chain establishes a chain of trust from a peer certificate to the root CA. Each certificate in the chain is signed by the certificate above it. Chains typically include these elements:
During path validation, the client application verifies the signature on each certificate using the public key in the issuer’s certificate. This climbs the chain until reaching the root certificate, which is trusted based on its presence in the trust store.
If any signature is invalid or the chain is broken, validation fails. The root certificate serves as a trust anchor to finalize the path validation process.
Revoking Root Certificates
If a root CA’s private key is compromised or the root starts malfunctioning, the root certificate must be revoked so it is no longer trusted.
Revoking public root certificates is challenging because they are distributed so widely. Private roots are easier to revoke within an enterprise. Removal from trust stores is the primary revocation method for root certificates.
Example of Root Certificate
Conclusion
Root certificates are fundamental enablers of trust on the internet and within enterprises. By anchoring extensive PKI hierarchies, root CAs allow entities to verify identities and establish secure communications via public/private key pairs and certificates. Rigorous controls and governance of root CAs maintain confidence in the integrity of PKI chains of trust.
What is the difference between a root CA and an intermediate CA?
A root CA holds a self-signed certificate that serves as a trust anchor. An intermediate CA’s certificate is issued and signed by the root CA, or another intermediate CA.
Where are root CA keys normally stored?
Root CA keys are typically stored offline in secure cryptographic hardware like a hardware security module (HSM) and accessed only during key signing ceremonies.
Can I create my own root CA and issue certificates?
Yes, you can create your own root and intermediate CAs for issuing certificates within private environments like internal networks. Publicly trusted root certificate requires more stringent browser/OS acceptance.
How many root CAs are typically operated by a public CA?
Major public CAs like DigiCert operate dozens of independent root CAs that anchor separate intermediate CA hierarchies for different purposes.
How long are root certificate validities?
Root certificates often have validity periods of 20 years or more. However, lower intermediates often have shorter validity periods like 5-10 years.
What is the role of the CA/Browser Forum and IETF with roots?
These organizations establish policies and technical standards around the operation of CAs that issue SSL/TLS certificates trusted by browsers.
Can an intermediate CA ever issue certificates directly?
Yes, intermediate CAs can be configured to issue end-entity certificates directly. The intermediate must first obtain a valid certificate path to a root CA.
How are private root CAs different than public root CAs?
Private root CAs are limited to internal enterprise trusts rather than distributing publicly. Private roots operate under an organization’s own policies and controls.
