Delivering Secure Content Over HTTPS

Secure HTTP, or HTTPS, is a protocol which is used for secure communication over the Internet. HTTPS technology relies on the concept of public key cryptography to accomplish its tasks. In public key cryptography, each party has two keys, a public key and a private key. Information encrypted with a public key can only be decrypted with its private key and vice versa. Public keys are shared to initiate a session.

How HTTPS Works

HTTPS certificates

Any company or entity that intends to secure their customer sessions and details while doing business on their portal needs to obtain a certificate.

Types of certificates

Domain Validation (DV): a Domain Validated certificate is issued after proof that the owner has the right to use their domain is established. This is typically done by the Certificate Authority (CA) sending an email to the domain owner (as listed in a WHOIS database). Once the owner responds, the certificate is issued.

Organizational Validation (OV): for OV certificates, CAs must validate the company name, domain name and other information through the use of public databases. CAs may also use additional methods to insure the information inserted into the certificate is accurate.

Extended Validation (EV): EV certificates are only issued once an entity passes a strict authentication procedure. These checks are much more stringent than OV certificates.

The following table compares these three certificate types:

Type of certDomain validated?Company name validated?Address validated?Pad lock displayed in browser UI?Green address bar?Typical relative price
DVX

X
$
OVXXXX
$$
EVXXXXX$$$

Obtaining a certificate

Step 1: The company creates a Certificate Signing Request (CSR) and during this process, a private key is generated. (To remain secure, certificates must use keys which are at least 2048 bits in length).

The following is contained in a CSR:

NameExplanationExamples

Common Name

The fully-qualified domain name (FQDN) of your server. This must match exactly what you type in your web browser or you will receive a name mismatch error.

*.xyz.com
mail.xyz.com

OrganizationThe legal name of your organization. This should not be abbreviated and should contain suffixes such as Inc, Corp, LLC, etc.XYZ Inc.
Organizational UnitThe division of your organization handling the certificate

Information Technology
IT Department

City/LocalityThe city where your organization is locatedPalo Alto
State/County/RegionThe state/region where your organization is located. This should not be abbreviated.California
Country

The two-letter ISO code for the country where your organization is located

US
GB

Email address

An email address to be used to contact your organizationwebmaster@xyz.com
Public Key

The public key that will go into the certificate

The public key is created automatically

Step 2: A Certificate Authority (CA) then takes the CSR and validates the company in a two-step process:

  1. Ensure the company has control of the domain
  2. Verify if the company is an official organization listed in public government records

Step 3: When the validation process is complete, the CA issues a new public key (certificate) encrypted with the CA's private key.

Step 4: The company then installs the certificate on their web server(s).

How customers communicate with the web server using HTTPS

Interaction between a client browser and web server over SSL

Figure 1: Interaction between a client browser and web server over HTTPS

Step 1: A customer makes a connection to xyz.com on an HTTPS port (typically port 443). This connection is denoted with https instead of http.

Step 2: xyz.com sends back its public key to the customer. Once the customer receives it, their browser decides if it is OK to proceed based on the following criteria:

  • The xyz.com public key must NOT be expired
  • The xyz.com public key must be for xyz.com only
  • The client must have the public key representing the CA, installed in their browser certificate store

Step 3: If the customer decides to trust the certificate, then the customer is sent to xyz.com using his/her public key.

Step 4: xyz.com next creates a unique hash and encrypts it using both the customer's public key and xyz.com's private key, and sends this back to the client.

Step 5: Customer's browser decrypts the hash. This means that xyz.com sent the hash and only the customer is able to read it.

If you have any questions, please contact us.