HTTPS

All right — let’s talk about HTTPS, why it matters, and how it works. HTTPS (HTTP over TLS) encrypts the connection between a user’s browser and a web server. That encryption prevents eavesdroppers from reading or tampering with data in transit and is a baseline requirement for modern websites — for privacy, security, and search ranking. Why HTTPS matters

Security: On untrusted networks (coffee shops, airports), sensitive data such as passwords, session cookies, and payment information can be intercepted unless the connection is protected by TLS.
Trust & authenticity: TLS certificates let browsers verify that a website is the site it claims to be, preventing simple impersonation attacks.
SEO & user experience: Search engines and browsers favor HTTPS-enabled sites; some browser features require secure contexts.

An illustration titled "Importance of HTTPS" showing people in a coffee shop using laptops and public Wi‑Fi, with dotted lines indicating unsecured connections and a password/login box labeled "Without HTTPS."

Without HTTPS, traffic is sent in plaintext and can be read or modified by attackers. With HTTPS, traffic is encrypted, so intercepted bytes are useless without the proper keys.

A presentation slide titled "Importance of HTTPS" with a "02 SEO Benefits" heading. It shows a stylized browser window displaying the URL "https://mydomain.com/" and colored lines representing webpage content.

SSL and TLS

SSL (Secure Sockets Layer) is the legacy protocol. TLS (Transport Layer Security) is its modern replacement.
Today, when people say “SSL certificate,” they usually mean an X.509 certificate used with TLS.
TLS provides confidentiality, integrity, and server authentication between the browser and the web server.

A slide titled "SSL and TLS" explaining that the protocols ensure privacy and integrity between a browser and a web server. The illustration shows a browser icon and a stack of servers connected and protected by a shield with a checkmark.

How the TLS handshake works (high level) A TLS handshake establishes a secure channel before sensitive data (e.g., payment details) is submitted. Simplified flow:

The browser connects to the website and requests a secure session (this is automatic when visiting an HTTPS URL).
The server sends a TLS certificate — a digitally signed document containing the server’s public key and identity information. The browser validates the certificate chain up to a trusted Certificate Authority (CA).

A simple diagram showing step 2 of an SSL/TLS exchange: the store's web server sends its SSL/TLS certificate to the user's payment form. It depicts a user icon on the left, a payment form in the center, and server racks labeled "Store's Web Server" on the right.

If the certificate checks out, the browser and server perform a key exchange (often using ephemeral keys) to agree on a symmetric session key.
The agreed symmetric key encrypts the rest of the session (fast and efficient for bulk data).

What is a Certificate Authority (CA)? A CA is a trusted third party that verifies identity and signs TLS certificates. Certificates typically include domain names and organization details to help browsers verify server identity.

A presentation slide titled "Certificate Authority" stating that it governs and manages digital certificates. It shows an illustration of a company/person pointing to a certificate with bullets for user's name, company information, and website address.

The TLS certificate acts like an online ID card — it confirms that https://onlinestore.com is actually the site it claims to be and not an imposter.

A slide titled "Certificates" showing a stylized browser window with a highlighted https://www.onlinestore.com address and an SSL certificate icon. It visually represents an SSL/TLS certificate verifying the site's authenticity.

Asymmetric encryption: public and private keys TLS uses asymmetric cryptography to authenticate the server and establish a shared symmetric key:

The server publishes a public key (in the certificate).
The server keeps the corresponding private key secret.
Asymmetric operations authenticate and perform key exchange; the resulting symmetric session key encrypts bulk data for the session.

A simple diagram showing a web server handing a public key (illustrated by an open padlock) to a browser. The browser then uses that key to encrypt the data being sent.

The private key must remain secure on the server. Modern TLS setups often use ephemeral (short-lived) keys for forward secrecy so a compromised long-term key cannot decrypt past sessions.

A slide titled "Private Key" showing a padlock icon inside a speech-bubble-like box and a separate key icon labeled "Kept secret by the server." The image illustrates that the private key is stored secretly on the server.

Putting it together When you submit a credit card number, the browser and server encrypt the data with the symmetric session key negotiated during the handshake. The server decrypts and processes the payment securely. Asymmetric keys are only used initially for authentication and key agreement.

A diagram titled "How Keys Work in Practice" showing a browser form submitting a credit card number that gets encrypted, sent to a server, and decrypted with a private key. The decrypted data is then used to process the payment.

Certificate Authorities (examples) Many commercial CAs exist; Let’s Encrypt is the most popular free CA and is widely automated and trusted by browsers.

Table — Common CAs and when to use them

CA	Use case	Notes
Let’s Encrypt	Free, automated certificates for most public sites	Ideal for most websites; certs renew every 90 days
DigiCert	Commercial, enterprise-grade certificates	Paid options, enterprise support, extended validation
Comodo / Sectigo	Commercial certificates	Widely used in legacy enterprise environments

Obtaining certificates Certbot (Let’s Encrypt)

Certbot is a widely used tool to request and renew Let’s Encrypt certificates.
On Debian/Ubuntu, install certbot and request certificates as shown.

sudo apt update
sudo apt install certbot

Example: obtain a certificate using the standalone plugin (Certbot runs a temporary web server for the HTTP-01 challenge):

sudo certbot certonly --standalone --preferred-challenges http -d devops.org -d www.devops.org

Requirements for that command:

You own the domain(s).
DNS A records point to the server’s public IP where certbot runs.
Port 80 is reachable from the internet for the HTTP challenge.

mkcert (local development / testing)

For local development, use mkcert to generate locally trusted certs. These are convenient for testing but are not valid on the public internet.
Do not deploy mkcert-generated certificates to production.

mkcert produces locally-trusted certificates for development only. Do not use mkcert-generated certificates in production.

Example mkcert workflow:

sudo apt update
sudo apt install mkcert

# Install mkcert's local CA and create certificates, often run as the user; location depends on your OS
mkcert -install
mkcert '*.example.com'

Sample mkcert output:

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"
The key is at "./_wildcard.example.com-key.pem"

Reference the generated cert and key in your server config when testing locally. Nginx server block example Once you have certificate and key files available on the server, a minimal Nginx server block for HTTPS looks like:

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

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

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

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

Security hardening (recommended for production)

Enforce TLS 1.2+ (prefer TLS 1.3 where supported).
Use modern cipher suites and enable forward secrecy.
Enable HSTS (Strict-Transport-Security) so browsers always use HTTPS.
Consider OCSP stapling and certificate pinning only if you understand the operational tradeoffs.
Automate certificate renewal (Certbot can install hooks to reload Nginx after renewal).

Summary

HTTPS (TLS) encrypts traffic between browsers and servers, protecting confidentiality and integrity.
TLS replaced SSL; certificates issued by trusted CAs enable browsers to verify site identity.
Let’s Encrypt + Certbot is a standard, automated way to obtain public TLS certificates.
Use mkcert for local development only.
Configure your web server (Nginx example above) with the certificate and key, and apply production-grade TLS hardening.

Next steps

Try obtaining a Let’s Encrypt certificate in a lab and configure Nginx to serve your site with HTTPS.
Use tools like SSL Labs (https://www.ssllabs.com/ssltest/) to scan your TLS configuration and improve your score.

Introduction

Install & Config

Intermediate Config

Security

Performance

Conclusion

Watch Video