HTTPS

In this lesson you’ll learn what HTTPS is, why it matters, how TLS certificates work, and how to obtain and use them with a web server. The Nginx server block shown later demonstrates how to wire a certificate into a production-style configuration. Why HTTPS matters

Security: HTTPS (TLS) encrypts the entire communication channel between browser and website. On a shared network (e.g., public Wi‑Fi) an attacker cannot read intercepted traffic without access to the server’s private key. HTTPS protects usernames, passwords, payment data, and other sensitive information.
SEO and trust: Modern search engines and browsers favor HTTPS. A secure site can rank better in search results and displays browser UI (padlock) that increases user trust.

An illustrated slide titled "Importance of HTTPS" showing people in a coffee shop using laptops and Wi‑Fi, with a padlock icon and dotted lines depicting a secure (HTTPS) connection.

A presentation slide titled "Importance of HTTPS" showing an https:// lock icon labeled "SEO Benefits." Below it are icons and captions indicating HTTPS protects customer data and boosts visibility in search engines.

SSL vs TLS

SSL (Secure Sockets Layer) is deprecated. TLS (Transport Layer Security) is the modern, secure protocol that replaced SSL.
People still say “SSL certificate,” but the protocol in use is TLS. Use TLS 1.2 or TLS 1.3; TLS 1.0 and 1.1 (and all SSL versions) are insecure and should be disabled.

A simple diagram titled "SSL and TLS" showing a browser icon on the left and a web server stack on the right, connected under a shield with a checkmark. The caption says the protocols ensure privacy and integrity between browser and server.

High-level TLS handshake (simplified)

The browser opens an HTTPS connection to the server.
The server sends its TLS certificate (an X.509 document signed by a Certificate Authority). The certificate includes the server’s public key and identifying information (domain name).
The browser validates the certificate (chain-of-trust, expiration, and domain name). If valid, the browser and server complete an authenticated key exchange (commonly ECDHE), which results in ephemeral symmetric session keys.
All subsequent traffic is encrypted using the negotiated symmetric keys for performance and confidentiality.

A simple diagram showing an SSL/TLS step where a store’s web server sends its SSL/TLS certificate to a user’s browser/payment form. It features a user icon on the left, a payment form in the center, and server racks with a certificate icon on the right.

Certificate Authorities (CAs)

CAs validate identity and digitally sign certificates so browsers can trust them.
Examples include DigiCert, Sectigo, and other commercial CAs.
Let’s Encrypt is a widely used free, automated CA trusted by modern browsers and suitable for production.

A presentation slide titled "Certificate Authority" that shows a company/person icon issuing a digital certificate. The certificate graphic is labeled with contents like user's name, company information, and website address, and the slide notes the CA governs and manages digital certificates.

Certificates verify ownership

A TLS certificate is effectively a website’s online ID card. It proves the certificate requester controls the domain and prevents impersonation.

A slide titled "Certificates" showing a stylized browser window with the URL https://www.onlinestore.com and an SSL certificate icon. The caption notes that a certificate verifies the domain belongs to the store, not an impostor.

Public/private keys (asymmetric encryption)

TLS uses asymmetric cryptography for authentication and key exchange: a public key (shared) and a private key (kept secret on the server).
The public/private key pair authenticates the server and helps establish session keys; bulk encryption uses symmetric keys because symmetric algorithms are faster.

A diagram showing a web server sending a public key (depicted by an unlocked padlock) to a browser. The browser then uses that key to encrypt the data being sent.

A slide titled "Private Key" showing a lock icon in a speech-bubble and a separate key icon labeled "Kept secret by the server." It illustrates that the private key is stored confidentially on the server.

Practical flow for a payment form

After the TLS handshake, the browser encrypts sensitive form fields (e.g., credit card numbers) with the negotiated symmetric session keys.
The server uses its private key and the session keys established during the handshake to decrypt and process the request.

A diagram illustrating how public-key encryption works in practice. It shows a browser encrypting a credit card number, sending the encrypted data to a server that decrypts it with a private key and processes the payment.

Obtaining TLS certificates

