Getting an SSL Certificate/Setting Up HTTPS

If you’re doing any sort of e-commerce, you’ll need a Secure Sockets Layer (SSL) certificate to support Hypertext Transfer Protocol Secure (HTTPS) on your website. I’ll say that again:

If you’re doing e-commerce, you need SSL/HTTPS.

This is not negotiable. I understand that this represents an added expense and hassle, but HTTPS is a must. In this post, I’ll first explain why using HTTPS is a requirement, and then discuss how you go about acquiring and installing an SSL certificate. (Although this post is designed to be generally useful, I’ve included it in my series on Stripe because you’ll need HTTPS setup in order to begin using Stripe to handle payments.)

What Does SSL Do?

SSL, and its newer incarnation Transport Layer Security (TLS), encrypt and decrypt data so that it can be transmitted securely over the Internet. When SSL is used in combination with HTTP, you get HTTPS: a secure way for a browser to access a website. Over HTTPS connections, the data being transmitted between the client (i.e., the browser) and the server cannot be read or manipulated by others. Obviously, this is imperative when any kind of sensitive information is being communicated back and forth.

Note that SSL is not just for securing HTTP connections. It can be used to add security to many types of protocols, such as File Transfer Protocol (FTP) and Simple Mail Transfer Protocol (SMTP). Also, in the case of HTTPS, the browser and server will decide whether to use SSL or TLS for the communication, but I’ll continue to use the more common, colloquial term “SSL” in this article.

What is an SSL Certificate?

An SSL certificate is a type of public key certificate, or digital certificate, that ties a public key to an identity. The key is used by the encryption/decryption process. The identity in the case of HTTPS is a domain name.

Certificates can be signed or unsigned. For example, I can create my own SSL certificate and configure my website to use it. This is an example of a unsigned (or self-signed) certificate. Technically, communications between my browser and my website will be secure using this certificate, as the data transmitted will be encrypted and decrypted. However, because the certificate in this case is self-signed (and therefore, effectively unsigned), most browsers will issue warnings indicating that the interaction may not be secure.

The alternative is to obtain a signed certificate through a Certification Authority (CA). This is a service you must pay for. Understand that certificate itself is just as secure as the self-signed certificate, but the user’s browser will not raise a flag about the connection potentially being unsecure (assuming that the certificate is correctly configured and installed). All browsers keep a running list of legitimate CAs; what you’re buying with a signed certificate is trust: the browser trusts the CA and the CA says that you are trustable. That’s the deal. With a self-signed certificate, you’re saying that you’re trustable, and the browser responds with “I don’t really know this person”.

So if both types of certificates are equally secure, why should you spend the money on a signed certificate? Because of the two types of security.

The Two Types of Security

In my mind, one of the most important security concepts to grasp are the two types of security: perceived and actual. With a house or apartment, there’s the assumption that when the door is closed, it’s also locked, whether it is or not. The mere act of closing the door makes it appear that the domicile is more secure. But it’s not. That’s perceived security. To actually make the unit more secure, the door needs to be locked. That’s actual security.

On every website you create, actual security is paramount. This is even more true with e-commerce, where security failures can have serious repercussions. But end users are rarely aware of the actual security measures in place, particularly when security is implemented properly. Good, actual security is like plumbing in that way: you’re only aware of it when it doesn’t work and you’re left with an awful mess.

On many websites, perceived security is not that important. When I’m at ESPN checking sports scores, I have no security demands or concerns whatsoever. But in e-commerce, perceived security is vital, because you’re asking for someone’s money.

Completing an e-commerce transaction (i.e., a sale) is a two-step process:

1. Convince the customer that the product is worth spending her money on (at your site)
2. Convince the customer that she can trust you (with personal details, with billing information, to actually fulfill the order, etc.)

Perceived security plays a big role in this second step. In fact, I’m of the opinion that properly done e-commerce is a matter of getting out of the customer’s way. The customer has gotten to your site, has decided to purchase X, and now you need to make that process as easy and flawless as possible. Don’t make the customer work harder than she has to and don’t give the customer reasons not to complete the sale. Having the browser suggest that the site may not be trustworthy because you have a self-signed (or improperly installed) certificate is a huge, valid reason not to complete a sale. I know I won’t complete sales at insecure sites, and I hope it’s something you pay attention to, too.

