A 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; it is an SEO ranking factor; and it has a serious impact on privacy in general. Additionally, there is now more than one option to get an HTTPS certificate for free, so switching to HTTPS is only a matter of will.


HTTPS is a must for every website nowadays: Users are looking for the padlock when providing their details; Chrome and Firefoxexplicitly mark websites that provide forms on pages without HTTPS as being non-secure; it is an SEO ranking factor; and it has a serious impact on privacy in general. Additionally, there is now more than one option to get an HTTPS certificate for free, 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 example.com is actually example.com. Some certificates even check the legal identity behind that website, so that you know yourbank.com 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 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 encryption
Symmetric encryption (View large version)

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 encryption
Asymmetric encryption (View large version)

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.


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.


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 example.com (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 trust
Chain of trust (View large version)

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. 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 Encrypt and Cloudflare 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 connect.data.com, 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.


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 example.com and http://www.example.com.
  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 (*.example.com) — for example, example.com, http://www.example.com, mail.example.com, ftp.example.com, 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:

Verified legal owner
Single domain example.com, http://www.example.com
Multiple domains example.com, http://www.example.com, mail.example.com, example.net, example.org, etc.
predefined list, up to a certain limit (usually 100)
Wildcard *.example.com
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 combinations is available.)

So, there are some configuration choices to be made.


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.

Wikipedia has a comprehensive list of algorithms for all components of TLS and their support in different versions of SSL and TLS.

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


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:

  • example.com.key
    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.
  • example.com.pub
    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.
  • example.com.csr
    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.
  • example.com.crt
    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 example.com.

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 Encrypt and Cloudflare.

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.


  1. Log into your host’s cPanel.
  2. Scroll down to the “Security” section and click “SSL/TLS.”
    cPanel Security section
    cPanel “Security” section (View large version)
  3. You are now in the “SSL/TLS Manager” home. Click “Private Keys (KEY)” to create a new private key.
    cPanel SSL/TLS Manager
    cPanel “SSL/TLS Manager (View large version)
  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 management
    cPanel “Private Key” management (View large version)
  5. The new private key will be generated, and you will get a confirmation screen:
    cPanel Private key confirmation
    cPanel private key confirmation (View large version)
  6. If you go back to the “Private Keys” home, you will see your new key listed:
    cPanel Private keys with the new key generated
    cPanel “Private Keys” with the new key generated (View large version)
  7. Go back to the “SSL/TLS Manager” home. Click “Certificate Signing Requests (CSR)” to create a new certificate request.
    cPanel SSL/TLS Manager
    cPanel “SSL/TLS Manager” (View large version)
  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 (example.com); the CA will usually add the wwwsubdomain as well (i.e. http://www.example.com). When finished, click the “Generate” button.
    cPanel create new Certificate Signing Request form
    cPanel “Create New Certificate Signing Request” form (View large version)
  9. The new CSR will be generated, and you will get a confirmation screen:
    cPanel CSR confirmation
    cPanel CSR confirmation (View large version)
  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 generated
    cPanel “Certificate Signing Request” with the new CSR generated (View large version)


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 example.com.key -out example.com.csr

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 'example.com.key'
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 (example.com), the CA will usually add the www subdomain as well (i.e. http://www.example.com):

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) []:example.com
Email Address []:admin@example.com

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


  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 Certificates
    Open “Internet Information Services (IIS) Manager.” Double-click “Server Certificates.” (View large version)
  2. Click “Create Certificate Request” in the right column.
    Click Create Certificate Request in the right column
    Click “Create Certificate Request” in the right column. (View large version)
  3. Enter your organization’s details, paying special attention to “Common
    Name,” which should match your domain name. Click “Next.”

    Enter your organization's details
    Enter your organization’s details. (View large version)
  4. Leave the default “Cryptographic Service Provider.” Set the “Bit length” to 2048. Click “Next.”
    Set the Bit length to 2048
    Set the “Bit length” to 2048. (View large version)
  5. Browse for a place to save the generated CSR and click “Finish.”
    Browse for a place to save the generated CSR and click Finish
    Browse for a place to save the generated CSR and click ‘Finish’. (View large version)

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.


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 TXTrecord 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.


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 example.com, 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 example.com.key -in example.com.csr -req -days 365 -out example.com.crt

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


  1. Go back to the “SSL/TLS Manager” home. Click “Certificates (CRT)” to import the new certificate.
    cPanel SSL/TLS Manager
    cPanel “SSL/TLS Manager” (View large version)
  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 certificate
    cPanel “Import” a new HTTPS certificate (View large version)
  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 certificate
    cPanel “Review” and confirm HTTPS certificate (View large version)
  4. The new HTTPS certificate will be saved, and you will get a confirmation screen:
    cPanel SSL certificate confirmation
    cPanel HTTPS certificate confirmation (View large version)
  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 listed
    cPanel “Certificates” with the new HTTPS certificate listed (View large version)
  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 Manager
    cPanel “SSL/TLS Manager” (View large version)
  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 Website
    cPanel “Install an SSL Website” (View large version)

Test to see that you can access your website at the address https://www.example.com. 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 RewriteRulelines only, right after the existing RewriteEngine On directive.


Place the generated private key (example.com.key), Certificate Signing Request (example.com.csr) and the valid HTTPS certificate (example.com.crt) in the appropriate locations:

  • Debian, Ubuntu and clones, FreeBSD
    cp example.com.crt /etc/ssl/certs/
    cp example.com.key /etc/ssl/private/
    cp example.com.csr /etc/ssl/private/
  • Red Hat, CentOS and clones
    cp example.com.crt /etc/pki/tls/certs/
    cp example.com.key /etc/pki/tls/private/
    cp example.com.csr /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


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>
	ServerName example.com
	ServerAlias www.example.com
	Redirect 301 / https://www.example.com/

<VirtualHost *:443>
	ServerName example.com
	Redirect 301 / https://www.example.com/

<VirtualHost *:443>
	ServerName www.example.com
	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 Generator, 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).


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 Generator, 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!


  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 Certificates
    Open “Internet Information Services (IIS) Manager.” Double-click “Server Certificates.” (View large version)
  2. Click “Complete Certificate Request” in the right column.
    Click Complete Certificate Request in the right column
    Click “Complete Certificate Request” in the right column. (View large version)
  3. Select the signed certificate file (example.com.crt) 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 file
    Select the signed certificate file. (View large version)
  4. If the process went OK, you should see the certificate listed under “Server

    You should see the certificate listed under Server Certificates
    You should see the certificate listed under “Server Certificates.” (View large version)
  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 Bindings
    Select the website and click “Bindings.” (View large version)
  6. In the “Site bindings” window, click the “Add” button.
    Click the Add button
    Click the “Add” button. (View large version)
  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 certificate
    Select “HTTPS,” and select the installed HTTPS certificate. (View large version)
  8. You should now have both HTTP and HTTPS installed for this website.
    You should now have both HTTP and HTTPS installed for this website
    You should now have both HTTP and HTTPS installed for this website. (View large version)


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 https://code.jquery.com/jquery-3.1.0.min.js.

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


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 Test. 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.


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.


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 Encrypt 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).

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.


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
    , 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 page to determine whether you are fine cutting off incompatible platforms.


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 FAQ for more information.

