HTTPS Basics

Key Takeaways

• HTTPS, or Hypertext Transfer Protocol Secure, is essential for secure communication over the internet, particularly for websites handling sensitive information like credit card details. It encrypts data and authenticates the website, ensuring the information is safe even if intercepted.
• To implement HTTPS, a website needs a Certificate, issued by a Certificate Authority (CA). This digital document confirms the website’s identity to the user’s browser. The site also requires a private key and a Certificate Signing Request (CSR), which are generated on the server hosting the website.
• HTTPS can be installed using either a self-signed certificate or a third-party signed certificate. While the former is not trusted by browsers and triggers a warning for users, the latter is trusted and costs an annual fee. Once the certificate is installed, secure pages need to be modified to read ‘https://’ instead of ‘http://’.
• The implementation of HTTPS can boost a website’s SEO, as Google uses it as a ranking signal. It also increases user trust and protects against certain types of attacks. Despite the extra steps involved in the SSL handshake process, the impact on website speed is minimal with modern servers and optimized configurations.

What is HTTPS?

Hypertext Transfer Protocol Secure or Hypertext Transfer Protocol over SSL is used for secure communication over a network, or perhaps more importantly – over the Internet. You would see https:// in the URI and a lock icon in the browser when you access a page that uses HTTPS.

If you ever wondered whether and how to go HTTPS with your website, we’ll attempt to clear this up in this article by briefly describing what HTTPS is about, and why and how to implement it.

Why go HTTPS?

Consider developing an e-commerce website that requires your users to enter sensitive information, such as credit card details, in order to proceed with an online transaction. If the information travels over the Internet as is and is intercepted by someone, it could be easily understood and misused. This is where HTTPS comes in – if you need to prevent these types of threats, you need to go HTTPS.

HTTPS promises you two things; first, the sensitive data is encrypted into gibberish by applying a cryptography mechanism which can be decrypted only by your server, the certificate owner. Now, if this information is intercepted with a man-in-the-middle attack, it will be meaningless. Secondly, HTTPS authenticates that the website is the website it claims to be. In your case, it will validate your website before sending your user’s encrypted credit card details so no one else can imitate you.

Thus, going HTTPS authenticates your website and protects sensitive information being communicated over the Internet. This is made possible with the help of Certificates and Encryption.

• Certificates

  In order for you to go HTTPS, you need a Certificate. It is a digital document that your website submits to proclaim your identity to the user, the web browser. The certificates are issued by companies known as Certificate Authorities (CA) which will encrypt your web related information such as your domain name, server platform and identity information such as company’s name address, phone number etc. within the certificate. You may wonder how a browser would trust a certificate. All browsers come with a set of pre-installed information letting them know of trusted certificate authorities. When you go HTTPS, you’ll have your certificate in your server which will be sent to your user whose browser will certify you.

• Encryption

  We know that HTTPS encrypts data before sending it over the Internet and the server decrypts it. In the encryption-decryption scenario, a pair of keys is involved. One is public and the other is private. When your website wants your user to send information, your server instructs the user’s browser with a key (public) to encrypt the data which is to be sent over. Once the encrypted message is received, the server will use its private key to decrypt and understand the data. In HTTPS, any plain text encrypted with the public key can only be decrypted by the holder of the private key.

So how do we get this implemented?

How to go HTTPS

For you to go HTTPS, you need a certificate installed in your server. A certificate can be either self-signed or third party signed. A self-signed certificate is a certificate signed by itself and not trusted by browsers. Users will see a warning when they access a secure web page which is from a server that has a self-signed certificate. However it will be useful in situations like if you want to test your application over a secured connection without any cost or if you want a secured connection in the Intranet. A third party signed certificate on the other hand is verified and issued by a CA trusted by browsers. This will cost you annually, and prices range from 10 dollars to several hundred, depending on certain features certificates provide.

To get a certificate you need a Private Key and a Certificate Signing Request (CSR). These are generated in the server you’ll have your website hosted on. In the previous section under Encryption we saw what a Private Key does. A CSR is simply a request that needs to be submitted to get a certificate. When you generate a CSR, you will enter your identity information such as business name, location etc.

Suppose you get a certificate signed by a CA that’s not trusted by a certain browser or a browser version. This occurs rarely, however if it happens your users would see a “connection not trusted” message. To prevent this, your CA will provide another certificate called chain certificate. This one has a chain of trusted CAs who can verify your CA and the certificate provided.

Installing Self-Signed Certificates

An article in the SSLShopper website explains you how to install a Self-Signed Certificate in your Apache server. It also talks more about self-signed certificates. Look here if you want the certificate in IIS 7.

If your website is at a shared host, you can do the installation using front-end features. C Panel documentation explores how to do this using C Panel and WHM. Most of the times, hosting providers ask for a request from you to install the certificate, regardless of its type.

Installing Certificates signed by CA

You may also purchase a certificate from a CA like Verisign and install it in your server when you deploy your site for commercial use. This SSL installation guide will help with any server you’ve got. The CA also may send you installation instructions or a reference to their support pages via email along with the certificate.

You may look at C Panel documentation and assistance from your hosting provider if your website is at a shared host.

I would also like to show you how BlueHost explains on how to get a self-signed certificate and how to get a CA signed certificate in their host.

HTTPS installed, what is next?

After HTTPS is ready you need to make certain modifications in your website and the server in order to make it work, this process is simple and straightforward.

Pages that need to be communicated securely have to read https:// at the beginning instead of http:// in your website. For example, if you want the page http://mydomain.com/checkout.php to load securely; you need to change all links to that page on your website to https://mydomain.com/checkout.php.
In addition to this, you also need to add a server setup to automatically redirect users who try to access the secure pages via insecure URIs. For example, users who try to access the above page (checkout.php) using http:// should be routed to https://. Let’s see how we do this on Apache.

To do so, you add the following code to the .htaccess file,

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}

This will however redirect all your webpages to https://. If you need only specific pages to be re-directed, the best way is to put those files in a folder or special route through your app’s router, and use a rule like this:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^/?securepage/(.*) https://%{SERVER_NAME}/secureFolder/$1 [R,L]

This rule redirects files in this folder with https:// if they are accessed using http://. This is of course a precaution even though users do not usually change the protocol manually unless their intentions are dishonorable.

There’s one more thing we need to do. There can be resources (images, css files etc.) loaded insecurely on your secure page. To fix this, you simply replace http:// of those files with //, as an example:

link rel="stylesheet" href="http://mysite.com/css/style.css"

Should read as,

link rel="stylesheet" href="//mysite.com/css/style.css"

You’re done! As a best practice visit your secured pages with different browsers and make sure all are OK. You may see the lock icon in your browser. You may also click on it for addition information.

Conclusion

In this article, we went through what HTTPS is, why to go HTTPS and how to implement it. We also went through a few underlying technical aspects to understand how HTTPS works. Hope this helped you to get a clear understanding of what HTTPS is all about and how to work with it. Your feedback is highly welcome!

Frequently Asked Questions (FAQs) about HTTPS