HTTPS (HyperText Transfer Protocol Secure) is the encrypted version of HTTP — the foundation of data communication on the web. Every time you see a padlock icon in your browser's address bar, HTTPS is working in the background to encrypt the connection between your browser and the website, protecting your data from interception and tampering. Understanding what HTTPS is, how it works, and why it matters is essential for anyone running a website, managing servers, or making decisions about web security.
What Is HTTPS?
HTTPS stands for HyperText Transfer Protocol Secure. It is an extension of HTTP — the protocol that governs how data is transferred between a web browser and a web server. The difference is the "S": HTTPS adds a layer of encryption via SSL/TLS (Secure Sockets Layer / Transport Layer Security), which ensures that all data exchanged between a browser and a server is encrypted, authenticated, and integrity-protected.
When you visit a website over HTTPS, three things are guaranteed:
- Encryption: All data in transit is encrypted so that even if intercepted, it cannot be read by an attacker.
- Authentication: The website's identity has been verified by a trusted Certificate Authority (CA), confirming you are talking to the genuine website and not an impostor.
- Data integrity: Data cannot be modified or corrupted during transit without detection. If tampering occurs, the connection is immediately terminated.
Without HTTPS, all data transmitted between a browser and a server — including passwords, form submissions, payment details, and session tokens — travels in plain text. Any attacker positioned between the user and the server (a "man-in-the-middle" attacker) can read, steal, or modify that data without either party knowing.
💡 None of these worked? Skip the guesswork.
Get Expert Help →How HTTPS Works: The SSL/TLS Handshake
The security of HTTPS depends on the SSL/TLS handshake — a negotiation process that occurs before any application data is exchanged. This handshake establishes the encrypted channel that all subsequent communication flows through. Here is how it works step by step:
The browser sends a "Client Hello" message to the server, containing the TLS version it supports, a list of supported cipher suites (encryption algorithms), and a randomly generated number used later in key generation.
The server responds with a "Server Hello," selecting the highest mutually supported TLS version and cipher suite. It sends its SSL/TLS certificate, which contains the server's public key and has been digitally signed by a trusted Certificate Authority. This certificate proves the server's identity.
The browser verifies the server's certificate against its built-in list of trusted Certificate Authorities. It checks that the certificate has not expired, has not been revoked, and matches the domain being accessed. If any check fails, the browser displays a security warning and blocks the connection.
The browser and server use the server's public key (and in TLS 1.3, a Diffie-Hellman key exchange) to securely establish a shared session key — a symmetric encryption key that will encrypt all data for this session. The session key never travels across the network, making interception impossible.
Both parties confirm the handshake is complete, and all subsequent data is encrypted using the session key. The handshake in TLS 1.3 completes in a single round trip — significantly faster than the two-round-trip handshake required by TLS 1.2, reducing latency for users.
For most websites, a free DV certificate from Let's Encrypt is appropriate and sufficient. Let's Encrypt is a non-profit Certificate Authority that issues free, automated, and open certificates trusted by all major browsers. For business websites where displaying organisational identity in certificate details matters, obtain an OV certificate from a commercial CA such as DigiCert, Sectigo, or GlobalSign. For financial services or high-trust applications, consider an EV certificate.
For Let's Encrypt certificates on Linux servers, the recommended tool is Certbot. Installation on Apache:
sudo apt install certbot python3-certbot-apache
sudo certbot --apache -d yourdomain.com -d www.yourdomain.comFor Nginx:
sudo apt install certbot python3-certbot-nginx
sudo certbot --nginx -d yourdomain.com -d www.yourdomain.comCertbot automatically configures the web server and sets up automatic certificate renewal. For commercial certificates, the CA will provide the certificate files (typically a .crt and intermediate chain file) which you install manually by referencing them in your server configuration.
For Nginx, a basic HTTPS server block looks like this:
server {
listen 443 ssl http2;
server_name yourdomain.com www.yourdomain.com;
ssl_certificate /etc/letsencrypt/live/yourdomain.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/yourdomain.com/privkey.pem;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384;
ssl_prefer_server_ciphers off;
add_header Strict-Transport-Security "max-age=63072000" always;
}Add a server block to redirect all HTTP requests to HTTPS (Nginx):
server {
listen 80;
server_name yourdomain.com www.yourdomain.com;
return 301 https://$host$request_uri;
}This 301 redirect is permanent — it also passes SEO link equity from HTTP URLs to their HTTPS equivalents, preserving search rankings during migration.
Add the HSTS header to instruct browsers to always connect via HTTPS, even if the user types http://. The configuration shown in Step 3 includes this header. The max-age=63072000 value sets a two-year HSTS policy. Once HSTS is active, removing it requires the full max-age period to expire — only enable it when you are certain HTTPS is stable.
Ensure all internal links on your website use https:// or protocol-relative URLs (//). Any resources (images, scripts, stylesheets) loaded over HTTP on an HTTPS page trigger "mixed content" warnings that partially break the security guarantee and may cause browser warnings. Use browser developer tools or a mixed content scanner to identify and fix any HTTP resources.
Let's Encrypt certificates expire after 90 days. Certbot automatically adds a renewal cron job or systemd timer. Verify it is active:
sudo certbot renew --dry-runFor commercial certificates with annual renewal, set a calendar reminder 30 days before expiry — certificate expiry is one of the most common and avoidable causes of website security incidents.
HTTPS Configuration Best Practices
Installing a certificate is just the first step. Proper HTTPS configuration means regularly testing and hardening your TLS setup:
- Use TLS 1.2 and 1.3 only. Disable TLS 1.0 and 1.1 — both are deprecated and vulnerable to known attacks (POODLE, BEAST). TLS 1.3 is the preferred version for all new deployments.
- Use strong cipher suites. Prioritise ECDHE-based cipher suites with AES-GCM or ChaCha20-Poly1305. Disable RC4, 3DES, and NULL cipher suites entirely.
- Enable OCSP Stapling. OCSP (Online Certificate Status Protocol) stapling allows the server to proactively provide certificate validity information, reducing browser lookup delays and improving performance.
- Test your configuration regularly. Use SSL Labs' free SSL Server Test (ssllabs.com/ssltest) to get a detailed grade of your TLS configuration and identify any weaknesses. Aim for an A+ rating.
- Monitor certificate expiry proactively. Use monitoring tools or services that alert you at least 30 days before certificate expiry — before users start seeing browser warnings.
- Consider certificate pinning for high-security applications. Certificate pinning instructs a client application to only trust specific certificates or public keys for a domain, preventing attacks even if a CA is compromised. Most appropriate for mobile applications and APIs, not general-purpose websites.
Troubleshooting Common HTTPS Issues
Even after correct installation, HTTPS issues occasionally arise. Here are the most common problems and how to resolve them:
- Browser warning: "Your connection is not private" / NET::ERR_CERT_AUTHORITY_INVALID: The certificate is not trusted by the browser. Most common causes: the certificate chain is incomplete (the intermediate CA certificate is missing from the server configuration), the certificate is self-signed, or the certificate was issued by a CA not in the browser's trust store. Fix: ensure the full certificate chain (leaf certificate + all intermediate certificates) is installed on the server.
- Mixed content warnings: The page is loaded over HTTPS but some resources (images, scripts, iframes) are still referenced via HTTP URLs. Fix: update all resource URLs to HTTPS, use protocol-relative URLs, or add a
Content-Security-Policy: upgrade-insecure-requestsheader to force the browser to upgrade HTTP resource requests automatically. - Certificate name mismatch: The domain in the browser's address bar does not match the domain(s) on the certificate. Fix: ensure the certificate covers the exact domain being accessed, including or excluding the
www.prefix as appropriate, or use a SAN certificate that covers both. - SSL handshake timeout or failure: Often caused by firewall rules blocking port 443, an incorrect certificate/key pair, or TLS version/cipher mismatch between client and server. Check firewall rules, verify the certificate and private key match (their modulus should be identical), and confirm the server supports at least TLS 1.2.
- Expired certificate: Browser will show a certificate expiry warning and block access. Immediately renew the certificate using your CA's renewal process or by running
certbot renewfor Let's Encrypt certificates. This is preventable with automated renewal and proactive expiry monitoring.
HTTPS and Server Hardening
Proper HTTPS configuration is one component of a broader server hardening strategy. A correctly installed and configured TLS setup — with strong cipher suites, HSTS, OCSP stapling, and disabled legacy protocols — significantly reduces a server's attack surface. However, it works best as part of a comprehensive security posture that also includes OS-level hardening, regular patching, intrusion detection, and security monitoring.
If your organisation needs expert assistance with TLS configuration, SSL certificate management, or broader infrastructure security, our server hardening services cover the full stack — from web server TLS configuration to firewall rules, OS hardening, and ongoing security monitoring.
Conclusion
HTTPS is not a feature — it is the baseline security expectation for every website in 2026. It protects your users' data, authenticates your site's identity, improves your search rankings, enables modern web performance features, and is increasingly a legal compliance requirement. The barriers to adoption have never been lower: free certificates are available from Let's Encrypt, and automated tools like Certbot make installation and renewal straightforward on any Linux server. If any website you own or manage is still running over HTTP, migrating to HTTPS should be your immediate next step.