How to Implement HTTPS on Your Website: A Step-by-Step Guide with Let’s Encrypt

If you are still running a website on plain HTTP in 2026, browsers are actively shaming your visitors with “Not Secure” warnings, Google is downranking you, and modern features like HTTP/2, HTTP/3, and service workers simply will not work. The good news? Enabling HTTPS is free, fast, and fully automatable thanks to Let’s Encrypt.

In this hands-on guide, we will walk through exactly how to implement HTTPS on your website using real terminal commands, working Nginx and Apache snippets, and an auto-renewal setup that you can forget about for years.

Why HTTPS Is Non-Negotiable in 2026

Before jumping into commands, let’s quickly cover what HTTPS actually does. HTTPS is HTTP wrapped in TLS encryption. It guarantees three things:

• Confidentiality: traffic between the browser and your server is encrypted.
• Integrity: nobody can tamper with the data in transit.
• Authenticity: visitors know they are really talking to your server.

Unlike the old GoDaddy or commercial route where you buy a certificate, request it, then install it manually, Let’s Encrypt issues free, automated, 90-day certificates that renew themselves. No credit card, no annual renewal panic.

Prerequisites Before You Start

You need the following ready:

1. A registered domain name (e.g. example.com).
2. An A record (and ideally an AAAA record for IPv6) pointing to your server’s public IP.
3. Port 80 and 443 open in your firewall and security groups.
4. SSH access to your Linux server (Ubuntu 24.04, Debian 12, or similar).
5. A working Nginx or Apache installation already serving your site over HTTP.

Quick check: run dig +short yourdomain.com from your laptop. It must return your server’s IP. If DNS is not propagated yet, wait before continuing, otherwise certificate validation will fail.

Step 1: Install Certbot

Certbot is the official Let’s Encrypt client. The recommended installation method in 2026 is via snap, which keeps it always up to date.

sudo snap install core; sudo snap refresh core
sudo snap install --classic certbot
sudo ln -s /snap/bin/certbot /usr/bin/certbot

Verify the installation:

certbot --version

Step 2: Obtain and Install Your Certificate

Certbot can either automatically edit your web server config, or just give you the certificate files. For most people, the automatic option is the right call.

For Nginx

sudo certbot --nginx -d example.com -d www.example.com

For Apache

sudo certbot --apache -d example.com -d www.example.com

You will be asked for an email (for expiration notices) and whether to redirect HTTP traffic to HTTPS. Always say yes to the redirect. Certbot will then:

• Prove to Let’s Encrypt that you control the domain (HTTP-01 challenge on port 80).
• Download the certificate to /etc/letsencrypt/live/example.com/.
• Edit your server config to use it.
• Reload your web server.

Visit https://example.com. You should see the padlock.

Step 3: Hardened Nginx Configuration

The default Certbot config works, but a production setup deserves stronger TLS settings. Here is a clean, modern Nginx server block:

server {
    listen 80;
    listen [::]:80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    http2 on;
    server_name example.com www.example.com;

    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers off;
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 1d;
    ssl_session_tickets off;

    add_header Strict-Transport-Security "max-age=63072000; includeSubDomains" always;
    add_header X-Content-Type-Options nosniff always;
    add_header X-Frame-Options SAMEORIGIN always;

    root /var/www/example.com;
    index index.html;
}

Test and reload:

sudo nginx -t && sudo systemctl reload nginx

Step 4: Hardened Apache Configuration

For Apache, make sure these modules are enabled:

sudo a2enmod ssl headers http2 rewrite
sudo systemctl restart apache2

Example virtual host:

<VirtualHost *:80>
    ServerName example.com
    ServerAlias www.example.com
    Redirect permanent / https://example.com/
</VirtualHost>

<VirtualHost *:443>
    ServerName example.com
    ServerAlias www.example.com
    DocumentRoot /var/www/example.com

    Protocols h2 http/1.1

    SSLEngine on
    SSLCertificateFile      /etc/letsencrypt/live/example.com/fullchain.pem
    SSLCertificateKeyFile   /etc/letsencrypt/live/example.com/privkey.pem

    SSLProtocol             all -SSLv3 -TLSv1 -TLSv1.1
    SSLHonorCipherOrder     off
    SSLSessionTickets       off

    Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains"
