Educational Content: This article is written for educational purposes to help developers and cybersecurity students understand software concepts. Always follow ethical guidelines and applicable laws.
Every browser shows a little padlock icon next to HTTPS URLs. Most people — including a lot of developers — treat that padlock as a simple on/off switch. Either the connection is secure or it isn't. The reality underneath that icon is significantly more interesting, and understanding it properly changes how you think about building secure applications.
This post walks through how HTTPS actually works from the ground up — the TLS handshake, how certificates are verified, what encryption is actually protecting what, and how concepts like certificate pinning fit in for mobile and API development.
Why HTTP Alone Is a Problem
Plain HTTP sends everything as readable text. Every request your browser makes, every response the server sends back — headers, cookies, form data, passwords — travels across the network in a format that anyone positioned between your device and the server can read and modify.
This isn't theoretical. On a shared WiFi network — a coffee shop, an airport, a university — traffic can be observed by other devices on the same network with freely available tools. Internet service providers can read unencrypted traffic. Anyone operating a router your traffic passes through can see and modify it.
HTTPS solves this by wrapping HTTP inside TLS (Transport Layer Security) — a protocol that encrypts the connection and verifies the identity of the server you're talking to. Those two things together — encryption and identity verification — are what the padlock actually represents.
What TLS Actually Does
TLS does three distinct things that are worth understanding separately:
Encryption — The data exchanged between client and server is encrypted so that anyone intercepting the traffic sees only meaningless ciphertext. They can see that a connection exists, roughly how much data is being transferred, and the IP addresses involved — but not the content.
Authentication — The server proves its identity to the client using a digital certificate. This is what prevents an attacker from intercepting your connection to yourbank.com and serving you a fake version — they can't get a legitimate certificate for a domain they don't control.
Integrity — The data cannot be tampered with in transit. If anyone modifies the encrypted traffic between client and server, TLS detects it and the connection fails. This prevents injection of malicious content into otherwise legitimate responses.
The TLS Handshake — Step by Step
Every HTTPS connection begins with a handshake — a negotiation between client and server that establishes the encrypted channel before any actual data is sent. Here's what happens:
1. Client Hello — Your browser sends a message to the server listing the TLS versions it supports, the cipher suites it can use (combinations of encryption algorithms), and a random number it generated.
2. Server Hello — The server responds by selecting the TLS version and cipher suite from the client's list, sending its own random number, and sending its digital certificate.
3. Certificate Verification — Your browser examines the server's certificate. It checks that the certificate was issued by a trusted Certificate Authority (CA), that it hasn't expired, that it hasn't been revoked, and that the domain name on the certificate matches the domain you're connecting to. If any of these checks fail, you see a browser warning.
4. Key Exchange — Using the server's public key (from the certificate) and the random numbers exchanged earlier, the client and server derive a shared secret. Modern TLS uses Diffie-Hellman key exchange for this, which has the property that even someone who records all the traffic and later obtains the server's private key cannot decrypt past sessions — this is called Perfect Forward Secrecy.
5. Finished — Both sides send a Finished message encrypted with the new shared secret. If both sides can decrypt each other's Finished message correctly, the handshake is complete and the encrypted channel is established. All subsequent HTTP data travels through this encrypted tunnel.
How Certificates Work
A TLS certificate is a digital document that binds a public key to a domain name, issued and signed by a Certificate Authority that browsers trust.
The trust chain works like this: your operating system and browser ship with a built-in list of trusted root CAs — organizations like Let's Encrypt, DigiCert, and Sectigo whose certificates are embedded in your browser. When a server presents its certificate, your browser traces the certificate's chain of signatures back to one of these trusted roots. If the chain is valid and unbroken, the certificate is trusted.
This is why you can't just generate your own certificate and have browsers trust it — you're not in the trusted root list. It's also why certificate theft is serious — anyone with a certificate's private key can impersonate that domain to anyone who trusts that CA.
Getting a certificate for your own domain has become extremely accessible. Let's Encrypt provides free, automated certificates that are trusted by all major browsers. If you're using Hostinger or any modern hosting provider, they typically offer one-click SSL installation.
Implementing HTTPS Correctly in PHP
Having an SSL certificate installed isn't enough on its own. You also need to make sure your application uses it correctly.
Force HTTPS redirects:
<?php
// At the top of your entry point or in a middleware
if (empty($_SERVER['HTTPS']) || $_SERVER['HTTPS'] === 'off') {
$redirect = 'https://' . $_SERVER['HTTP_HOST'] . $_SERVER['REQUEST_URI'];
header('HTTP/1.1 301 Moved Permanently');
header('Location: ' . $redirect);
exit;
}
Or via .htaccess which is cleaner and faster:
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
Set the HSTS header:
<?php
// Strict-Transport-Security tells browsers to always use HTTPS for your domain
// Even if the user types http:// — the browser upgrades automatically
header('Strict-Transport-Security: max-age=31536000; includeSubDomains; preload');
HSTS (HTTP Strict Transport Security) is important because the redirect approach has a weakness: the very first HTTP request before the redirect can be intercepted. With HSTS, after the first visit the browser remembers to always use HTTPS, skipping the HTTP request entirely.
Verify SSL when making outgoing requests:
<?php
// When your PHP code makes HTTP requests to external APIs
// Always verify SSL — never disable verification
$ch = curl_init('https://api.external-service.com/endpoint');
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, true); // NEVER set to false in production
curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, 2);
$response = curl_exec($ch);
curl_close($ch);
Disabling SSL verification in curl is a common "quick fix" for certificate errors during development. Deploying that to production is a serious security issue — it means your server will connect to anyone claiming to be the target API, including an attacker positioned in the middle.
Certificate Pinning for APIs and Mobile Apps
Standard TLS trusts any certificate from any CA in the trusted root list. Certificate pinning takes this further — you hardcode the expected certificate or public key directly in your application, so it only trusts that specific certificate, regardless of what the system's CA store says.
This is primarily relevant for mobile applications and API clients. It prevents attacks where an attacker installs a custom CA certificate on the device and uses it to issue a trusted certificate for your domain — something that's possible on rooted devices with tools that security researchers use for traffic analysis.
A simplified illustration of the verification logic:
// Conceptual pinning check in a PHP API client
function fetchWithPinning($url, $expectedPublicKeyHash) {
$ch = curl_init($url);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, true);
// Get certificate info after connection
curl_setopt($ch, CURLOPT_CERTINFO, true);
$response = curl_exec($ch);
$certInfo = curl_getinfo($ch, CURLINFO_CERTINFO);
curl_close($ch);
// Verify the certificate matches your expected hash
// In practice you'd extract and hash the public key from certInfo
// and compare it to your stored hash
return $response;
}
In Android development, OkHttp provides built-in certificate pinning support through its CertificatePinner class, which is cleaner to implement than manual verification.
One important caveat: pinned certificates expire. If you pin a certificate and it expires — or if you switch providers — your application stops working until users update. Build certificate rotation into your pinning strategy from the start, typically by pinning multiple certificates simultaneously so you can rotate without breaking existing installs.
Common HTTPS Mistakes Developers Make
Mixed content — Your page loads over HTTPS but includes resources (images, scripts, stylesheets) from HTTP URLs. Browsers block or warn on mixed content. Fix it by ensuring every resource reference uses HTTPS or a protocol-relative URL.
<!-- Wrong -->
<script src="http://cdn.example.com/library.js"></script>
<!-- Right -->
<script src="https://cdn.example.com/library.js"></script>
Cookies without the Secure flag — A cookie without Secure can be sent over HTTP connections. If a user visits any HTTP version of your page, that cookie travels in plain text.
<?php
session_set_cookie_params([
'secure' => true, // Only send over HTTPS
'httponly' => true,
'samesite' => 'Strict'
]);
Outdated TLS versions — TLS 1.0 and 1.1 have known vulnerabilities and are considered deprecated. Your server should only accept TLS 1.2 and TLS 1.3. Check your Hostinger SSL settings or your server's nginx/Apache configuration to confirm which versions are enabled.
Weak cipher suites — Some older cipher configurations allow weak encryption that can be broken. Tools like SSL Labs' free server test (ssllabs.com/ssltest) will grade your configuration and flag specific weaknesses.
Testing Your HTTPS Setup
A few quick things to verify your setup is solid:
SSL Labs test — Go to ssllabs.com/ssltest and enter your domain. It runs a comprehensive analysis and gives you a grade from A+ to F with specific recommendations. Aim for at least A.
securityheaders.com — Checks your HTTP response headers including HSTS, CSP, and other security-relevant headers. Shows you exactly what's missing and what it does.
Check your certificate expiry — Add a reminder to check certificate expiry dates, or better, set up automated renewal. Let's Encrypt certificates expire every 90 days but renew automatically if configured correctly. A lapsed certificate takes your entire site offline from a user's perspective — they see a scary warning and most will leave immediately.
The Bigger Picture
HTTPS is table stakes for any website or application in 2026. It's no longer optional — browsers actively flag HTTP sites as insecure, search engines factor HTTPS into rankings, and users have been trained to look for the padlock. But beyond the basics, understanding how TLS actually works — the handshake, the certificate chain, the key exchange — lets you make better decisions when things go wrong, when you're integrating with external APIs, and when you're building mobile applications that need strong connection security.
The padlock is the result of a lot of moving parts working correctly together. Now you know what those parts are.
— Skand K.