Let’s Encrypt’s automated mode of operation enforces some usage limits 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 page for details.

Using The Let’s Encrypt HTTPS Certificates In Practice Link


  1. Log into your host’s cPanel
  2. Scroll down to the “Security” section, and click “Let’s Encrypt for cPanel.”
    cPanel Security section
    cPanel “Security” section (View large version)
  3. You are now in the “Let’s Encrypt for cPanel” section. Check both domain names (example.com and http://www.example.com), and click “Issue Multiple.”
    Check both domain names and click Issue Multiple
    Check both domain names and click “Issue Multiple.” (View large version)
  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 two
    Click “Issue” and be patient for about a minute or two. (View large version)
  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 message
    If the process completes successfully, you will see a confirmation message. (View large version)
  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 certificates
    Your domains with Let’s Encrypt certificates (View large version)


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

Let's Encrypt certbot
Let’s Encrypt Certbot (View large version)


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:

  • ACMESharp (PowerShell) is the first effort to write a Windows client.
  • letsencrypt-win-simple (for the command line) seems the easiest to use.
  • Certify provides a GUI on top of ACMESharp, but is still in alpha.

Cloudflare Link

Cloudflare 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

CertSimple 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 blog.

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), 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 Apache, nginx and IIS (8+) in the respective documentation.

Useful Resources Link

Fonte: A Complete Guide To Switching From HTTP To HTTPS – Smashing Magazine

Stop paying for SSL Certificates

One of my most proud accomplishments of late is finally, after 7 years of web development, having one of my personal sites be secured with a valid SSL certificate. Now, this may not sound like such a big thing to some more seasoned developers, but to me, it’s kind of a big deal. My wife had to witness me have a nerdgasm afterward, as I tried to explain to her the significance of having an SSL certificate. Mainly it came down to having that satisfying little green lock with the word “Secure” next to it.