</VirtualHost>

Step 5: Set Up Auto-Renewal (and Actually Test It)

Let’s Encrypt certificates last only 90 days. Certbot installs a systemd timer or cron job automatically. Confirm it is active:

systemctl list-timers | grep certbot

Then do a dry run. This is the single most important command in this entire guide:

sudo certbot renew --dry-run

If it succeeds, renewals will happen automatically in the background, typically when the certificate has 30 days or less remaining.

Optional: deploy hook

If you need to restart something else after renewal (a Node.js app, HAProxy, mail server), add a hook:

sudo certbot renew --deploy-hook "systemctl reload nginx"

Common Mistakes to Avoid

Mistake	Why it breaks	Fix
Closing port 80 after setup	Renewals via HTTP-01 challenge fail	Keep 80 open or switch to DNS-01
Using cert.pem instead of fullchain.pem	Intermediate chain missing, mobile browsers fail	Always point to fullchain.pem
Mixed content (HTTP images on HTTPS pages)	Padlock disappears, console errors	Update asset URLs to https:// or protocol-relative
Enabling HSTS too early	If HTTPS later breaks, users are locked out	Start with short max-age (e.g. 300), grow later
Forgetting the www variant	Cert invalid for www.example.com	Pass both domains to Certbot with -d
Never testing renewal	Silent failure until expiry day	Run certbot renew --dry-run after every config change

Step 6: Verify Your Setup

Once HTTPS is live, validate it with these tools:

• SSL Labs: https://www.ssllabs.com/ssltest/ — aim for an A or A+ grade.
• Mozilla Observatory: checks security headers.
• curl: curl -I https://example.com should return HTTP/2 200 and your HSTS header.

Bonus: Wildcard Certificates with DNS-01

If you need to cover *.example.com, the HTTP-01 challenge will not work. Use the DNS-01 challenge instead. Most major DNS providers (Cloudflare, Route53, OVH, DigitalOcean) have official Certbot plugins:

sudo snap install certbot-dns-cloudflare
sudo certbot certonly \
  --dns-cloudflare \
  --dns-cloudflare-credentials /root/.secrets/cf.ini \
  -d example.com -d "*.example.com"

FAQ

Is Let’s Encrypt really free, even for commercial sites?

Yes. There are no fees, no tiers, and no restrictions on commercial usage. The only “cost” is that certificates are valid for 90 days, which is solved by automation.

Do I still need a paid SSL certificate for anything?

Only if you need an Extended Validation (EV) certificate showing your organization name in specific legacy contexts, or if your compliance framework specifically requires a paid CA. For 99% of websites, Let’s Encrypt is identical from a browser security standpoint.

What happens if my certificate expires?

Visitors will see a full-screen browser warning and most will leave immediately. As long as certbot renew --dry-run succeeds and your server stays online, this will not happen.

Can I use Let’s Encrypt behind Cloudflare?

Yes. Use Cloudflare’s Full (strict) SSL mode, and install a Let’s Encrypt certificate on your origin server. Cloudflare will validate it on each request.

How do I implement HTTPS on a website hosted on shared hosting?

Most modern shared hosts (cPanel, Plesk, DirectAdmin) ship with a one-click Let’s Encrypt integration in the control panel. Look for “SSL/TLS Status” or “AutoSSL”. You will not need to touch the terminal.

What about HTTP/3?

Once HTTPS is in place, enabling HTTP/3 (QUIC) is just a few extra directives in Nginx (>= 1.25) or Caddy. We will cover that in an upcoming post on the Coding4 blog.

Wrapping Up

Implementing HTTPS on a website used to mean buying certificates, generating CSRs, copying intermediate chains, and praying. In 2026, it is three commands and a dry run. There is no longer any technical or financial excuse to ship plain HTTP.

If you would like our team at Coding4 to audit your TLS setup, fix mixed-content issues, or migrate a legacy stack to HTTPS and HTTP/3, get in touch via our contact page. We do this stuff every week.