Menu Search
Jump to the content X X
Smashing Conf Barcelona

You know, we use ad-blockers as well. We gotta keep those servers running though. Did you know that we publish useful books and run friendly conferences — crafted for pros like yourself? E.g. our upcoming SmashingConf Barcelona, dedicated to smart front-end techniques and design patterns.

The Complete Guide To Switching From HTTP To HTTPS

HTTPS is a must for every website nowadays: Users are looking for the padlock when providing their details; Chrome and Firefox explicitly mark websites that provide forms on pages without HTTPS as being non-secure;[1]1 it is an SEO ranking factor;[2]2 and it has a serious impact on privacy in general.[3]3 Additionally, there is now more than one option to get an HTTPS certificate for free4, so switching to HTTPS is only a matter of will.

Setting up HTTPS can be a bit intimidating for the inexperienced user — it takes many steps with different parties, it requires specific knowledge of encryption and server configuration, and it sounds complicated in general.

In this guide, I will explain the individual components and steps and will clearly cover the individual stages of the setup. Your experience should be easy, especially if your hosting provider also supplies HTTPS certificates — chances are you will be able to perform everything from your control panel quickly and easily.

I have included detailed instructions for owners of shared hosting plans on cPanel, administrators of Apache HTTP servers and of Nginx on Linux and Unix, as well as Internet Information Server on Windows.

Let’s start with the basics.

HTTP Vs. HTTPS Vs. HTTP/2 Vs. SSL Vs. TLS: What’s What? Link

A lot of acronyms are used to describe the processes of communication between a client and a server. These are often mixed up by people who are not familiar with the internals.

The Hypertext Transfer Protocol (HTTP) is the basic communication protocol that both clients and servers must implement in order to be able to communicate. It covers things such as requests and responses, sessions, caching, authentication and more. Work on the protocol, as well as on the Hypertext Markup Language (HTML), started in 1989 by Sir Tim Berners-Lee and his team at CERN. The first official version of the protocol (HTTP 1.0) was released in 1996, shortly followed by the currently widely adopted version (HTTP 1.1) in 1997.

The protocol transfers information between the browser and the server in clear text, allowing the network, through which the information passes, to see the information transmitted. This is a security concern, so HTTP Secure (HTTPS) was introduced, allowing the client and the server to first establish an encrypted communication channel, and then pass the clear text HTTP messages through it, effectively protecting them from eavesdropping.

The encrypted channel is created using the Transport Layer Security (TLS) protocol, previously called Secure Socket Layer (SSL). The terms SSL and TLS are often used interchangeably, with SSL 3.0 being replaced by TLS 1.0. SSL was a Netscape-developed protocol, while TLS is an IETF standard. At the time of writing, all versions of SSL (1.0, 2.0, 3.0) are deprecated due to various security problems and will produce warnings in current browsers, and the TLS versions (1.0, 1.1, 1.2) are in use, with 1.3 currently a draft.

So, sometime around 1996 and 1997, we got the current stable version of the Internet (HTTP 1.1, with or without SSL and TLS), which still powers the majority of websites today. Previously, HTTP was used for non-sensitive traffic (for example, reading the news), and HTTPS was used for sensitive traffic (for example, authentication and e-commerce); however, increased focus on privacy means that web browsers such as Google Chrome now mark HTTP websites as “not private” and will introduce warnings for HTTP in future.

The next upgrade of the HTTP protocol — HTTP/2 — which is being adopted by a growing number of websites, adds new features (compression, multiplexing, prioritization) in order to reduce latency and increase performance and security.

In HTTP version 1.1, the secure connection is optional (you may have HTTP and/or HTTPS independent of each other), while in HTTP/2 it is practically mandatory — even though the standard defines HTTP/2 with or without TLS, most browser vendors have stated that they will only implement support for HTTP/2 over TLS.

What Does HTTPS Provide? Link

Why bother with HTTPS in the first place? It is used for three main reasons:

  • Confidentiality
    This protects the communication between two parties from others within a public medium such as the Internet. For example, without HTTPS, someone running a Wi-Fi access point could see private information such as credit cards when someone using the access point purchases something online.
  • Integrity
    This makes sure information reaches its destined party in full and unaltered. For example, our Wi-Fi friend could add extra advertisements to our website, reduce the quality of our images to save bandwidth or change the content of articles we read. HTTPS ensures that the website can’t be modified.
  • Authentication
    This ensures that the website is actually what it claims to be. For example, that same person running the Wi-Fi access point could send browsers to a fake website. HTTPS ensures that a website that says it’s is actually Some certificates even check the legal identity behind that website, so that you know is YourBank, Inc.

Cryptography In A Nutshell Link

Confidentiality, integrity and authentication aren’t HTTPS-specific: They’re the core concepts of cryptography. Let’s look a little more closely at them.

Confidentiality Link

Confidentiality is privacy — that is, it protects information from being read by an unauthorized third party. The process usually involves turning a readable (i.e. audible and visible) form of the information, called plaintext, into a scrambled, unreadable version, called ciphertext. This process is called encryption. The reverse process — turning the unreadable ciphertext back into readable plaintext — is called decryption. There are many methods — cipher functions (or algorithms) — to encrypt and decrypt information.

In order for two parties to be able to communicate, they should agree on two things:

  1. which algorithm (cipher function) they will use in their communication;
  2. which parameters, password or rules (i.e. secret) will be used with the method selected.

There are two main types of encryption methods:

  • symmetric
    Both parties share a common secret key.
  • asymmetric
    One of the parties has a pair of a secret and a public key, the foundation of public key infrastructure (PKI).

The symmetric class of methods relies on both parties having a shared secret, which the sender uses to encrypt the information, which in turn the receiver decrypts using the same method and key (see the figure below). The problem with these methods is how both parties will negotiate (i.e. exchange) the secret without physically meeting each other — they need to have a secure communication channel of some sort.

Symmetric encryption5

Symmetric encryption (View large version6)

The asymmetric methods come to solve this kind of problem — they are based on the notion of public and private keys. The plaintext is encrypted using one of the keys and can only be decrypted using the other complementary key.

So, how does it work? Let’s assume we have two parties who are willing to communicate with each other securely — Alice and Bob (these are always the names of the fictional characters in every tutorial, security manual and the like, so we’ll honor the tradition here as well). Both of them have a pair of keys: a private key and a public one. Private keys are known only to their respective owner; public keys are available to anyone.

If Alice wants to send a message to Bob, she would obtain his public key, encrypt the plaintext and send him the ciphertext. He would then use his own private key to decrypt it.

If Bob would like to send a reply to Alice, he would obtain her public key, encrypt the plaintext and send her the ciphertext. She would then use her own private key to decrypt it.

Asymmetric encryption7

Asymmetric encryption (View large version8)