Now, anyone who has tried to get an SSL certificate in the past knows that they are a pain in the but to get. There are hundreds of providers and they can be expensive. Unfortunately, for those exact reasons SSL certificates aren’t usually seen as a priority for smaller sites such as personal blogs like this. Thankfully The Linux Foundation, as well as a myriad of other supporters, have come to the rescue in the form of Let’s Encrypt.

According to Let’s Encrypt’s website:

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

What does this mean for us as developers? It simply means that securing your website isn’t just for the big boys anymore. Any developer with a little bit of terminal knowledge can generate and install their very own certificate and get that comforting little “Secure” emblem next to their website’s URL.

So, how do I get started?

Getting started with Let’s Encrypt is super fairly easy. First of all, you should know that my primary development machine right now is running Ubuntu. Yours might be different and that’s okay. The Certbot client works with almost all Unix-based operating systems. Those with Non-Unix systems, such as Windows running Microsoft IIS, aren’t completely out of luck, but my instructions here won’t help. You might try using something like ACMESharpinstead.

For Debian-based Linux distributions such as Ubuntu, the process is fairly straightforward. First, you’ll need to open a terminal window. For those that aren’t familiar with the terminal this can be daunting, but fear not! The terminal isn’t as scary as it first appears.

Paste the following commands into the terminal, making sure to respond yes to any prompts.

sudo apt-get install software-properties-common  
sudo add-apt-repository ppa:certbot/certbot  
sudo apt-get update

After the update has finished, enter the following command. For this example I’m using nginx, if you’re using apache you should install python-certbot-apache instead.

sudo apt-get install python-certbot-nginx

Once the plugin is installed, run the following to generate a cert and automatically add it to your nginx configuration file.

certbot --nginx

It’s also possible to get a little more control when installing your certs. For instance, with this blog I used the --webroot flag to have a validation file placed into this site’s root in order for Let’s Encrypt to verify that this site is mine. The full command I used was:

certbot --webroot -w /var/www/my-blog -d blog.cwatsondev.com -d www.blog.cwatsondev.com

This installed both certs and then verified that my sites were where I said they were.

Finally, these certificates expire after 90 days, so you will need to renew them often. The easiest way to do that is to run the certbot renew --dry-run command. This creates a cron job that will auto-renew the certificate for you.

Congratulations! You now have an SSL certificate installed! All of the instructions above are also listed on the Certbot Website for a myriad of different distros.

This article is also available on my personal blog at https://blog.cwatsondev.com. Please check it out!

Edit: For people that are wondering about the “super fairly easy”, check out my blog. The original version has a strike through and that didn’t translate here.

Como proteger-se do ransomware

O ataque WannaCry, que sequestrou dados de milhares de computadores em todo o mundo, veio dar razão aos alertas dos especialistas em segurança que têm vindo a alertar constantemente para o crescimento e perigos deste tipo de ataque. Felizmente, como acontece com a esmagadora maioria do malware, há formas de evitar esta e outras “infeções”

De um momento para o outro, o termo “ransomware” passou a fazer parte do léxico dos portugueses. Uma consequência do ataque global WannaCry, que trouxe este tema para a comunicação social generalista o que levou muitas pessoas a ficar assustadas e a tentar perceber melhor o que se estava a passar. Como é habitual nestas coisas, nem sempre o tema tem sido abordado corretamente nos media mais populares, onde têm surgido muitos textos com confusões e até erros. Termos como hacking, vírus ou phishing têm sido empregues muitas vezes de forma errada ou exagerada.

Quem segue os meios de especialidade está, naturalmente, mais dentro do assunto e até tem sido, nesta última semana, um “porto seguro” para familiares e amigos. Para quem está mais dentro do assunto, sabe que o ransomware está longe de ser uma novidade; que tem sido um dos tipos de ataque em maior crescimento; e que, apesar da segurança total ser um conceito utópico, há formas de minorar muito a nossa exposição aos riscos.

As três regras do costume

Há regras que já deviam ser evidentes para todos os utilizadores de dispositivos ligados à Internet, desde os PCs de secretária mais poderosos até ao mais humilde smartphone. Infelizmente, ter conhecimento das boas práticas não significa, necessariamente, pô-las em prática. Provavelmente quem anda de bicicleta sem capacete ou leva crianças “soltas” nos bancos de trás do carro sabe bem que essas não são as opções mais seguras…

Como tal, como fazem as autoridades rodoviárias, o melhor é começar por repetir os conselhos para dar à conhecer a quem não sabe e relembrar quem já sabe, mas opta por ignorar.

1- Cuidado com os emails

Um estudo da IBM Security indica que 40% do spam que chegou às caixas de correio eletrónico em 2016 continha código para ataques de ransomware. Este tem sido o sistema de entrega de código malicioso preferido pelos atacantes, o que tudo indica ter acontecido WannaCry, pelo menos numa fase inicial.

