What Happens Between The Web Browser And Server
- A browser attempts to connect to a web site secured with SSL. The browser requests that the web server identify itself.
- The server sends the browser a copy of its SSL certificate.
- The browser checks whether it trusts the SSL certificate. If so, it sends a message to the server.
- The server sends back a digitally signed acknowledgement to start an SSL encrypted session.
- Encrypted data is shared between the browser and the server.
There are 3 essential elements at work in the process described above: a protocol for communications (SSL), credentials for establishing identity (the SSL certificate), and a third party that vouches for the credentials (the certificate authority).
- Computers use protocols to allow different systems to work together. Web servers and web browsers rely on the Secure Sockets Layer (SSL) protocol to enable encrypted communications. The browser’s request that the server identify itself is a function of the SSL protocol.
- Credentials for establishing identity are common to our everyday lives: a driver’s license, a passport, a company badge. An SSL certificate is a type of digital certificate that serves as a credential in the online world. Each SSL certificate uniquely identifies a specific domain and a web server.
- Our trust of a credential depends on our confidence in the organization that issued it. Certificate authorities have a variety of methods to verify information provided by individuals or organizations. Established certificate authorities, are well known and trusted by browser vendors. Browsers extend that trust to digital certificates that are verified by the certificate authority.
What Is a Certificate Authority (CA)?
A certificate authority (CA), also sometimes referred to as a certification authority, is a company or organization that acts to validate the identities of entities (such as websites, email addresses, companies, or individual persons) and bind them to cryptographic keys through the issuance of electronic documents known as digital certificates.
A digital certificate provides:
Authentication, by serving as a credential to validate the identity of the entity that it is issued to.
Encryption, for secure communication over insecure networks such as the Internet.
Integrity of documents signed with the certificate so that they cannot be altered by a third party in transit.
Typically, an applicant for a digital certificate will generate a key pair consisting of a private key and a public key, along with a certificate signing request (CSR). A CSR is an encoded text file that includes the public key and other information that will be included in the certificate (e.g. domain name, organization, email address, etc.). Key pair and CSR generation are usually done on the server or workstation where the certificate will be installed, and the type of information included in the CSR varies depending on the validation level and intended use of the certificate. Unlike the public key, the applicant’s private key is kept secure and should never be shown to the CA (or anyone else).
After generating the CSR, the applicant sends it to a CA, who independently verifies that the information it contains is correct and, if so, digitally signs the certificate with an issuing private key and sends it to the applicant.
When the signed certificate is presented to a third party (such as when that person accesses the certificate-holder’s website), the recipient can cryptographically confirm the CA’s digital signature via the CA’s public key. Additionally, the recipient can use the certificate to confirm that signed content was sent by someone in possession of the corresponding private key, and that the information has not been altered since it was signed. A key part of this aspect of the certificate is something called a chain of trust.
What is a chain of trust?
In SSL/TLS, S/MIME, code signing, and other applications of X.509 certificates, a hierarchy of certificates is used to verify the validity of a certificate’s issuer. This hierarchy is known as a chain of trust. In a chain of trust, certificates are issued and signed by certificates that live higher up in the hierarchy.
A chain of trust consists of several parts:
1. A trust anchor, which is the originating certificate authority (CA).
2. At least one intermediate certificate, serving as “insulation” between the CA and the end-entity certificate.
3. The end-entity certificate, which is used to validate the identity of an entity such as a website, business, or person.
It’s easy to see a chain of trust for yourself by inspecting an HTTPS website’s certificate. When you check an SSL/TLS certificate in a web browser, you’ll find a breakdown of that digital certificate’s chain of trust, including the trust anchor, any intermediate certificates, and the end-entity certificate. These various points of verification are backed up by the validity of the previous layer or “link,” going back to the trust anchor.
What is a trust anchor?
The root certificate authority (CA) serves as the trust anchor in a chain of trust. The validity of this trust anchor is vital to the integrity of the chain as a whole. If the CA is publicly trusted (like SSL.com), the root CA certificates are included by major software companies in their browser and operating system software. This inclusion ensures that certificates in a chain of trust leading back to any of the CA’s root certificates will be trusted by the software.
What is an intermediate certificate?
The root CA or trust anchor has the ability to sign and issue intermediate certificates. Intermediate certificates (also known as intermediate, subordinate, or issuing CAs) provide a flexible structure for conferring the validity of the trust anchor to additional intermediate and end-entity certificates in the chain. In this sense, intermediate certificates serve an administrative function; each intermediate can be used for a specific purpose — such as issuing SSL/TLS or code signing certificates — and can even be used to confer the root CA’s trust to other organizations.
Intermediate certificates also provide a buffer between the end-entity certificate and the root CA, protecting the private root key from compromise. For publicly trusted CAs (including SSL.com), the CA/Browser forum’s Baseline Requirements actually prohibit issuing end-entity certificates directly from the root CA, which must be kept securely offline. This means that any publicly trusted certificate’s chain of trust will include at least one intermediate certificate.
What is an end-entity certificate?
The end-entity certificate is the final link in the chain of trust. The end-entity certificate (sometimes known as a leaf certificate or subscriber certificate), serves to confer the root CA’s trust, via any intermediates in the chain, to an entity such as a website, company, government, or individual person.
An end-entity certificate differs from a trust anchor or intermediate certificate in that it cannot issue additional certificates. It is, in a sense, the final link as far as the chain is concerned.
Why does a chain of trust matter?
A chain of trust ensures security, scalability, and standards compliance for CAs. It also ensures privacy, trust, and security for those who rely upon end-entity certificates, such as website operators and users.