SSL certificates: how they work, why they matter A short guide explaining how the TLS (Transport Layer Security) cryptographic protocol works and the importance it has to establish secure and verified connections

How to create a self-signed TLS SSL certificate for Apache or NGINX to accept HTTPS requests on port 443

This article is a spin-off from a guide that I wrote some time ago to explain how to create a self-signed SSL certificate and its configuration on Apache and / or Nginx web servers. I decided to extend the introductory part of that guide into a separate post for informational purposes, in the hope of spreading greater awareness on the importance of SSL / TLS certificates in the current IT landscape and on how their use is essential for any service provider or system administrator who wants to make connections to their services safer.

For anyone interested in the later parts as well, the full article is available here.


HTTPS is an acronym (and a crasis) of HyperText Transfer Protocol over Secure Socket Layer: it is a secure communication protocol that can be used by two systems (peer-to-peer or client-server) that have the aim of exchanging information between them . The conventionally used port is TCP 443. The main difference between HTTPS and its "cousin" HTTP (HyperText Transfer Protocol) is that the former, unlike the latter, allows the exchange of information through an encrypted connection using a cryptographic protocol asymmetric like Transport Layer Security (TLS) or its predecessor, Secure Sockets Layer (SSL).

The use of HTTPS instead of simple HTTP guarantees the connection a series of extremely important security features, including:

  • Protection of information and privacy of the communicating parties, in compliance with the criteria of confidentiality and confidentiality.
  • Guarantee of the integrity of the data exchanged between the communicating parties.
  • Verification and authentication of the sender, or of the website visited, or of both parties, in cases of duplex authentication (see below).

Until the early 2000s, the use of the HTTPS protocol was limited to e-commerce sites, inter-company connections and a series of corporate and enterprise services that dealt with particularly sensitive or confidential data: most websites did not. use, also and above all because of the hardware resources necessary to carry out the encrypt and decrypt activities required during the connection. From the mid-2000s and, above all, from 2010 onwards, the HTTPS protocol began to have a wide diffusion, also thanks to browsers and search engines, which have promoted and encouraged its use in various ways. Furthermore, a lot of SSL certificate resellers started to offer their services for affordable prices, which greatly helped in making the SSL adoption available for most websites.

The results of this wide-ranging adoption are extremely positive: the widespread use of HTTPS connections guarantees the authenticity of the web pages visited, increases the security of user accounts and protects data transiting the web from unauthorized access.

Transport Layer Security

TLS, acronym for Transport Layer Security and its predecessor SSL, or Secure Sockets Layer, are cryptographic protocols that guarantee a high level of security of communications through a computer network: their use includes all the main TCP connections used today through the internet and not only: web browsing, e-mail, faxing through the internet, instant messaging, VoIP protocols, and many others.

A TLS connection is characterized by the following main phases:

  • Negotiation: In this phase, the server and client determine which data-encryption protocol to use for secure communication, the protocol for key exchange and the authentication algorithm, as well as the Message Authentication Code (MAC).
  • Exchange of keys and authentication: in this phase the server and the client exchange information relating to the cryptographic keys respectively used, necessary to correctly decrypt the data transmitted and received. Both the key exchange algorithm and the authentication algorithm are usually public key algorithms or (as in the case of TLS-PSK) they use a Pre-Shared Key.
  • Symmetric encryption and message authentication: in this phase, the integrity of the messages is ensured by a hash algorithm that uses an HMAC construct for the TLS protocol or a non-standard pseudorandom function for the SSL protocol.

The main purpose of these protocols is twofold:

  • Protect in-transit data and guarantee their integrity through extremely complex and difficult to decrypt data-encryption algorithms, even following any unauthorized access (obtained through the use of attack techniques such as eavesdropping, tampering, man-in -the-middle, etc.).
  • Guarantee the real identity of the transmission source - for example, a website - through the certification of a body formally authorized to provide this service, that is a Certification Authority: this verification is carried out by analyzing the content of the certificate and checking the entire certification chain.

As you can easily see, the first aspect concerns the security and protection of data in the strict sense, while the second allows you to verify that the sender is who he claims to be.

Authentication types: one-sided, duplex, PSK and SRP

In most browser-server connections, TLS authentication occurs unilaterally, with the web server authenticating with the client but not vice versa: this means that the client is able to know and verify the identity of the server to which it connects even if remaining anonymous.

The TLS protocol also supports bilateral authentication, typically used in those scenarios where both connection peers (client and server, two web services that communicate with each other, or other similar situation) need to authenticate in a secure way by exchanging their certificates. . This authentication technique, known as Duplex Authentication, obviously requires that the client also has its own digital certificate and is normally used only in scenarios of corporate connections or with public bodies.

In the absence of bilateral authentication, the TLS-PSK (Pre-Shared Key) protocol, which we have already discussed, or the SRP (Secure Remote Password) protocol can be used: both allow secure authentication in absence of a client-side certificate.

Green Bar

To summarize what has been said so far, we can say that the TLS certificate allows you to guarantee both the encryption of the data and the verification of the transmitter. When both of these checks are successful, the browser indicates to the user that the connection is secure by showing a green lock icon or another similar visual message, depending on the browser and the characteristics of the certificate itself:

SSL certificates: how they work, why they matter

This type of visual evidence is called green lock and guarantees the user that their browser has successfully verified that the connection is protected by a "genuine" certificate, that is, issued to the company that owns the site.

IMPORTANT: It should be noted that these checks do not allow to determine that the site to which you are connecting is intrinsically safe: it is in fact quite possible that a site, although protected by a genuine certificate, may contain potentially dangerous material or convey fraudulent content. To explain the same concept with a metaphor, we could say that the checks on which the green lock is based concern the security of the lock and the correspondence between the address of the house and its actual owner, but they do not enter into the merits of what we can find over the front door.[/type]

About Ryan

IT Project Manager, Web Interface Architect and Lead Developer for many high-traffic web sites & services hosted in Italy and Europe. Since 2010 it's also a lead designer for many App and games for Android, iOS and Windows Phone mobile devices for a number of italian companies. Microsoft MVP for Development Technologies since 2018.

View all posts by Ryan

Leave a Reply

Your email address will not be published. Required fields are marked *

The reCAPTCHA verification period has expired. Please reload the page.

This site uses Akismet to reduce spam. Learn how your comment data is processed.