When do we use symmetric and when do we use asymmetric encryption? Asymmetric encryption is used to exchange the secret between the client and the server. In real life, we usually do not need two-way asymmetric communication — it is sufficient if one of the parties (we’ll just call it a server, for the sake of simplicity) has the set of keys, so it can receive an encrypted message. It really protects the security of information in only one direction — from the client to the server, because the information encrypted with the public key can only be decrypted using the private key; hence, only the server can decrypt it. The other direction is not protected — information encrypted with the server’s private key can be decrypted with its public key by anyone. The other party (we’ll similarly call it a client) begins the communication by encrypting a randomly generated session secret with the server’s public key, then sends the ciphertext back to the server, which, in turn, decrypts it using its own private key, now having the secret.

Symmetric encryption is then used to protect the actual data in transit, since it’s much faster than asymmetric encryption. The two parties (the client and the server), with the previously exchanged secret, are the only ones able to encrypt and decrypt the information.

That’s why the first asymmetric part of the handshake is also known (and referred to) as key exchange and why the actual encrypted communication uses algorithms known (and referred to) as cipher methods.

Integrity Link

Another concern, solved with HTTPS, is data integrity: (1) whether the entire information arrived successfully, and (2) whether it was modified by someone in transit. In order to ensure the information is transmitted successfully, message digest algorithms are used. Computing message authentication codes (MACs) for each message exchanged are a cryptographic hashing process. For example, obtaining a MAC (sometimes called a tag) uses a method that ensures that it is practically impossible (the term commonly used is infeasible) to:

  • change the message without affecting the tag,
  • generate the same tag from two different messages,
  • reverse the process and obtain the original message from the tag.

Authentication Link

What about authentication? The problem with the real-life application of the public key infrastructure is that both parties have no way of knowing who the other party really is — they are physically separate. In order to prove the identity of the other party, a mutually trusted third party — a certificate authority (CA) — is involved. A CA issues a certificate, stating that the domain name (a unique identifier), is associated with the public key XXX. In some cases (with EV and OV certificates — see below), the CA will also check that a particular company controls that domain. This information is guaranteed by (i.e. certified by) the certificate authority X, and this guarantee is valid no earlier than (i.e. begins on) date Y and no later than (i.e. expires on) date Z. All of this information goes into a single document, called an HTTPS certificate. To present an easily understandable analogy, it is like a country government (a third party trusted by all) issuing an ID or a passport (a certificate) to a person — every party that trusts the government would also accept the identity of the ID holder (assuming the ID is not fake, of course, but that’s outside the scope of this example).

Certification authorities (CAs) are organizations trusted to sign certificates. Operating systems, such as Windows, macOS, iOS and Android, as well as the Firefox browser, have a list of trusted certificates.

You can check which CAs are trusted by your browser:

  • Firefox
    “Options” → “Advanced” → “Certificates” → “View Certificates” → “Authorities”
  • Windows
    “Control Panel” → “Internet Options” → “Content” — “Certificates” → “Trusted Root Certification Authorities / Intermediate Certification Authorities”
  • Mac
    “Applications” → “Utilities” → “Keychain Access.” Under “Category,” pick Certificates”

All certificates are then checked and trusted — by the operating system or browser if directly trusted or by a trusted entity if verified. This mechanism of transitive trust is known as a chain of trust:

Chain of trust9

Chain of trust (View large version10)

You can add other unlisted CAs, which is useful when working with self-signed certificates (which we’ll discuss later).

In most common situations, only the server needs to be known to the client — for example, an e-commerce website to its customers — so, only the website needs a certificate. In other situations, such as e-government systems, both the server and the client, requesting a service, should have their identity proven. This means that both parties should be using certificates to authenticate to the other party. This setup is also outside the scope of this article.

Types Of HTTPS Certificates Link

There are several types of HTTPS certificates. They can be categorized according to the following criteria.

1. Identity Validation Link

  1. Domain validated (DV)
    The most common type of certificate, a DV certificate verifies that the domain matches a particular public key. The browser establishes a secure connection with the server and displays the closed padlock sign. Clicking the sign will show “This website does not supply ownership information.” There are no special requirements other than having a domain — a DV certificate simply ensures that this is the correct public key for that domain. The browser does not show a legal entity. DV certificates are often cheap (10 USD per year) or free — see the sections on Let’s Encrypt1511 and Cloudflare1612 below.
  2. Extended validation (EV)
    EV certificates verify the legal organization behind a website. This is the most trustworthy type of certificate, which is obtained after a CA checks the legal entity that controls the domain. The legal entity is checked with a combination of:

    • control of the domain (such as a DV certificate);
    • government business records, to make sure the company is registered and active;
    • independent business directories, such as Dunn and Bradstreet, Salesforce’s, Yellow Pages, etc.;
    • a verification phone call;
    • inspection of all domain names in the certificate (wildcards are explicitly forbidden for EV certificates).

    As well as the closed padlock sign, EV HTTPS certificates display the name of the validated legal entity — typically a registered company — before the URL. Some devices, such as iOS Safari, will only show the validated legal entity, ignoring the URL completely. Clicking the sign will show details about the organization, such as the name and street address. The cost is between 150 and 300 USD per year.

  3. Organization validated (OV)
    Like EV, OV certificates verify the legal organization behind a website. However, unlike EV, OV HTTPS certificates do not display the verified legal name in the UI. As a result, OV certificates are less popular, because they have high validation requirements, without the benefits of these being shown to users. Prices are in the 40 to 100 USD per year range.

2. Number of Domains Covered Link