O software de ataque pode estar incluído no próprio mail, mas é mais habitual que a mensagem contenha um link para descarregar ou executar o código a partir de um servidor. É comum recorrer-se a máscaras para esconder as verdadeiras intenções, o que significa que muitas vezes as coisas não são o que parecem. Por exemplo, o texto do link até pode indicar alguma coisa inocente como «link para as fotos».

O que nos traz à regra mais importante: nunca clique em links de e-mail de remetentes desconhecidos. Aliás, o melhor é mesmo apagar estes mails imediatamente (sem os abrir). Mas, mesmo que o emissor seja conhecido, a regra de não clicar cegamente em links continua a ser válida porque o mail pode resultar de um sistema comprometido (infetado) ou ser originário de um outro emissor que não o anunciado no campo «de:».

Não basta utilizar um sistema operativo o mais recente possível. É também importante mantê-lo atualizado, processo automático na maioria dos sistemas. Deve ter as atualizações de segurança ativadas tanto no smartphone Android como o seu computador pessoal.

Claro que, por razões pessoais ou profissionais, temos de muita vezes seguir links, mas, neste caso, recomendamos que verifique qual o endereço que vai usar e não acredite apenas no texto de referência. Se o destino (endereço) for um servidor desconhecido ou se levantar a mínima dúvida, não use o link e muito menos aceite a instalação de algum software diretamente. Não se esqueça que, em caso de dúvida, pode sempre contactar o remetente para verificar o conteúdo.

Este cuidado também é válido para evitar outro esquema muito popular, o phishing, em que os criminosos tentam obter dados privados, como nomes de utilizadores e palavras-chave através de “armadilhas”. Os atacantes enviam muitas vezes mails simulando que foram enviados por serviços como banca e comunicações. Alguns têm pedidos diretos de dados, mas a maioria inclui links para páginas Web falsas, que imitam serviços reais, para levar os utilizadores a revelaram dados pessoais.

2- Mantenha o sistema atualizado

Quem realizou o ataque WannaCry partiu do princípio que uma parte importante dos sistemas estaria exposto a uma brecha de segurança que foi corrigida pela Microsoft, através de atualizações automáticas e gratuitas, a 14 de abril. Uma atualização apresentada como crítica, o que significa que deveria ter sido aplicada imediatamente.

Considerando as empresas que foram afetadas, que têm estrutura de gestão de sistemas própria, é fácil concluir que a segurança ainda não é uma prioridade para alguns profissionais. Ou para as empresas, que muitas vezes não valorizam o investimento que pode estar associado às atualizações – as correções até podem ser gratuitas mas, em muitos casos, exigem intervenções e testes de certificação que podem levar tempo e até exigir períodos de inatividade.

No caso concreto do WannaCry, a brecha de segurança continuava a existir no Windows XP, um sistema operativo ainda muito comum no parque informático nacional. Isto apesar de este sistema operativo (SO) já chegou ao fim da vida útil – foi lançado em 2001 e em 2014 a Microsoft anunciou o fim do suporte para este SO, o que significa que já não é objeto de atualizações. Ciente da dimensão do problema WannaCry, a Microsoft acabou por, excecionalmente, lançar uma atualização para o XP depois do ataque ter sido noticiado, mas este ataque só foi mais um de muitos casos que demonstram como quão perigoso é utilizar sistemas operativos antigos. Aliás, de acordo com o relatório Microsoft Security Intelligence publicado no final de 2016, a percentagem de computadores em estado “desprotegido” é muito maior em máquinas com SOs antigos: mais de 20% com o Windows 7, ainda um grande sucesso em Portugal, comparam-se com cerca de 3% em sistemas com Windows 10. Há vários aspetos técnicos que o Windows 10 tem que torna este sistema inerentemente mais seguro que as versões anteriores, independentemente do software de segurança que possa estar instalado.

Mas não basta utilizar um SO o mais recente possível. É também importante mantê-lo atualizado, processo automático na maioria dos sistemas. Deve ter as atualizações de segurança ativadas tanto no smartphone Android como o seu computador pessoal. Não vá em conversas e ative as atualizações automáticas do Windows (Windows Update).

3- Backups obrigatórios

As cópias de segurança são uma discussão tão antiga quanto a informática. Mesmo quando tudo corre mal e as barreiras de segurança são ultrapassadas, os problemas são muito minorados quando há backups para recuperar a informação perdida. As políticas de backup ainda são vistas, erradamente, como uma solução para problemas de hardware, mais especificamente, nas unidades de armazenamento. Como as falhas destes componentes têm sido menos comuns, os utilizadores fazem cópias de segurança com menos regularidade… quando as fazem.