Even if you’re using PayPal (or the like), and all of the billing stuff is being done on PayPal’s server, you should still start that process on a secure page on your site. This conveys to the customer: “I take the time and spend the money to do things right. You can trust me.”

Cutting corners in e-commerce will cost you money in the long run, at best. At worst, it will ruin you.

Or, to put it another way, if you don’t think your e-commerce site will make enough money each year to cover the cost of a real certificate—approximately $200 (USD) per annum, then you shouldn’t be doing that e-commerce site anyway.

Acquiring a Certificate (the easy way)

Once you’ve accepted that you need a signed SSL certificate, regardless what type of e-commerce you’re performing and what payment provider you’re using, the next step is to get one. This can be easy or a bit of a pain, depending upon a few things.

First, I would recommend that if you’re using any kind of managed hosting, you have the hosting company acquire and install the certificate for you. You may end up spending a little bit more this way, but it will be done easily and reliably. You may also need to pay extra for a unique IP address, if you don’t already have one.

If you have managed hosting, pay your host to acquire and install your certificate. Spend your time programming instead.

Acquiring and Installing a Certificate (i.e., the harder way)

If you’re not using managed hosting, and by that I mean you have control of your own server, you’ll need to acquire and install the certificate yourself. The first thing you’ll need to do is create a Certificate Signing Request (CSR). You can do this using the command line open_ssl tool (there are tutorials online for this) or through a control panel.

Control Panel for Creating Certificates

When creating the certificate, the most important consideration is the domain name. Certificates can be associated with just a specific domain, a specific subdomain, or multiple domains. For example, I might want a certificate that works on yii.larryullman.com as well as www.larryullman.com. In that case, the domain name would be *.larryullman.com, where * is a wildcard character.

You really have to think about the domain name for a couple of reasons. First, the certificate will be bound to whatever domain name you provide, so you cannot just use the same certificate if you change domain names later. Second, the more restrictive your certificate is, the cheaper it will be. The less restrictive, the more expensive.

For example, I purchased my most recent certificate from DigiCert. A single domain certificate starts at $195/year (with discounts for multiple years). A wildcard certificate, usable upon multiple subdomains (of the same domain), starts at $595/year. So think about your budget, your long-term plans, and choose accordingly.

For the bits, with the options being 1024 and 2048, you ought to choose 2048, which is more secure. In fact, your CA may require this. (2048 bits here equates to 256-bit encryption; 1024 = 128-bit encryption).

By completing the form or using open_ssl, you’ll end up with a CSR, which is an odd block of meaningful characters (much longer than this):

-----BEGIN CERTIFICATE REQUEST-----
 Ew93d3cuZXhhbXBsZS5uZXQxJDAiBgkqhkiG9w0BCQEWFUxhcnJ5QERNQ0luc2ln
 UB9KtjHeB5E2sYI8UxcN3+hrWUgFnl3pSo/mXxpMRvQOK4lLDugZqArnpFKCzoCy
 JDw6
 -----END CERTIFICATE REQUEST-----

The CSR is provided to the Certificate Authority, including the opening and closing lines. Once you’ve paid the CA and processed everything, the CA will provide you with two (or more) certificates. These are text files with .crt extensions. The contents of the files will be like (but, again, much longer):

-----BEGIN CERTIFICATE -----
 MIICzzCCAbcCAQAwgYkxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJNRDEQMA4GA1UE
 6f2B1RmYwJiRCM8wUXQ55/WpUEM9f3mm57x3vxkvk4TsNjlVPB8BXD7w/jGe4U9W
 f+AsoYdd20I5VBLwYM8ifBWBo2evLpEZKZsm2ey3f7oD0VQ0vilcjW0fJ1f7e+VJ
 -----END CERTIFICATE-----

One of these files will be your certificate, associated with the domain name used to create the CSR. Another file will be the certificate for the signing authority. You will need both.

If you’re using command-line tools, then installing the certificates is a matter of editing the Apache configuration file (httpd.conf). Again, tutorials online explain this in fine detail. If you’re using a control panel, then you can either upload the files or paste their contents into the appropriate spots in the same form used to create the CSR in the first place.

