What is HTTPS - Why Secure a

Web Site
Use HTTPS for Storefronts and Ecommerce
Web Sites
Definition:
HTTPS stands for HyperText Transfer Protocol over SSL (Secure Socket Layer). It is a TCP/IP protocol
used by Web servers to transfer and display Web content securely. The data transferred is encrypted
so that it cannot be read by anyone except the recipient.
HTTPS is used by any Web site that is collecting sensitive customer data such as banking information
or purchasing information. If you are making a transaction online, you should make sure that it is
done over HTTPS so that the data remains secure.
You can tell when a page is using HTTPS in two ways:
1.

There will be a lock icon in the browser window pane (usually at the bottom).

2.

The URL will say "https://"

*******************************************************************************
If you're going to run an online store or ecommerce Web site, you should be aware of HTTPS - or
HyperText Transfer Protocol with Secure Sockets Layer. HTTPS is a protocol to transfer encrypted data
over the Web.
There are two primary differences between an HTTPS and an HTTP connection work:

HTTPS connects on port 443, while HTTP is on port 80

HTTPS encrypts the data sent and received with SSL, while HTTP sends it all as plain text

Most Web customers know that they should look for the https in the URL and the lock icon in their
browser when they are making a transaction. So if your storefront is not using HTTPS, you will lose
customers. But even still, it is common to find Web sites that collect money including credit card data
over a plain HTTP connection. This is very bad.
As I said above, HTTP sends the data collected over the Internet in plain text. This means that if you
have a form asking for a credit card number, that credit card number can be intercepted by anyone
with a packet sniffer. Since there are many free sniffer software tools, this could be anyone at all. By
collecting credit card information over an HTTP (not HTTPS) connection, you are broadcasting that
credit card information to the world. And the only way your customer will learn it was stolen is when
it's maxed out by a thief.

What You Need to Host Secure Pages

There are only a couple things you need in order to host secure pages on your Web site:

A Web server such as Apache with mod_ssl that supports SSL encryption

A Unique IP address - this is what the certificate providers use to validate the secure
certificate

An SSL Certificate from an SSL certificate provider

If you aren't sure about the first two items, you should contact your Web hosting provider. They will be
able to tell you if you can use HTTPS on your Web site.

After You've Got Your HTTPS Certificate

Your hosting provider will need to set up the certificate in your Web server so that every time a page is
accessed via the https:// protocol, it hits the secure server. Once that is set up, you can start building
your Web pages that need to be secure.
Here are some tips for using HTTPS:

Point to all Web forms on the https:// server. Whenever you link to Web forms on your
Web site, get in the habit of linking to them with the full server URL including the https://
designation. This will insure that they always are secured.

Use relative paths to images on secured pages. If you use a full path (http://www...) for
your images, and those images are not on the secure server, your customers will get error
messages that say things like: "Insecure data found. Continue?" This can be disconcerting,
and many people will stop the purchase process when they see that. If you use relative paths,
your images will be loaded from the same secure server as the rest of the page.

Secure only the pages that request and collect data. It is possible to run your entire Web
site on https://, but it slows down the connection and some SSL providers charge you on the
bandwidth secured. You should only secure those pages that collect data.

Secure Sockets Layer - SSL

Setting up a secure Web site requires that you use SSL or the secure sockets layer to encrypt the data
that comes across. These links will help you secure your pages and set up SSL certificates on your
Web sites.

Signed vs. Self-signed Certificates

What is the Difference and How Should They Be Used
When you're building an ecommerce site one of the first things you'll need to set up is a security
certificate so that your server data will be secure. When you set this up, you have the option of
creating a self-signed cerficate or creating a certificate approved by a certificate authority.

Similarities Between Signed and Self-Signed Certificates

Whether you get your certificate signed by a certificate authority or sign it yourself, there is one thing
that is exactly the same on both:

Both certificates will generate a site that cannot be read by third-parties. The data sent over
an https connection or SSL, will be encrypted regardless of whether the certificate is signed or
self-signed.

In other words, both types of certificates will encrypt the data to create a secure website.

Then Why Pay a Certificate Authority?

A certificate authority tells your customers that this server information has been verified by a trusted
source. The most commonly used Certificate Authority is Verisign. Depending upon which CA is used,
the domain is verified and a certificate is issued. Verisign and other more trusted CAs will verify the
existence of the business in question and the ownership of the domain to provide a bit more security
that the site in question is legitimate.
The problem with using a self-signed certificate is that nearly every Web browser checks that an https
connection is signed by a recognized CA. If the connection is self-signed, this will be flagged as
potentially risky and error messages will pop up encouraging your customers to not trust the site.

When Can You Use a Self-Signed Certificate?

Since they provide the same protection, you can use a self-signed cerificate anywhere you would use a
signed certificate. But some places work better than others.
Self-signed certificates are great for testing servers. If you're creating a website that you need to test
over an https connection, you don't have to pay for a signed certificate for that testing site. You just
need to tell your testers that their browser may pop warning messages.
You can also use self-signed certificates for situations that require privacy, but people might not be as
concerned about. For example:

Username and password forms

Collecting personal (non-financial) information

On forms where the only users are people who know and trust you

What it comes down to is trust. When you use a self-signed certificate, you are saying to your
customers "trust me - I am who I say I am." When you use a certificate signed by a CA, you are
saying, "Trust me - Verisign agrees I am who I say I am."

If You're Doing Ecommerce You Need a Signed Certificate

While it is possible your customers will forgive you a self-signed certificate if all they use it for is to
login to your website. But if you're asking them to input their credit card or Paypal information, then
you really need a signed certificate. Most people trust the signed certificates and won't do business
over an HTTPS server without one. So if you're trying to sell something on your website, invest in that
certificate. It's just a cost of doing business.

How To Create a Self-Signed SSL Certificate

If you need to test an https connection but don't want to pay for the Certifiate Authority (CA) to sign
your certificate, you can sign it yourself. Web browsers will report self-signed certificates as
suspicious, so don't use them when you need a real certificate.
1.

Su to root and create a directory that only the root account has access to.

su
mkdircertificates
chmod700certificates
cdcertificates
2.

Use openssl to generate a server key

opensslgenrsades3outserver.key4096
3.

Openssl will request a pass phrase. Type in a sentence that is long and complex but that you
can remember (you'll have to type it at least twice). Try to make it at least 40 characters long,
with punctuation and capital and lowercase letters. The more different characters you use the
better.

4.

Then create the certificate signing request with the server key you created in step 2.

opensslreqnewkeyserver.keyoutserver.csr
1.

Sign your certificate using SSL.

opensslx509reqdays365inserver.csrsignkeyserver.keyout
server.crt
You can set your certificate for any number of days, but I recommend 365 so that you
remember to update it once a year.
2. Once you're done, you'll have the following files:
o

server.crt: The self-signed server certificate

server.csr: Server certificate signing request

server.key: The private server key, does not require a password when
starting Apache

3. Place those files where they are required for your Web server, and turn on HTTPS.
(If you don't know how, contact your server administrator.)