Mas os backups são, cada vez mais, úteis para recuperar depois de perdas causadas por malware (nome geral dado a aplicações maliciosas). Os ataques de ransomware são um bom exemplo disso mesmo. Quem viu os seus dados encriptados e alvo de resgate ficou muito ou pouco preocupado em função de não ter ou ter backups atualizados. Na verdade, para quem tem backups atualizados, um ataque de ransomware bem-sucedido pode não passar de um problema menor e fácil de ultrapassar sem custo além do tempo necessário para repor os dados através das cópias de segurança.

Mas, para que o backup seja realmente útil nestas situações, é necessário garantir que as unidades de armazenamento não podem ser afetadas pelo infeção ou ataque. O que significa que os dados das cópias de segurança não podem estar ao alcance dos sistemas que são os potenciais alvos dos criminosos. Por exemplo, um um disco rígido externo dedicado a backups pode ser corrompido se estiver ligado à máquina atacada. O mesmo é válido para sistemas em rede, o que significa que, os utilizadores e, sobretudo, as empresas, devem recorrer a diferentes níveis de backup, incluindo cópias para unidades que estão offline quando não são usadas. Num sistema doméstico ou numa pequena empresa, os aparelhos tipo NAS costumam ser uma solução eficiente porque são funcionam com sistemas operativos proprietários (muito menos expostos ao malware) como também podem ter unidades de rede não mapeadas e, como tal, não acessíveis à esmagadora maioria do malware. Outra solução tão ou mais eficiente é o cloud. Para uma utilização pessoal, as ofertas gratuitas podem ser suficientes, especialmente se se recorrer a serviços como o Google Fotos para armazenar fotos e vídeos que são, normalmente, os ficheiros de maior dimensão.

Ou seja, se usar o Google Fotos para armazenar todas as fotos e todos os vídeos que quiser (há alguma compressão de ficheiros, mas a qualidade é muito satisfatória), o espaço oferecido, por exemplo, pelo Google Drive ou o OneDrive podem ser suficientes para os seus documentos. E estas soluções têm ainda a vantagem de incluírem sincronização automática das pastas selecionadas, o que significa que pode ter backups em tempo real e totalmente automatizados.

Software de Segurança

Um utilizador com sistema operativo recente, atualizado e que não corra riscos desnecessários até pode dispensar software de segurança. Isto porque o próprio Windows 10 oferece proteção contra malware. No entanto, para a maioria dos utilizadores é importante instalar um “pacote” de segurança abrangente, que ofereça proteção para todos os tipos de ataque e que seja capaz de compensar os descuidos do utilizar. E, muito importante, deve ser uma versão nova porque os “Internet Security” mais populares não incluíam proteção contra ransomware até recentemente.

Quer use uma aplicação de segurança deste tipo, quer se fique pelas ferramentas da Microsoft, recomendamos que utilize o Malwarebytes, disponível para download em https://pt.malwarebytes.com. A versão gratuita inclui uma poderosa ferramenta de deteção e remoção de malware. Ganhe o hábito de correr o Malwarebytes com alguma regularidade (a versão gratuita não funciona de modo residente na memória). Uma vez por semana costuma ser suficiente.