When I used DigiCert, there was also a third, intermediary certificate provided. However, the control panel form only has spots for two certificates and the signing authority certificate on its own wasn’t working. The solution in this case was to use the intermediate certificate and then the signing authority certificate for the signing authority certificate value (i.e., to copy and paste both of those together into one block of text).

Testing

Once you think you’ve got the certificate installed properly (whether you did it or your host did it for you), you should test the installation. There are many online tools for doing so, including:

• SSL Checker
• DigiCert’s SSL Certificate Tester

Once one of those (or another tool) says that your SSL is setup properly, you can use it on your site. However, there is one more test you should do…

Creating Secure Pages

If your SSL is setup properly and you only have a wee bit of HTML in a page, with no external resources at all—JavaScript, CSS, images, or other media, the browser should indicate that a secure connection is established.

A secure connection has been established.

However, if your site references any content at all that’s not being served over HTTPS, then the browser may complain about the site having insecure content (depending upon the browser). In other words, if the page itself is loaded over HTTPS, but an image, a CSS file, or some JavaScript is not loaded over HTTPS, then the customer may still see signs of mistrust. (I just made this mistake myself recently, even though I should know better: the Amazon widget on the secure pages of my Yii book site was not being loaded via HTTPS).

A insecure connection exists because of a problematic resource.

There are a couple of solutions to this problem.

First, if you reference everything via a relative path (e.g., javascript/somefile.js, image/someimage.png), then when the page is loaded via HTTPS, those resources will be, too.

But sometimes you need to use absolute paths (e.g., http://www.example.com/javascript/somefile.js, http://www.example.com/image/someimage.png). There’s an example of this in my “Effortless E-commerce with PHP and MySQL” book, as mod_rewrite was being used for cleaner URLs. If you have to use absolute paths, you’ll run into complications, as sometimes you would want to use HTTP and sometimes HTTPS. The solution is to use a protocol-relative URL: two slashes instead of one (e.g., //javascript/somefile.js, //image/someimage.png). This is an absolute path that the browser will always follow using the current protocol (HTTP or HTTPS).

A third option is to create separate includable files. For example, when using PHP, if I’m not using more formal template systems or a framework, I’ll create one header file that begins the HTML page and a footer file that ends the HTML page. If neither of the above is a good solution, or if I want to make other distinctions between my secure and non-secure pages, I’ll just create a different include that makes the proper absolute references.

Whichever route you go, once you’ve got this figured out, retest the page(s) in your browser and watch for warnings. When you change the HTML, check it again to be sure.

Oh, and go ahead and grab a “seal” image from the CA to add to your site! Looks good, for those that pay attention to such things. (Don’t grab this seal! Grab one from the CA through which you bought your certificate.)

One of DigiCert’s Seal Images

Two More Things…

There are two more quick things I want to mention: how to choose a certificate authority and extended validation certificates.

I used DigiCert for my most recent certificate purchase mostly because that’s who Stripe uses, which is a pretty good recommendation. Verisign (now Symantec), GeoTrust, and Thawte are all established names, too. Their prices are all comparable to, or more expensive than, DigiCert. You don’t have to break the bank, and the most expensive is not the best, just don’t be cheap about choosing a CA.

Better CA’s offer:

• Browser trust in all browsers (i.e., the browser recognizes the CA)
• More, and more flexible, certificate options
• Great customer service

Second, you can also consider getting an extended validation (EV) certificate. An EV certificate means that the CA has taken extra measures to validate that you are who you say you are. There’s no actual security benefit to this, but there is a perceived security benefit: most browsers will emphasize EV status in green in the address bar.

Stripe uses an extended validation certificate.

On the other hand, an EV certificate will cost a tad more, and your business information has to be validated. This means that your business’s address and phone number will need to be registered with a recognized directory such as Dun and Bradstreet (although Google does count as a recognized directory of businesses). Or your lawyer or CPA will need to fill out some validation paperwork, at your expense. I am my own business, so this wasn’t really feasible for me.

So there you have a whole lot of information on SSL certificates. I hope it’s been useful for you and that you appreciate the need to have a certificate if you’re doing e-commerce.

In my next post in this series, I’ll begin setting up a web page to accept payments through Stripe.