Once upon a time, HTTPS certificates generally contained a single domain in the CN field. Later, the “subject alternative name” (SAN) field was added to allow additional domains to be covered by a single certificate. These days, all HTTPS certificates are created equal: Even a single-domain certificate will have a SAN for that single domain (and a second SAN for the www version of that domain). However, many certificate vendors still sell single- and multi-domain HTTPS certificates for historical reasons.

  1. Single domain
    This is the most common type of certificate, valid for the domain names and
  2. Multiple domains (UCC/SAN)
    This type of certificate, also known as Unified Communications Certificate (UCC) or Subject Alternative Names (SAN) certificate, can cover a list of domains (up to a certain limit). It is not limited to a single domain — you can mix different domains and subdomains. The price usually includes a set number of domains (three to five), with the option to include more (up to the limit) for an additional fee. Using it with related websites is advised, because the client inspecting the certificate of any of the websites will see the main domain, as well as all additional ones.
  3. Wildcard
    This type of certificate covers the main domain as well as an unlimited number of subdomains (* — for example,,,,, etc. The limitation is that it covers only subdomains of the main domain.

The variety of HTTPS certificates available is summarized in the table below:

Certificate type Domain validated (DV) Organization validated (OV) Extended validation (EV)
Verified legal owner
Verified legal owner
Owner info displayed in browser
Single domain,
Multiple domains,,,,, etc.
predefined list, up to a certain limit (usually 100)
Wildcard *
matches any subdomain
N/A — all names must be included explicitly in the certificate and inspected by the CA.

The Configuration Link

To recap, four components of HTTPS require encryption:

  1. The initial key exchange
    This uses asymmetric (private and public key) algorithms.
  2. The identity certification (the HTTPS certificate, issued by a certification authority)
    This uses asymmetric (private and public key) algorithms.
  3. The actual message encryption
    This uses symmetric (pre-shared secret) algorithms.
  4. The message digesting
    This uses cryptographic hashing algorithms.

Each of these components has a set of used algorithms (some of them deprecated already) that use different key sizes. Part of the handshake involves the client and the server agreeing on which combination of methods they will use — select one out of about a dozen public key (key exchange) algorithms, one out of about a dozen symmetric key (cipher) algorithms and one out of three (two deprecated) message-digesting (hashing) algorithms, which gives us hundreds of combinations.

For example, the setting ECDHE-RSA-AES256-GCM-SHA384 means that the key will be exchanged using the Elliptic Curve Diffie-Hellman Ephemeral (ECDHE) key exchange algorithm; the CA signed the certificate using the Rivest-Shamir-Adleman (RSA) algorithm; the symmetric message encryption will use the Advanced Encryption Standard (AES) cipher, with a 256-bit key and GCM mode of operation; and message integrity will be verified using the SHA secure hashing algorithm, using 384-bit digests. (A comprehensive list of algorithm combinations13 is available.)

So, there are some configuration choices to be made.

Cipher Suites Link

Deciding the cipher suites to use is a balance between compatibility and security:

  • Compatibility with older browsers needs the server to support older cipher suites.
  • However, many older cipher suites are no longer considered secure.

OpenSSL lists the supported combinations (see above) in order of cryptographic strength, with the most secure at the top and the weakest at the bottom. It is designed in this way because, during the initial handshake between the client and the server, the combination to be used is negotiated until a match is found that is supported by both parties. It makes sense to first try the most secure combinations and gradually resort to weaker security only if there is no other way.

A very useful and highly recommended resource, advising on what cryptographic methods to enable on the server, is the Mozilla SSL Configuration Generator108605914, which we’ll use later on with actual server configurations.

Key Types Link

Elliptic Curve Cryptography (ECC) certificates are faster and use less CPU than the RSA certificates, which is particularly important for mobile clients. However, some services, such as Amazon, CloudFront and Heroku, don’t yet, at the time of writing, support ECC certificates.

A 256-bit ECC key is considered sufficient.

Rivest Shamir Adleman (RSA) certificates are slower but compatible with a wider variety of older servers. RSA keys are larger, so a 2048-bit RSA key is considered minimal. RSA certificates of 4096 and above may hurt performance — they’re also likely to be signed by a 2048-bit intermediary, undermining much of the additional security!

You might have noticed the fluidity of the statements above and the lack of any numbers — it is because what is a heavy load on one server is not on another. The best way to determine the impact on performance is to monitor the load on your server, with your real website(s) and your real visitors. And even that will change over time.

Procedures Link

To obtain an HTTPS certificate, perform the following steps:

  1. Create a private and public key pair, and prepare a Certificate Signing Request (CSR), including information about the organization and the public key.
  2. Contact a certification authority and request an HTTPS certificate, based on the CSR.
  3. Obtain the signed HTTPS certificate and install it on your web server.

There exists a set of files, containing different components of the public key infrastructure (PKI): the private and public keys, the CSR and the signed HTTPS certificate. To make things even more complicated, different parties use different names (and file extensions) to identify one and the same thing.

To start, there are two popular formats for storing the information — DER and PEM. The first one (DER) is binary, and the second (PEM) is a base64-encoded (text) DER file. By default, Windows uses the DER format directly, and the open-source world (Linux and UNIX) uses the PEM-format. There are tools (OpenSSL) to convert between one and the other.

The files we’ll be using as examples in the process are the following:

    This PEM-formatted file contains the private key. The extension .key is not a standard, so some might use it and others might not. It is to be protected and accessible only by the system super-user.
    This PEM-formatted file contains the public key. You do not actually need this file (and it’s never explicitly present), because it can be generated from the private key. It is only included here for illustration purposes.
    This is a certificate signing request. A PEM-formatted file containing organizational information, as well as the server’s public key, should be sent to the certification authority issuing the HTTPS certificate.
    This HTTPS certificate is signed by the certification authority. It is a PEM-formatted file, including the server’s public key, organizational information, the CA signature, validity and expiry dates, etc. The extension .crt is not a standard; other common extensions include .cert and .cer.

File names (and extensions) are not standard; they can be anything you like. I have chosen this naming convention because I think it is illustrative and makes more obvious which component has what function. You can use whatever naming convention makes sense to you, as long as you refer to the appropriate key-certificate files in the commands and server configuration files throughout the process.

The private key is a randomly generated string of a certain length (we’ll use 2048-bit), which looks like the following:


Keep the private key private! This means protect it by very restricted permissions (600), and do not disclose it to anyone.

Its counterpart — the public key — looks like this:

-----END PUBLIC KEY-----

The Certificate Signing Request (CSR) looks like the following:


This particular CSR contains the server’s public key and details about the organization ACME Inc., based in London, UK, and which owns the domain name

Finally, the signed HTTPS certificate looks like the following:


All parts are connected and should match each other. The final certificate was generated for illustration purposes only — it is the so-called self-signed certificate, because it was not signed by a recognized certification authority.

The process will be illustrated with actual steps for cPanel, Linux, FreeBSD and Windows. This is a universal process, valid for all kinds of certificates. If you are interested in getting a free DV certificate, there are other procedures to follow in the sections on Let’s Encrypt1511 and Cloudflare1612.

Step 1: Create A Private Key And A Certificate Signing Request (CSR) Link

In the following examples, we’ll use 2048-bit RSA certificates, for their wide compatibility. If your server provider supports it (for example, if you don’t use Heroku or AWS), you might prefer to use ECC instead.

cPanel Link

  1. Log into your host’s cPanel.
  2. Scroll down to the “Security” section and click “SSL/TLS.”
    cPanel Security section17

    cPanel “Security” section (View large version18)
  3. You are now in the “SSL/TLS Manager” home. Click “Private Keys (KEY)” to create a new private key.
    cPanel SSL/TLS Manager19

    cPanel “SSL/TLS Manager (View large version20)
  4. You will be redirected to a page to “Generate, Paste or Upload a new “Private
    Key.” Select “2048-bit” in the “Key Size” dropdown, and click “Generate.”
    cPanel cPanel Private Key management21

    cPanel “Private Key” management (View large version22)
  5. The new private key will be generated, and you will get a confirmation screen:
    cPanel Private key confirmation23

    cPanel private key confirmation (View large version24)
  6. If you go back to the “Private Keys” home, you will see your new key listed:
    cPanel Private keys with the new key generated25

    cPanel “Private Keys” with the new key generated (View large version26)
  7. Go back to the “SSL/TLS Manager” home. Click “Certificate Signing Requests (CSR)” to create a new certificate request.
    cPanel SSL/TLS Manager27

    cPanel “SSL/TLS Manager” (View large version28)
  8. You will now be presented with the “Generate Service Request” form. Select the previously created private key and fill in the fields. Answer all of the questions correctly (they will be public in your signed certificate!), paying special attention to the “Domains” section, which should exactly match the domain name for which you are requesting the HTTPS certificate. Include the top-level domain only (; the CA will usually add the www subdomain as well (i.e. When finished, click the “Generate” button.
    cPanel create new Certificate Signing Request form29

    cPanel “Create New Certificate Signing Request” form (View large version30)
  9. The new CSR will be generated, and you will get a confirmation screen:
    cPanel CSR confirmation31

    cPanel CSR confirmation (View large version32)
  10. If you go back to the “Certificate Signing Request” home, you will see your new CSR listed:
    cPanel Certificate Signing Request with the new CSR generated33

    cPanel “Certificate Signing Request” with the new CSR generated (View large version34)

Linux, FreeBSD Link

Make sure OpenSSL is installed. You can check by using:

openssl version

If it’s not already present, open the command line and install it for your platform:

  • Debian, Ubuntu and clones
    sudo apt-get install openssl
  • Red Hat, CentOS and clones
    sudo yum install openssl
  • FreeBSD
    make -C /usr/ports/security/openssl install clean

Then, generate a private key and a CSR with a single command:

openssl req -newkey rsa:2048 -nodes -keyout -out

The private key will be generated, and you will be asked some information for the CSR:

Generating a 2048 bit RSA private key
writing new private key to ''
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter ‘.', the field will be left blank.

Answer all questions correctly (they will be public in your signed certificate!), paying special attention to the “Common Name” section (for example, server FQDN or YOUR name), which should exactly match the domain name for which you are requesting the HTTPS certificate. Include the top-level domain only (, the CA will usually add the www subdomain as well (i.e.

Country Name (2 letter code) [AU]:GB
State or Province Name (full name) [Some-State]:London
Locality Name (eg, city) []:London
Organization Name (eg, company) [Internet Widgits Pty Ltd]:ACME Inc.
Organizational Unit Name (eg, section) []:IT
Common Name (e.g. server FQDN or YOUR name) []
Email Address []

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

Internet Information Server (IIS) on Windows Link

  1. Open “Start” → “Administrative Tools” → “Internet Information Services (IIS) Manager.” Click the server name. Double-click “Server Certificates” in the middle column:
    Open Internet Information Services (IIS) Manager. Double-click Server Certificates6135

    Open “Internet Information Services (IIS) Manager.” Double-click “Server Certificates.” (View large version6236)
  2. Click “Create Certificate Request” in the right column.
    Click Create Certificate Request in the right column37

    Click “Create Certificate Request” in the right column. (View large version38)
  3. Enter your organization’s details, paying special attention to “Common
    Name,” which should match your domain name. Click “Next.”
    Enter your organization's details39

    Enter your organization’s details. (View large version40)
  4. Leave the default “Cryptographic Service Provider.” Set the “Bit length” to 2048. Click “Next.”
    Set the Bit length to 204841

    Set the “Bit length” to 2048. (View large version42)
  5. Browse for a place to save the generated CSR and click “Finish.”
    Browse for a place to save the generated CSR and click Finish43

    Browse for a place to save the generated CSR and click ‘Finish’. (View large version44)

Step 2: Obtaining The HTTPS Certificate Link

In order to get your website certificate, first purchase a HTTPS certificate credit of a chosen type (DV, OV, EV, single site, multisite, wildcard — see above) from an HTTPS certificate provider. Once the process is complete, you will have to provide the certificate signing request, which will spend the purchased credit for your chosen domain. You’ll be asked to provide (i.e. to paste in a field or to upload) the whole CSR text, including the -----BEGIN CERTIFICATE REQUEST----- and -----END CERTIFICATE REQUEST----- lines. If you would like to have an EV or OV certificate, you’ll need to provide the legal entity for which you’re requesting the certificate — you might also be asked to provide additional documents to confirm that you represent this company. The certificate registrar will then verify your request (and any supporting documents) and issue the signed HTTPS certificate.

Getting an HTTPS Certificate Link

Your hosting provider or HTTPS registrar might have a different product and registration procedure, but the general logic should be similar.

  1. Find an HTTPS certificate vendor.
  2. Select a type of certificate (DV, OV, EV, single site, multisite, wildcard), and click “Add to cart.” Specify your preferred payment method and complete the payment.
  3. Activate the new HTTPS certificate for your domain. You can either paste or upload the certificate signing request. The system will extract the certificate details from the CSR.
  4. You will be asked to select a method of “Domain Control Validation” — whether by email, uploading an HTML file (HTTP-based) or adding a TXT record to your domain zone file (DNS-based). Follow the instructions for your DCV method of choice to validate.
  5. Wait several minutes until the validation is performed and the HTTPS certificate is issued. Download the signed HTTPS certificate.

Self-Signed Certificates Link

It is also possible to sign a certificate yourself, rather than have a certificate authority do it. This is good for testing purposes because it will be cryptographically as good as any other certificate, but it will not be trusted by browsers, which will fire a security warning — you can claim you are anything you want, but it wouldn’t be verified by a trusted third party. If the user trusts the website, they could add an exception in their browser, which would store the certificate and trust it for future visits.

The example certificate above is a self-signed one — you can use it for the domain, and it will work within its validity period.

You can create a self-signed certificate on any platform that has OpenSSL available:

openssl x509 -signkey -in -req -days 365 -out

Once the certificate is available, you will have to install it on your server. If you are using hosting and HTTPS registration services from the same provider (many hosting providers also sell HTTPS certificates), there might be an automated procedure to install and enable your newly obtained HTTPS certificate for the website. If you are hosting your website elsewhere, you will need to download the certificate and configure your server to use it.

Step 3: Installing The HTTPS Certificate For Your Website Link

cPanel Link

  1. Go back to the “SSL/TLS Manager” home. Click “Certificates (CRT)” to import the new certificate.
    cPanel SSL/TLS Manager45

    cPanel “SSL/TLS Manager” (View large version46)
  2. You will be redirected to a page to “Paste, Upload or Generate” a new “Certificate.” Paste the contents of the certificate file received from the HTTPS registrar or upload it using the “Browse” button.
    cPanel Import a new SSL certificate47

    cPanel “Import” a new HTTPS certificate (View large version48)
  3. When you paste the contents of the HTTPS certificate, it will be parsed, and plain text values will be presented to you for confirmation. Review the contents and click the “Save Certificate” button.
    cPanel Review and confirm SSL certificate49

    cPanel “Review” and confirm HTTPS certificate (View large version50)
  4. The new HTTPS certificate will be saved, and you will get a confirmation screen:
    cPanel SSL certificate confirmation51

    cPanel HTTPS certificate confirmation (View large version52)
  5. If you go back to the “Certificates (CRT)” home, you will see your new HTTPS certificate listed:
    cPanel Certificates with the new SSL certificate listed53

    cPanel “Certificates” with the new HTTPS certificate listed (View large version54)
  6. Go back to the “SSL/TLS Manager” home. Click “Install and Manage SSL for your website (HTTPS)” to assign the new certificate to your existing website.
    cPanel SSL/TLS Manager55

    cPanel “SSL/TLS Manager” (View large version56)
  7. You will be presented with the “Install an SSL Website” form. Click the “Browse Certificates” button and select your HTTPS certificate. Select your website domain from the dropdown list (if it’s not automatically selected), and verify that the fields for “Certificate” and “Private Key” are populated.
    cPanel Install an SSL Website57

    cPanel “Install an SSL Website” (View large version58)

Test to see that you can access your website at the address If all works OK, you will most probably want to permanently redirect your HTTP traffic to HTTPS. To do so, you’ll have to include several lines of code to an .htaccess file (if you’re using an Apache web server) in your website’s root folder:

RewriteEngine On

RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

If the .htaccess file already exists, then paste the RewriteCond and RewriteRule lines only, right after the existing RewriteEngine On directive.

Linux, FreeBSD Link

Place the generated private key (, Certificate Signing Request ( and the valid HTTPS certificate ( in the appropriate locations:

  • Debian, Ubuntu and clones, FreeBSD
    cp /etc/ssl/certs/
    cp /etc/ssl/private/
    cp /etc/ssl/private/
  • Red Hat, CentOS and clones
    cp /etc/pki/tls/certs/
    cp /etc/pki/tls/private/
    cp /etc/pki/tls/private/
    restorecon -RvF /etc/pki

The files should be owned by root and protected by a permission setting of 600.

  • Debian, Ubuntu and clones
    chown -R root. /etc/ssl/certs /etc/ssl/private
    chmod -R 0600 /etc/ssl/certs /etc/ssl/private
  • Red Hat, CentOS and clones
    chown -R root. /etc/pki/tls/certs /etc/pki/tls/private
    chmod -R 0600 /etc/pki/tls/certs /etc/pki/tls/private
  • FreeBSD
    chown -R root:wheel /etc/ssl/certs /etc/ssl/private
    chmod -R 0600 /etc/ssl/certs /etc/ssl/private

Apache Link

To enable the HTTPS version of your website, you should:

  • make sure that mod_ssl is installed on your server,
  • upload the received HTTPS certificate (.crt) file to your server,
  • edit the Apache server configuration files.

Start by checking mod_ssl. Depending on your operating system, either one should work:

apache2 -M | grep ssl
httpd -M | grep ssl

If mod_ssl is installed, you should get either this…

ssl_module (shared)
Syntax OK

… or something similar.

If it’s not present or not enabled, then try this:

  • Debian, Ubuntu and clones
    sudo a2enmod ssl
    sudo service apache2 restart
  • Red Hat, CentOS and clones
    sudo yum install mod_ssl
    sudo service httpd restart
  • FreeBSD (select the SSL option)
    make -C /usr/ports/www/apache24 config install clean
    apachectl restart

Edit the Apache configuration file (httpd.conf):

  • Debian, Ubuntu
  • Red Hat, CentOS
  • FreeBSD

Listen			80
Listen			443

<VirtualHost *:80>
	Redirect 301 /

<VirtualHost *:443>
	Redirect 301 /

<VirtualHost *:443>
	SSLEngine on
	SSLCertificateKeyFile /path/to/private/key

	# Uncomment the following directive when using client certificate authentication
	#SSLCACertificateFile  /path/to/ca_certs_for_client_authentication

	# HSTS (mod_headers is required) (15768000 seconds = 6 months)
	Header always set Strict-Transport-Security "max-age=15768000"

# intermediate configuration, tweak to your needs
SSLProtocol			all -SSLv3
SSLHonorCipherOrder	on
SSLCompression			off
SSLSessionTickets		off

# OCSP Stapling, only in httpd 2.3.3 and later
SSLUseStapling					on
SSLStaplingResponderTimeout		5
SSLStaplingReturnResponderErrors	off
SSLStaplingCache				shmcb:/var/run/ocsp(128000)

This configuration was generated using the Mozilla SSL Configuration Generator108605914, mentioned earlier. Check with it for an up-to-date configuration. Make sure to edit the paths to the certificate and private key. The configuration provided was generated using the intermediate setting — read the limitations and supported browser configurations for each setting to decide which one suits you best.

Some modifications to the generated code were made (marked in bold above) to handle redirects from HTTP to HTTPS, as well as non-www to the www domain (useful for SEO purposes).

nginx Link

Edit the nginx configuration file (nginx.conf):

  • Debian, Ubuntu, Red Hat, CentOS
  • FreeBSD
server {
	listen 80 default_server;
	listen [::]:80 default_server;

	# Redirect all HTTP requests to HTTPS with a 301 Moved Permanently response.
	return 301 https://$host$request_uri;

server {
	listen 443 ssl http2;
	listen [::]:443 ssl http2;

	# certs sent to the client in SERVER HELLO are concatenated in ssl_certificate
	ssl_certificate /path/to/signed_cert_plus_intermediates;
	ssl_certificate_key /path/to/private_key;
	ssl_session_timeout 1d;
	ssl_session_cache shared:SSL:50m;
	ssl_session_tickets off;

	# Diffie-Hellman parameter for DHE ciphersuites, recommended 2048 bits
	ssl_dhparam /path/to/dhparam.pem;

	# intermediate configuration. tweak to your needs.
	ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
	ssl_prefer_server_ciphers on;

	# HSTS (ngx_http_headers_module is required) (15768000 seconds = 6 months)
	add_header Strict-Transport-Security max-age=15768000;

	# OCSP Stapling	---
	# fetch OCSP records from URL in ssl_certificate and cache them
	ssl_stapling on;
	ssl_stapling_verify on;

	## verify chain of trust of OCSP response using Root CA and Intermediate certs
	ssl_trusted_certificate /path/to/root_CA_cert_plus_intermediates;
	resolver <IP DNS resolver>;


This configuration was generated using the Mozilla SSL Configuration Generator108605914, mentioned earlier. Check with it for an up-to-date configuration. Make sure to edit the paths to the certificate and private key. The configuration provided was generated using the intermediate setting — read the limitations and supported browser configurations for each setting to decide which one suits you best.

The generator automatically generates code for handling redirects from HTTP to HTTPS, and it enables HTTP/2 out of the box!

Internet Information Server (IIS) on Windows Link

  1. Open “Start” → “Administrative Tools” → “Internet Information Services (IIS) Manager.” Click the server name. Double-click “Server Certificates” in the middle column:
    Open Internet Information Services (IIS) Manager. Double-click Server Certificates6135

    Open “Internet Information Services (IIS) Manager.” Double-click “Server Certificates.” (View large version6236)
  2. Click “Complete Certificate Request” in the right column.
    Click Complete Certificate Request in the right column63

    Click “Complete Certificate Request” in the right column. (View large version64)
  3. Select the signed certificate file ( that you obtained from the CA. Enter some name in the “Friendly name” field to be able to distinguish the certificate later. Place the new certificate in the “Personal” certificate store (IIS 8+). Click “OK.”
    Select the signed certificate file65

    Select the signed certificate file. (View large version66)
  4. If the process went OK, you should see the certificate listed under “Server
    You should see the certificate listed under Server Certificates67

    You should see the certificate listed under “Server Certificates.” (View large version68)
  5. Expand the server name. Under “Sites,” select the website to which you want to assign the HTTPS certificate. Click “Bindings” from the right column.
    Select the website and click Bindings69

    Select the website and click “Bindings.” (View large version70)
  6. In the “Site bindings” window, click the “Add” button.
    Click the Add button71

    Click the “Add” button. (View large version72)
  7. In the new window, select:
      • “Type”: “https”
      • “IP address”: “All Unassigned”
      • “Port”: “443”

    In the “SSL Certificate” field, select the installed HTTPS certificate by its friendly name. Click “OK.”

    Select https and select the installed SSL certificate73

    Select “HTTPS,” and select the installed HTTPS certificate. (View large version74)
  8. You should now have both HTTP and HTTPS installed for this website.
    You should now have both HTTP and HTTPS installed for this website75

    You should now have both HTTP and HTTPS installed for this website. (View large version76)

Mixed-Content Warnings Link

You might get a warning sign next to the address bar and a message such as “Connection is not secure! Parts of this page are not secure (such as images).” This does not mean that your installation is wrong; just make sure that all links to resources (images, style sheets, scripts, etc.), whether local or from remote servers, do not start with http://. All resources should be pointed to with paths relative to the root (/images/image.png, /styles/style.css, etc.) or relative to the current document (../images/image.png), or they should be full URLs beginning with https://, such as <script src=""></script>.

These tips should eliminate the mixed-content warnings, and your browser should display the closed padlock without an exclamation mark.

Testing Your Server Link

After you have configured your server and have the website up and running on HTTPS, I strongly recommend checking its security configuration using the Qualys SSL Server Test77. This performs a scan of your website, including a comprehensive evaluation of its configuration, possible weaknesses and recommendations. Follow the advice there to further improve your server’s security configuration.

Renewal Link

Your certificate is valid for a set period — typically, a year. Don’t wait to renew it at the last moment — your registrar will start sending you emails as the renewal date approaches. Do issue a new certificate as soon as you get your first reminder. The procedure is pretty much the same: Create a new certificate signing request, get a new HTTPS certificate, and install it on your server. The certificate’s validity will start running at the time of signing, while the expiration will be set one year after your current certificate expires. Thus, there will be a time when both your old and new certificates will be valid, and then a full new year after the expiration of the old certificate. During the overlap, you will be able to make sure that the new certificate is working OK, before the old one expires, allowing for uninterrupted service of your website.

Revocation Link

If your server is compromised or if you think someone might have access to your private key, you should immediately revoke your current HTTPS certificate. Different registrars have different procedures, but it generally boils down to marking the compromised certificate as inactive in a special database of your registrar, and then issuing a new HTTPS certificate. Of course, revoke the current certificate as soon as possible, so that nobody can impersonate you, and get the new certificate only after you have investigated and fixed the cause of the security breach. Please ask your registrar for assistance.

Let’s Encrypt Link

To quote the Let’s Encrypt78 website:

Let’s Encrypt is a free, automated, and open certificate authority (CA), run for the public’s benefit. Let’s Encrypt is a service provided by the Internet Security Research Group (ISRG)79.

The key principles behind Let’s Encrypt are:

  • Free
    Anyone who owns a domain name can use Let’s Encrypt to obtain a trusted certificate at zero cost.
  • Automatic
    Software running on a web server can interact with Let’s Encrypt to painlessly obtain a certificate, securely configure it for use, and automatically take care of renewal.
  • Secure
    Let’s Encrypt will serve as a platform for advancing TLS security best practices, both on the CA side and by helping website operators properly secure their servers.
  • Transparent
    All certificates issued or revoked will be publicly recorded and available for anyone to inspect.
  • Open
    The automatic issuance and renewal protocol will be published as an open standard that others can adopt.
  • Cooperative
    Much like the underlying Internet protocols themselves, Let’s Encrypt is a joint effort to benefit the community, beyond the control of any one organization.

To take advantage of Let’s Encrypt, set up your hosting account or server properly. Let’s Encrypt offers short-term certificates that need to be renewed regularly in order to keep an HTTPS website operational.

How It Works Link

There are some substantial differences in the mode of operation between Let’s Encrypt and the other CAs. Following the first three points above, here are the main ones:

  • Free
    The Let’s Encrypt HTTPS certificates are completely free for the whole lifespan of your website.
  • Automatic
    The Let’s Encrypt HTTPS certificates are valid
    for 90 days
    80, unlike regular HTTPS certificates, which are valid for one year. People are encouraged to automate their certificate renewal; for example, the administrator of the server would set up a dedicated software service (or would periodically invoke software from cron) to manage the initial domain validation and subsequent renewal for all hosted domains — set-it-and-forget-it style.
  • Secure
    Let’s Encrypt HTTPS certificates are issued with no compromise on security, leading to certain incompatibilities with older and more exotic platforms. Check the compatibility page8481 to determine whether you are fine cutting off incompatible platforms.

Limitations Link

Let’s Encrypt provides only DV certificates. OV and EV are not supported, and there are currently no plans to support them. Single- and multiple-domain HTTPS certificates are offered, but no wildcard ones at the moment. See the Let’s Encrypt FAQ82 for more information.

Let’s Encrypt’s automated mode of operation enforces some usage limits83 in order to protect the infrastructure from intentional and unintentional abuse. The rate limits are high enough not to affect regular users with even hundreds of domains. However, if you manage HTTPS certificates at a very large scale, you might want to check them out.

Older and exotic clients (prior to Windows XP SP3) are not supported. Check the compatibility page8481 for details.

Using The Let’s Encrypt HTTPS Certificates In Practice Link

cPanel Link

  1. Log into your host’s cPanel
  2. Scroll down to the “Security” section, and click “Let’s Encrypt for cPanel.”
    cPanel Security section85

    cPanel “Security” section (View large version86)
  3. You are now in the “Let’s Encrypt for cPanel” section. Check both domain names ( and, and click “Issue Multiple.”
    Check both domain names and click Issue Multiple87

    Check both domain names and click “Issue Multiple.” (View large version88)
  4. You will be taken to a confirmation screen. Your top-level (i.e. non-www) domain name will be selected as the primary, and your www domain name as an alias, which will be placed in the HTTPS certificate’s “Subject Alt Name” (SAN) record. Click “Issue” to continue. Please be patient and do not refresh the page, because the initial validation might take longer — about a minute or two.
    Click Issue and be patient for about a minute or two89

    Click “Issue” and be patient for about a minute or two. (View large version90)
  5. If the process completes successfully, you will see a confirmation message. Click “Go back” to see the installed HTTPS certificate.
    If the process completes successfully, you will see a confirmation message91

    If the process completes successfully, you will see a confirmation message. (View large version92)
  6. You will see your domain listed under “Your domains with Let’s Encrypt certificates.” You may check the certificate’s details and verify that the website opens with the https:// prefix in your browser.
    Your domain with Let's Encrypt certificates93

    Your domains with Let’s Encrypt certificates (View large version94)

Linux, FreeBSD, Other Link

The easiest way to set up Let’s Encrypt on your server is with Certbot95. Just select your web server and operating system and follow the instructions.

Let's Encrypt certbot96

Let’s Encrypt Certbot (View large version97)

Internet Information Server on Windows Link

There is currently no official client for IIS on Windows, but there are workarounds.

There are several projects to create a native Windows client for Let’s Encrypt:

Cloudflare Link

Cloudflare101 is a service that provides a content delivery network (CDN), website security, and protection against distributed denial of service (DDoS) attacks. It features a free HTTPS certificate with all subscription plans, including the free one — a shared DV Cloudflare Universal SSL certificate. In order to have a unique HTTPS certificate, you need to upgrade to the Business plan.

To take advantage, simply create an account, set up your website, and visit the “Crypto” section.

CertSimple Link

CertSimple102 is an EV-only HTTPS certificate vendor. It is disrupting the EV HTTPS certificate market in a way similar to what Let’s Encrypt is doing in the DV HTTPS certificate market, by providing a faster, easier process of organization validation — an otherwise slow and cumbersome routine. Here are its advantages:

  • Simplified application procedure
    No software to install or command line questions. Live validation, with most details checked before payment.
  • Fast validation time
    Three hours on average versus the industry standard 7 to 10 days.
  • Free reissues for the lifetime of the certificate
    Easily add domain names later or fix a lost private key.

You can read an excellent, in-depth review of the process on Troy Hunt’s blog103.

Multiple HTTPS Websites On A Single IP Address Link

Due to the nature of the handshake process, virtual hosts with a single IP address are a problem for TLS. Virtual hosts work by having the client include the domain name as part of the HTTP request header, but when HTTPS is used, the TLS handshake happens before the HTTP headers are sent — the secure channel should be initialized and fully functional before transmitting any plain-text HTTP, including headers. So, the server does not know which HTTPS certificate to present up front to a connecting client, so it presents the first one it finds in its configuration file, which, of course, only works correctly for the first TLS-enabled website.

There are several workarounds: to have a unique IP for each TLS-enabled domain, or to have all domains in a single certificate. Both are impractical — the IPv4 address space is now used up, and having one big HTTPS certificate means that if you want to add a single website to this server, you’ll need to reissue the whole multiple-domain certificate.

An extension to the TLS protocol, named Server Name Indication (SNI)104, was introduced to overcome this limitation. Both servers and clients should support it, and although SNI support is nowadays widely available, it is still not 100% bulletproof, if compatibility with all possible clients is a requirement.

You can read more about running SNI for Apache105, nginx106 and IIS (8+)107 in the respective documentation.

Useful Resources Link

Footnotes Link

  1. ^114 Chrome115 and Firefox116 explicitly mark websites that provide forms on pages without HTTPS as being non-secure.
  2. ^117 HTTPS has become an SEO ranking factor118,
  3. ^119 HTTPS has a serious privacy impact120.

(rb, vf, cm, al, il)

Footnotes Link

  1. 1 #footnote-1
  2. 2 #footnote-2
  3. 3 #footnote-3
  4. 4 #lets-encrypt
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11 #lets-encrypt
  12. 12 #cloudflare
  13. 13
  14. 14
  15. 15 #lets-encrypt
  16. 16 #cloudflare
  17. 17
  18. 18
  19. 19
  20. 20
  21. 21
  22. 22
  23. 23
  24. 24
  25. 25
  26. 26
  27. 27
  28. 28
  29. 29
  30. 30
  31. 31
  32. 32
  33. 33
  34. 34
  35. 35
  36. 36
  37. 37
  38. 38
  39. 39
  40. 40
  41. 41
  42. 42
  43. 43
  44. 44
  45. 45
  46. 46
  47. 47
  48. 48
  49. 49
  50. 50
  51. 51
  52. 52
  53. 53
  54. 54
  55. 55
  56. 56
  57. 57
  58. 58
  59. 59
  60. 60
  61. 61
  62. 62
  63. 63
  64. 64
  65. 65
  66. 66
  67. 67
  68. 68
  69. 69
  70. 70
  71. 71
  72. 72
  73. 73
  74. 74
  75. 75
  76. 76
  77. 77
  78. 78
  79. 79
  80. 80
  81. 81
  82. 82
  83. 83
  84. 84
  85. 85
  86. 86
  87. 87
  88. 88
  89. 89
  90. 90
  91. 91
  92. 92
  93. 93
  94. 94
  95. 95
  96. 96
  97. 97
  98. 98
  99. 99
  100. 100
  101. 101
  102. 102
  103. 103
  104. 104
  105. 105
  106. 106
  107. 107
  108. 108
  109. 109
  110. 110
  111. 111
  112. 112
  113. 113
  114. 114 #1-return
  115. 115
  116. 116
  117. 117 #2-return
  118. 118
  119. 119 #3-return
  120. 120

↑ Back to top Tweet itShare on Facebook

Vladislav Denishev is an independent expert, helping small and medium businesses excel by analyzing and improving their processes, technology and human capital in a systematic way. He works in the intersection of three domains: (1) Innovation and Digital Transformation, (2) Information Technology and (3) Educational Technologies. Find out more at Systematic Brains.

  1. 1

    Wow what an article! Thanks for the extensive explanation! Much appreciated!

    • 2

      Thanks, Marina. My hope is that the article will bring value and be of use to site owners – be it of sites small or large – to offer better security and privacy to their users.

  2. 3

    Michael van Laar

    June 12, 2017 2:11 pm

    Great and comprehensive guide! Thanks Vladislav. Just a short info on SNI and the possible problems that come with it—based on my latest experiences.

    The shared webspace hoster of my personal websites offeres Let’s Encrypt in combination with SNI. That’s great because that way, delivering even my small personal websites and blogs via https doesn’t cost me anything extra. Works perfect in all relevant more or less modern browsers, which is enough for me. All of my personal websites are delivered exclusively via https, using SNI.

    Search engine bots can cope with SNI and so do popular server-side components like cURL as well as the scrapers of social media platforms. Except two exceptions, one of which may be relevant for a lot of websites:

    LinkedIn’s scraper (which is buggy in more than one way anyway), which is to create the nice link preview boxes in postings, obviously still can’t handle SNI. That’s why you get an error message instead of a nice link preview box.
    Google Newsstand Publisher can’t read RSS feeds which are delivered via https using SNI.

    These are the only two major problems I came across since I started delivering my personal web pages exclusively via https using SNI. The Google Newsstand Publisher bug is not a big deal for me. But LinkedIn’s incapability of coping with SNI is not so nice. I asked the LinkedIn support team if this is on their list. But they replied that there are no plans to change that. Which is awkward because it shouldn’t be a big deal to use an SNI compatible component to fetch web content for their link preview boxes.

    • 4

      Hi Michael, it is really strange (and sad) to hear about your problems with LinkedIn and SNI. It is now a well established technology and should not be a problem, except for old and unsupported clients. Are you sure it is SNI that causes the problem? I use Cloudflare certificates with SNI and I can confirm it works fine with LinkedIn posting (see Systematic Brains on LinkedIn).

      To check your HTTPS server for potential problems, I strongly suggest you visit the Qualys SSL Server Test page and look for possible misconfiguration and recommendations.

      If that does not work, you may try to switch to Cloudflare – it is free and easy, and you get a CDN as an added value.

  3. 5


    June 12, 2017 3:21 pm

    The sheer density of this post is exactly why so many of us with our own sites haven’t moved to HTTPS, it is hardly a simple affair. Until it becomes a one-clicker in cPanel, this is not getting done by the many and will still only be accessible to the few.

    I recommend listening to Cory Doctorow’s interview on the Changelog podcast on the subject, one way or another the system is problematic.

    • 6

      Šime Vidas

      June 12, 2017 4:12 pm

      Hm, but it is a “one-clicker.” ;-) I’ve enabled it a while ago on CloudFlare by toggling a switch (IIRC). Even if you don’t use a CDN, your hosting provider should have a way to add a Let’s Encrypt certificate via a setting or something like that.

    • 7

      Hi @theavangelist, I agree that the matter is complicated and overwhelming. Even though it is not a one-clicker in cPanel, you will find it surprisingly easy to set up a HTTPS version of your site through a wizard, and it should be safe as well – your HTTP site should continue operating as usual, even if you mess up the HTTPS setup. So I urge you to try it – in the newer versions of cPanel you usually have two options – the traditional process with buying a certificate from a CA or the free Let’s Encrypt version, which is even easier. Please consult the article and your hosting provider’s documentation.

      Once you have set everything up and confirmed it working, you then redirect all traffic to the HTTPS version.

      As for the article, it is aiming to help as many users in as many (most common) scenarios as possible. It has a theoretical background for the process-oriented readers, as well as practical step-by-step guides for the results-oriented. Hence the density.

    • 8

      It is a one-clicker in cPanel and Plesk. We have been one-clicking all our client sites to SSL for almost a year. Look again. It’s all there.

  4. 9

    Thanks for sharing this awesome article. I have to do an assignment on this topic and I found your post very helpful.

  5. 12

    Well, I’m going to call the naked emperor out. Why on earth are we buying into Google’s decision to penalize every blog for not using https? Therr is zero security issue. I am not going to cough up mega bucks to GoDaddy for a certificate for a blog I occasionally post to. Or pay a tech person to implement any of this stuff. Again, THERE IS NO REASON TO FORCE HTTPS on every single personal blog or website.

  6. 14

    Amazing article, thanks for sharing.

  7. 16

    Hi, is it possible to make localhost https ? if yes, how?

  8. 18

    awesome. great article. covered all most all the topics. Thanks a lot.

  9. 20

    Hi Eniel, Let’s Encrypt is a fully viable option, and you can (and should!) automate certificate renewal in order to eliminate your support engagement.

  10. 21

    Brett Santore

    June 15, 2017 8:02 pm

    A better standard for:
    <script src=""></script>

    Don’t specify the protocol:
    <script src="//"></script>

    This will default to the currently used protocol.

    [Formatted by Vladislav Denishev]

  11. 23

    Nice Article.. covered almost everything about HTTP , HTTPS , HTTP/2 , SSL , TLS

    Thanks For Sharing …. :)

  12. 25

    Hi! Cool article! Thanks!
    You do not plan to translate this article into Russian? If you do not plan, then maybe I will do it in my blog (

  13. 27

    Well written and informative, thank you for sharing

  14. 29

    Magarida Fernandes

    June 26, 2017 12:30 pm

    This is a great and useful tutorial.
    Thank you for the help. I have been trying to figure this out around the web without success.

  15. 31

    What a great article!
    Any tips on renewing the certificates?
    Because I like to put the new certificates already in place before the old one expires.

    • 32

      Hi Willem, you are perfectly fine getting a new certificate before the old one expires. It is a common misconception and practice to wait for the last possible moment to renew a certificate – the rationale being, since it is a time-limited service, use the old one as long as you can, before you pay for the new one.

      In reality, the CA signing the new certificate will make it valid starting immediately and last a year after your current certificate expires, e.g. if you renew the certificate one month before it expires, the new one will be valid for the overlapping month, plus a full year afterwards.

      This way you have a certain time frame to issue the certificate and try it, before you are forced to change it by the old one expiring.

      Additionally, if you use Let’s Encrypt you are encouraged to setup automated renewal, set it once and let it do its job.

  16. 33

    This was a very well written and informative article. I am looking forward to the rest of this series.


Leave a Comment

You may use simple HTML to add links or lists to your comment. Also, use <pre><code class="language-*">...</code></pre> to mark up code snippets. We support -js, -markup and -css for comments.

↑ Back to top