Let’s Encrypt + Certbot: Let’s Encrypt issues free, trusted certificates. Certbot is a popular, well-documented client to obtain and renew certificates automatically.
Requirements: you must own (or control) the domain and have DNS pointing to the server where you run Certbot.

Example Certbot usage (adjust domains and plugin/flags for your environment):

sudo apt update
sudo apt install certbot
# Obtain a certificate using the standalone plugin for devops.org and www.devops.org
sudo certbot certonly --standalone --preferred-challenges http -d devops.org -d www.devops.org

Note: package names, installation commands, and recommended Certbot plugins (e.g., certbot-nginx) vary by distribution. Check the Certbot documentation for platform-specific instructions: https://certbot.eff.org Local development / testing: mkcert

mkcert makes short-lived, locally trusted certificates for development and testing by installing a local CA in your machine’s trust store.
These certificates are only appropriate for local testing and should never be used for public production sites.

mkcert installs a local CA in your OS/browser trust store so the generated certs are trusted on your development machine. It is very convenient for local HTTPS but is not a replacement for CA‑signed certificates like those from Let’s Encrypt in production.

Example mkcert workflow (local testing)

Install mkcert (platform-specific) and run mkcert --install once to register the local CA.
Generate certificates for one or more hostnames. Note: X.509 wildcards only match a single subdomain level (e.g., *.example.com matches a.example.com but not a.b.example.com).

sudo apt install mkcert
cd /etc/ssl/private
mkcert --install
mkcert '*.example.com'

Sample mkcert output (representative):

Created a new certificate valid for the following names 📜
 - "*.example.com"

Reminder: X.509 wildcards only go one level deep, so this won't match a.b.example.com ℹ️

The certificate is at "./_wildcard.example.com.pem" and the key at "./_wildcard.example.com-key.pem"

Place the generated certificate and key into secure locations (for example, certificate into /etc/ssl/certs/ and private key into /etc/ssl/private/) and reference those paths from your web server configuration.

Do not use mkcert-generated certificates in production. For public-facing services, always use CA-signed certificates (e.g., from Let’s Encrypt or a commercial CA).

Using the certificate in an Nginx server block

After obtaining the certificate and private key, reference them in your Nginx configuration and listen on port 443 for TLS traffic.
Example Nginx server block — adjust server_name and file paths to match your environment:

server {
    listen 443 ssl;
    server_name honda.cars.com;

    ssl_certificate /etc/ssl/certs/honda.cars.com.pem;
    ssl_certificate_key /etc/ssl/private/honda.cars.com-key.pem;

    root /var/www/honda.cars.com/html;
    index index.html;

    location / {
        try_files $uri $uri/ =404;
    }
}

After configuring Nginx, test and reload:

sudo nginx -t
sudo systemctl reload nginx

Quick reference table — certificate options

Certificate Type	Use Case	Notes
Let’s Encrypt	Production, automated	Free, widely trusted; use Certbot for automation
Commercial CA (DigiCert, Sectigo)	Enterprise/extended validation	Paid options, extended features and support
mkcert	Local development	Installs local CA; never use in production

Summary

HTTPS/TLS protects confidentiality and integrity of web traffic; it’s essential for any site handling sensitive data.
TLS certificates are issued and validated by Certificate Authorities. Let’s Encrypt provides free, trusted certificates and Certbot is a commonly used client for obtaining and renewing them.
Use mkcert only for local development and testing; do not use mkcert certs in production.
After obtaining certificates, configure your web server (example shown with Nginx) to serve HTTPS on port 443, and verify with nginx -t and browser or SSL tools.

Links and references

Certbot: https://certbot.eff.org
Let’s Encrypt: https://letsencrypt.org
mkcert GitHub: https://github.com/FiloSottile/mkcert
Nginx documentation: https://nginx.org/en/docs/

Now that you understand the concepts and commands, practice obtaining a certificate (e.g., with Certbot) and configuring Nginx to serve HTTPS for your site.

Introduction

Install & Config

Intermediate Config

Security

Performance

Conclusion

Watch Video