Title: How HTTPS Works

HTTPS uses a public key encryption system. Each server has a private key, which is used to encrypt communications with the server.

Each server also has a certificate, which it presents to the browser. The certificate can be used to verify the identity of the server. It's job is to let the browser decided whether to trust the server, generally by confirming that the server is the intended server and not another server intercepting the communications.

If a browser doesn't trust a server's certificate, it complains to the user.

To prevent users from having to manually acknowledge every certificate, there is an industry that institutionalizes the notion of trust. Certificates can be signed by trusted organizations called Certificate Authorities (CA's) like Verisign. CA's are supposed to do background checks to verify that people requesting certificates are who they say they are. You trust Verisign, therefore you trust who Verisign trusts.

Browser manufacturers like Microsoft, Mozilla, Apple, etc. trust Verisign and a handful of other CA's, and so configure their browsers to automatically trust (i.e. not complain when presented with) certificates signed by these CA's.

If your certificate is signed by one of these CA's, the browser will accept it without issuing any warning the user.

There are many other CA's besides the top-level CA's: the U.S. Government, low-cost providers like InstantSSL, and perhaps even your IT department.

In order for HTTPS connections to "just work" and not prompt the user with a warning about a certificate, the browser must trust the certificate. But what if the certificate was not signed directly by one of the top CA's?

Browsers will also trust the certificate if:



As we said earlier, each browser starts with a short list of trusted CA's. There are two ways for additional CA's to become trusted:



The latter is the way most low-cost CA's work; they have their own certificate signed by a higher-level CA, which has its certificate signed by an even higher-level CA, and so on up the chain until a top-level CA is reached.

When a server has a certificate that has been signed by a CA with a trust chain that links it to a top CA, it can prevent the browser from complaining to the user by presenting all the signed certificates for each of the links in the chain all the way up to the top. If the browser sees that your server is trusted by someone it trusts, it will trust your certificate too.

What you need to do to set up HTTPS



Create or Import a Private Key



This covers the encryption part. If you already have a key, you can use it. If not, Traction will generate one for you.

Get Your Certificate Signed



This is optional; if you don't mind your users getting warned about their browsers not knowing who the server is, you can skip this step. Otherwise, you can generate a Certificate Signing Request (CSR) and pay a CA to sign your certificate. They will then send you back a signed copy of your certificate, as well as their own certificate, and all the certificates up the chain to a Trusted CA. You will need to import each of these certificates into your Traction server, which will then present the chain to the browser when a connection is made.





Related Articles
parents (1)
Doc1128: Configuring HTTPS and X.509 Certificates
referenced by (3)
Doc351: Installation and Configuration GuideDoc264: Setting up HTTPSDoc193: Using the Trust Manager
Article: Doc131 (permalink)
Date: March 22, 2008; 4:04:14 PM Eastern Daylight Time

Author Name: Documentation Importer
Author ID: importer