HTTPS Protocol

HTTPS (HTTP Secure) encrypts web traffic using TLS (Transport Layer Security). It's required for modern web security, SEO, and accessing modern browser APIs.

Understanding HTTPS is essential because it protects every interaction between your users and your server. Browsers mark plain HTTP pages as "Not secure", and Google has used HTTPS as a ranking signal since 2014.

"HTTPS (HyperText Transfer Protocol Secure) is an encrypted version of the HTTP protocol. It uses TLS to encrypt all communication between a client and a server."

HTTPS URL Structure

HTTPS URLs look nearly identical to HTTP URLs, with the only visible difference being the protocol. However, behind the scenes, TLS encryption wraps all communication between client and server.

# HTTPS URL components
https://example.com:443/path/page?query=value#fragment

# Components:
https://         - Scheme (secure HTTP)
example.com      - Host
:443             - Port (443 is default, usually omitted)
/path/page       - Path
?query=value     - Query string
#fragment        - Fragment

# Default port
https://example.com      # Port 443 (implicit)
https://example.com:443  # Port 443 (explicit, same as above)
https://example.com:8443 # Non-standard HTTPS port

The structure above shows that HTTPS URLs use port 443 by default (versus 80 for HTTP). When you see a URL without a port specified, browsers automatically use the default port for that protocol.

The security in HTTPS comes from the TLS protocol that encrypts the connection. Let's look at the evolution of these encryption protocols.

TLS/SSL Encryption

TLS (and its predecessor SSL) has evolved through multiple versions, with older versions deprecated due to discovered vulnerabilities. The table below shows which protocols are safe to use today.

Modern servers should support TLS 1.2 and 1.3 while disabling older versions. TLS 1.3 offers improved performance with faster handshakes and stronger security defaults.

TLS encryption requires a certificate that proves your domain ownership. Let's explore the different certificate types available.

SSL Certificates

SSL certificates serve two purposes: encrypting traffic and verifying that you own the domain. Different certificate types provide different levels of verification, from basic domain control to full organizational identity confirmation.

# Certificate types

# Domain Validation (DV)
# - Verifies domain ownership
# - Quick to obtain (minutes)
# - Free (Let's Encrypt) or low cost
# - Good for most websites

# Organization Validation (OV)
# - Verifies business exists
# - Manual vetting, slower than DV
# - Shows organization in certificate
# - Good for businesses

# Extended Validation (EV)
# - Extensive verification
# - Most extensive vetting, slowest to obtain
# - Historically showed green bar (no longer)
# - For high-trust sites (banks, government)

# Wildcard certificate
# *.example.com
# Covers one level of subdomains: www, app, api, etc.
# Does NOT cover example.com itself or a.b.example.com

For most websites, a free DV certificate from Let's Encrypt provides sufficient security. Wildcard certificates are convenient when managing multiple subdomains, covering every first-level subdomain with a single certificate (add the apex domain as a separate name).

Once you have HTTPS working, you should enforce it permanently using HSTS—a header that tells browsers to always use HTTPS for your domain.

HSTS (HTTP Strict Transport Security)

Once a browser has received the header over HTTPS, HSTS instructs it to automatically upgrade all HTTP requests to HTTPS for that host, even if a user types http:// or clicks an HTTP link. This prevents downgrade attacks and protects users from accidentally using insecure connections.

// HSTS forces browsers to use HTTPS

// HTTP response header
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

// Components:
// max-age=31536000    - Remember for 1 year
// includeSubDomains   - Apply to all subdomains
// preload             - Submit to browser preload list

// Express.js
app.use((req, res, next) => {
  res.setHeader(
    'Strict-Transport-Security',
    'max-age=31536000; includeSubDomains; preload'
  );
  next();
});

// With helmet middleware
const helmet = require('helmet');
app.use(helmet.hsts({
  maxAge: 31536000,
  includeSubDomains: true,
  preload: true
}));

// HSTS Preload
// Submit your domain to hstspreload.org
// Browser will never attempt HTTP for your domain

The code above shows how to add HSTS headers in Express.js, both manually and with the helmet middleware. The preload directive allows you to submit your domain to the HSTS preload list, which is built into browsers—meaning they'll never even attempt HTTP for your domain.

Even with HTTPS and HSTS configured, you can still have security issues if your page loads resources over HTTP. This is called mixed content.

Mixed Content

Mixed content occurs when an HTTPS page loads resources (scripts, images, stylesheets) over HTTP. Browsers block or warn about this because it undermines the security of your encrypted page.

<!-- Mixed content: HTTPS page loading HTTP resources -->

<!-- Blocked (active mixed content) -->
<script src="http://example.com/script.js"></script>
<iframe src="http://example.com/frame.html"></iframe>

<!-- Auto-upgraded to HTTPS, blocked if that fails (upgradable mixed content) -->
<img src="http://example.com/image.jpg">
<video src="http://example.com/video.mp4"></video>

<!-- Solutions -->

<!-- 1. Use protocol-relative URLs (not recommended) -->
<script src="//example.com/script.js"></script>

<!-- 2. Use HTTPS explicitly (recommended) -->
<script src="https://example.com/script.js"></script>

<!-- 3. Upgrade insecure requests -->
<meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests">

<!-- This header tells browsers to upgrade HTTP to HTTPS automatically -->

Blockable mixed content (scripts, iframes, stylesheets, fetch) is blocked completely, while current browsers auto-upgrade image, audio and video requests to HTTPS (and the resource fails to load if HTTPS isn't available). The best solution is using HTTPS URLs explicitly, or adding the upgrade-insecure-requests CSP directive to automatically upgrade HTTP resources.

Beyond fixing mixed content, you may need to programmatically verify SSL certificates—for monitoring, debugging, or building security tools.

Certificate Verification

Programmatically checking SSL certificates helps you monitor expiration dates, verify configurations, and debug TLS issues. The Node.js example below shows how to extract certificate details from any HTTPS connection.

// Check certificate in Node.js
const https = require('https');

function checkCertificate(hostname) {
  return new Promise((resolve, reject) => {
    const req = https.request({
      hostname,
      port: 443,
      method: 'GET'
    }, (res) => {
      const cert = res.socket.getPeerCertificate();
      res.resume(); // drain the body so the socket can close

      resolve({
        subject: cert.subject,
        issuer: cert.issuer,
        valid_from: cert.valid_from,
        valid_to: cert.valid_to,
        fingerprint: cert.fingerprint,
        serialNumber: cert.serialNumber
      });
    });

    req.on('error', reject);
    req.end();
  });
}

// Check expiry (ES module: top-level await)
const cert = await checkCertificate('example.com');
const expiry = new Date(cert.valid_to);
const daysUntilExpiry = Math.floor((expiry - new Date()) / (1000 * 60 * 60 * 24));

if (daysUntilExpiry < 30) {
  console.warn('Certificate expires soon:', daysUntilExpiry, 'days');
}

This code connects to a server and extracts certificate information including issuer, validity dates, and fingerprint. The expiry check at the end is useful for monitoring—Let's Encrypt certificates are currently valid for 90 days by default (scheduled to drop to 64 days in February 2027 and 45 days in February 2028), so automated checks help prevent outages.

Beyond security, HTTPS is required for many modern browser features. Let's look at which APIs only work on secure origins.

HTTPS-Only Browser APIs

Modern browsers restrict powerful APIs to secure contexts (HTTPS) to protect user privacy and security. If you need any of these features, HTTPS is non-negotiable.

These APIs are blocked on HTTP because they access sensitive user data or device capabilities. Service workers, for example, can intercept network requests—a powerful feature that could be exploited if allowed on insecure connections.