Se não tem uma aplicação de segurança com ferramentas contra ransomware, recomendamos que instale um programa dedicado para detetar e evitar este tipo de ataques. Há uma opção gratuita que sobressai, o Cybereason Ransomfree (https://ransomfree.cybereason.com/).

Desencriptar ficheiros sequestrados pelo WannaCry sem pagar por isso

Se, para si, as técnicas de proteção já vêm tarde porque o seu sistema foi afetado pelo WannaCry, temos uma boa notícia: já é possível desencriptar os dados aprisionados sem pagar o resgate pedido. Pelo menos em alguns casos.

Tudo graças uma ferramenta gratuita criada por Adrien Guinet, um especialista de segurança da Quarkslab. De acordo com TheHackerNews, Guinet descobriu que a chave necessária para desencriptar os dados continua residente na memória RAM do sistema. Deste modo, é possível obter a chave e remover a encriptação. Mas a ferramenta só funciona se o computador não tiver sido reiniciado após a infeção (o processo de reiniciar elimina os dados da memória RAM) e se nenhum outro programa tiver ocupado o mesmo espaço na memória, o que é tanto mais provável quanto maior for o tempo entre a encriptação dos dados e a tentativa de desencriptar.

A ferramenta chama-se WannaKey e pode ser descarregada a partir do GitHub em https://github.com/aguinet/wannakey. No texto de informação disponível é ainda indicado que a ferramenta funciona apenas em sistemas com Windows XP.

Como o código de Adrien Guinet exige alguns conhecimentos mais avançados para ser utilizado, um outro investigador na área da segurança, Benjamin Delpy, criou uma ferramenta mais fácil de usar baseada no código de Guinet: o WanaKiwi que, supostamente, funciona mais versões do Windows. O WanaKiwi também está disponível no GitHub em https://github.com/gentilkiwi/wanakiwi/releases.

Regras para usar serviços digitais

O que deve fazer:

• Ativar sistemas de dupla autenticação para que a palavra-chave não seja o único método necessário para acesso (muitos serviços recorrem ao envio de senhas por SMS);

• Eliminar contas que já não usa, sobretudo aquelas que não permitem dupla autenticação;

• Alterar com regularidade a palavra-chave nos serviços mais sensíveis (banco, por exemplo);

• Usar palavras-chave longas (8 caracteres no mínimo) que misturem letras, algarismos e símbolos;

• Criar uma segunda, terceira ou mesmo quarta conta de e-mail para associar a serviços menos relevantes (para receber e-mails informativos, por exemplo) e não usar essa(s) conta(s) para enviar/receber mails importantes;

• Aceder aos serviços online através de dispositivos seguros: nos computadores, deve ter um bom software de segurança instalado (as aplicações normalmente incluem denominação de Internet Security).

O que NÃO deve fazer:

• Usar a mesma password em serviços diferentes;

• Usar variações de password (sim, os hackers conhecem todos os truques, como juntar letras ou números relacionados com o serviço ou site);

• Recorrer a palavras, nomes, momentos e datas importantes para si para criar as palavras-chave (as técnicas de mnemónica são conhecidas e aproveitadas pelos hackers);

• Aceder a serviços sensíveis (banco online, por exemplo) a partir de PCs partilhados ou desconhecidos;

• Guardar listas de dados de acesso no mail (passwords, nomes de utilizador) ou em outros serviços digitais;

• Responder a e-mails e outros tipos de contacto (redes sociais, por exemplo) de desconhecidos;

• Seguir instruções e links supostamente enviados por serviços (a regra é: se lhe estão a pedir dados por mail é porque, provavelmente, trata-se de um esquema fraudulento);

• Guardar informação sensível em contas de e-mail que foram usadas em registos de outros serviços;

• Aceder a serviços online com dados pessoais importantes através de redes Wi-Fi públicas.

Fonte: Exame Informática Semanal, 20 de Maio de 2017

A Anatomia da NSA

Com o FuzzBunch, a NSA compilou um conjunto de vulnerabilidades que permitem a intrusão, e a espionagem de computares na Internet. Duas das vulnerabilidades existentes no kit usado pelos espiões americanos foram exploradas para lançar o WannaCry. Passadas 300 mil infeções fomos ver como ver funciona a ferramenta que começou a ser disponibilizada na Internet por um misterioso grupo de hackers, depois de uma não menos misteriosa fuga de informação

Nada disto deveria ter acontecido. Paulo Rosado, consultor em cibersegurança, sabe-o e quem o está a entrevistar também. E não são os únicos. Todos os internautas de alguma forma têm a ideia de que não é suposto haver um programa que permite aceder aos dados pessoais existentes em todos os outros computadores do mundo. Sabem as 300 mil potenciais vítimas que foram afetadas pelo ransomware Wannacry ao longo da semana; sabem todos os que ainda não foram vítimas; e provavelmente também sabem os operacionais da própria Agência de Segurança Nacional dos EUA (NSA) que criaram um arsenal informático e algorítmico que lhes permite estar virtualmente em qualquer ponto do Globo. Foi assim que surgiu o kit FuzzBunch. Parece nome de app de telemóvel mas é uma coleção de vulnerabilidades e ferramentas que permite assumir o controlo de máquinas que funcionam com os sistemas operativos Windows, que são usados pela esmagadora maioria dos computadores do Planeta. No verão, a Fuzzbunch foi libertado por um misterioso grupo de hackers de nome Shadow Brokers. Hoje, qualquer pessoa pode descarregá-lo a partir de repositórios de programas que perambulam na Internet. Paulo Rosado descarregou o ficheiro. E dispôs-se a mostrá-lo – com uma condição: nenhuma das missões pode afetar outros computadores que não o dele. Tudo o resto é interdito. E desaconselhado.

Como é que se faz um ataque que envolve três computadores quando só se pode usar um? Resposta: Com uma técnica que dá pelo pouco charmoso nome de virtualização, mas que tem a virtude de criar três computadores que só existem como entidades digitais, e podem ter configurações, funcionalidades, e até sistemas operativos diferentes – mas usam apenas um único equipamento. No limite, a mesma técnica pode ser usada para determinar que o computador do Joaquim usa apenas um terço da capacidade de processamento, memória e arquivo de dados ou bateria, que serão atribuídos em capacidades iguais ao Francisco e à Luísa enquanto vão alternando o uso do mesmo computador.

Agora imagine-se o seguinte: o Francisco tem um Fuzzbunch e pretende atacar o Joaquim em conluio com a Luísa, que encomendou o ataque. É essa operação que Paulo Rosado começa a demonstrar quando inicia o uso do kit de ciberarmas da NSA. «A primeira vez que fiz download do FuzzBunch o antivírus do meu computador classificou-o como código malicioso. Tive de preparar um computador virtual de forma a que se conseguisse instalar o kit de ferramentas», explica Paulo Rosado.

Ferramentas Depois de instalar backdoors, o computador do atacante fica à espera de receber os primeiros contactos dos computadores da vítimas

Todo o charme de FuzzBunch se esgota no próprio nome. A caixa de ferramentas da NSA não é mais que um ecrã preto com múltiplos carateres brancos. Todas as ações exigem a inserção de dados relativos endereço IP, “portos” de comunicações ou payloads (as “cargas” transportadas aquando da intrusão, que executam ações determinadas pelos hackers). Todas as peripécias imortalizadas por James Bond não têm lugar aqui; teclar será, provavelmente, a única ação levada a cabo durante as diferentes missões de um ciberoperacional da NSA.

Notoriamente, o Fuzzbunch é um ambiente mais propício para quem sabe programar, mas Paulo Rosado recorda que na Internet já se encontram múltiplos tutoriais capazes ensinar até quem não é programador a usar este conjunto de ferramentas. Esse é o lado perverso e assustador da inexplicada fuga de informação que permitiu aos Shadow Brokers distribuírem, no verão de 2016, o FuzzBunch – e que viria a ser secundada por uma outra conhecida por Vault 7, com a distribuição de ciberarmas da CIA pelo grupo hacktivista Wikileaks, em março.

Também foi em março que a Microsoft lançou um update que tinha por objetivo sanar vulnerabilidades conhecidas por EternalBlue e DeepPulsar. Com essa atualização dos sistemas operativos Windows são eliminados pontos de intrusão em versões antigas de um protocolo conhecido por SMB, que tem por objetivo a troca de mensagens – e como tal também pode ser usado para enviar ordens, fazer intrusões, apagar dados, desencadear aplicações, bloquear computadores com ransomware para poder exigir resgates, aceder à rede interna de uma organização e mais um sem número de patifarias que um hacker consiga imaginar.

A lista é exaustiva e pouco honrosa para quem a quiser divulgá-la ao detalhe – mas a verdade é incontornável: Por muito imbricadas que sejam as patifarias de um hacker, é bem provável que se encontrem no cardápio do Fuzzbunch. E todas elas revelam uma certa veia destes geeks espiões para a criação de marcas que ficam no ouvido. Mas centremo-nos apenas em duas dessas ferramentas/vulnerabilidades – precisamente aquelas que se tornaram o pior tormento das equipas de informática de milhões de empresas que se esqueceram ou adiaram a atualização dos sistemas operativos e que, in extremis , optaram pelo corte de acessos à Internet, e-mails, para evitar o sequestro das máquinas.

O Azul Eterno

Já não restam muitas dúvidas: houve contágio por e-mails, mas foi a exploração da vulnerabilidade conhecida por EternalBlue o principal método de propagação do WannaCry. O EternalBlue uma ferramenta que tira partido de um protocolo de comunicação já datado e que permite que um computador envie automaticamente um pacote de dados a outro sem que nenhum dos legítimos donos perceba. Com este envio de dados, um computador infeta o outro – e a uma velocidade mais rápida que o e-mail. Mas isso não chega para, no nosso cenário hipotético, a Luísa assumir o controlo do computador do Joaquim. É apenas o primeiro passo – que tem de ser executado por Francisco, se quiser cumprir a missão solicitada por Luísa (lembrete: o exercício aqui descrito tem por ponto de partida um ataque solicitado pela Luísa ao Francisco contra o Joaquim).

Com o DoublePulsar, a máquina infetada contacta com a máquina do hacker. Mas antes deixa um backdoor que permite o regresso dos hackers ao computador da vítima.

Ao estabelecer a comunicação com a máquina de Joaquim, Francisco não só encontra um potencial ponto de intrusão como passa a recorrer a uma segunda vulnerabilidade, que dá pelo nome de DoublePulsar. Através dessa vulnerabilidade, é executado o payload (a tal “carga”) da mensagem anterior, que por sua vez desencadeia uma ligação a um terceiro computador com as coordenadas pretendidas. Além disso, é criado um backdoor que permite ao hacker voltar mais tarde ao computador infetado. E é assim que o computador do Joaquim estabelece comunicação com o computador da Luísa, que é a mandante do ataque.

De seguida, a Luísa poderá usar ferramentas de ataque variadas para instalar pedaços de código que ora ficam em modo de escuta, ora fornecem dados em jeito de relatório sobre a máquina infetada ou permitem avançar com diferentes métodos de ataque. É nesse momento, que Luísa assume o denominado comando e controlo da máquina de Joaquim. No caso do WannaCry, é o momento em que é desencadeada a tecnologia de cifra que permite bloquear um computador e exigir um resgate em contagem decrescente no que toca ao tempo e em contagem crescente em relação valor a desembolsar.

No ecrã do computador de Luísa, o sucesso da missão é sinalizado com aquele que será o único recurso gráfico de toda esta ferramenta: múltiplos travessões alinhados, com a palavra «win» ao centro. A estética desta mensagem de sucesso tem similaridades inegáveis com uma certa moda das décadas de 1980 e 1990, que deu a conhecer laboriosos desenhos produzidos apenas e só com carateres de processadores de texto.

Todo o processo de ataque não terá demorado mais de 30 minutos, entremeados de entrevista, um ou outro apontamento sobre as ferramentas existentes, e um ou outro contratempo típico de quem, apesar de programador, não tem rotinas a usar a aplicação.

«O kit também contém ferramentas que apagam todos os vestígios a fim de evitar a deteção durante análises forenses que venham a ser feitas aos computadores infetados», acrescenta Paulo Rosado.

Atacar uma máquina pode não ser especialmente moroso, mas o cenário tende a ganhar complexidade quando se trata de atacar milhões de máquinas com um conjunto de ferramentas que, no limite, podem executar diferentes funcionalidades numa gigantesca orquestra do cibercrime, que pode atuar em diferentes cenários e missões.

Através da falha conhecida como EternalBlue, as caixa de ferramentas da NSA estabelece contacto com um computador de uma vítima. O sucesso da intrusão é sinalizado com um recurso gráfico e a palavra «win»

Mesmo que muitas das funcionalidades de gestão das máquinas infetadas possam ser automatizadas, é fácil concluir que o ciberbraço da NSA será sempre um consumidor intensivo de recursos humanos que têm de combinar paciência para tarefas rotineiras e uma tendência para ver as coisas ao contrário do estabelecido, com conhecimentos de programação, algoritmos, lógica matemática ou redes de telecomunicações. O que pode exigir uma equipa de especialistas – ou a divisão de tarefas, como sucede na indústria que o cibercrime montou ao longo dos anos.

«O kit também contém ferramentas que apagam todos os vestígios a fim de evitar a deteção durante análises forenses que venham a ser feitas aos computadores infetados»

Em qualquer dos casos, um dia de trabalho com o FuzzBunch não deverá ser assim tão diferente das rotinas típicas de quem passa oito horas a programar, a escrever notícias ou a trabalhar dados num software de gestão: Um humano frente ao computador que terá dias em que desespera por chegar à hora de saída como em qualquer outra profissão. Só a execução das missões em si permite imaginar algum momento mais emotivo ou comparável aos guiões de Hollywood.

Será que todos eles seguem a rotina sem nunca se questionarem? Edward Snowden, ex- operacional da NSA atualmente exilado na Rússia, mostrou com a primeira mega-revelação de métodos e ferramentas dos serviços secretos dos EUA, que até no arrependimento um ciberoperacional não será muito diferente de um empregado de escritório. É essa a maior das ambiguidades éticas das fugas de informação e das ferramentas dos serviços secretos: a mesma FuzzBunch que hoje está disponível na Internet para miúdos e graúdos, abrindo caminho para múltiplos sucessores mais sofisticados do WannaCry pode ser aproveitada para alertar autoridades e internautas em geral. «Este ataque revelou que algumas organizações ainda não estão suficientemente maduras para proteger os seus dados e os dados pessoais dos seus utilizadores e clientes, sendo que em maio começa a ser aplicado o novo Regulamento Geral de Proteção de Dados da UE».», refere Paulo Rosado, lembrando outra agravante decorrente do contágio levado a cabo pelo WannaCry: «Este ataque revelou que as organizações ainda não estão a proteger os dados pessoais como se desejaria, sendo que em maio começa a ser aplicado o novo Regulamento Geral de Proteção de Dados da UE».

A caça ao hacker pode estar apenas no começo.

Fonte: Exame Informática Semanal, 20 de Maio de 2017