HTTPS, SSL & Security
What is SSL?
SSL, Secure Sockets Layer, is a cryptographic protocol that establishes encrypted, authenticated connections between clients and servers over the internet. Originally developed by Netscape in the mid-1990s SSL created the foundation for secure web communication, enabling browsers to connect to servers with confidence that the connection was private, that the server was who it claimed to be, and that data transmitted could not be intercepted or modified in transit.
The SSL name is almost universally used today as a colloquial term for what is technically TLS: Transport Layer Security, the modern, improved successor to SSL. The actual SSL protocol versions, SSL 2.0 and SSL 3.0, are deprecated and disabled in all modern browsers and servers due to serious security vulnerabilities discovered over the years. What actually secures connections today is TLS 1.2 or TLS 1.3, but the SSL name persists in everyday usage. When someone says SSL, when they refer to SSL certificates, SSL configuration, or SSL errors, they almost always mean TLS in practice. The terms are used interchangeably across the industry.
SSL, and by extension TLS, is foundational to how HTTPS works. The S in HTTPS stands for Secure and that security comes from SSL/TLS encrypting the HTTP connection. Every redirect that involves HTTPS depends on SSL, without valid SSL certificates on domains serving redirects the entire redirect chain can break for HTTPS visitors. Understanding SSL is understanding the security layer beneath all secure web communication.
How SSL works
SSL, in its modern TLS form, secures connections through a combination of asymmetric and symmetric cryptography, certificate-based authentication, and message integrity verification. The process begins with a handshake that establishes the secure channel before any application data is transmitted.
Public key cryptography foundation: SSL uses asymmetric cryptography, a mathematically linked key pair consisting of a public key and a private key. Data encrypted with the public key can only be decrypted with the corresponding private key and vice versa. The public key is distributed freely, embedded in the SSL certificate that the server presents to browsers. The private key is kept secret on the server, never transmitted or shared.
Asymmetric cryptography enables two critical functions. Authentication, the server proves its identity by demonstrating possession of the private key corresponding to the public key in its certificate. Key exchange, the browser and server use asymmetric cryptography to securely establish the symmetric session keys used for encrypting actual data.
The TLS handshake: when a browser initiates an HTTPS connection the TLS handshake establishes the encrypted session.
The browser sends a Client Hello, specifying the TLS version it supports, the cipher suites it can use, and a random value for key derivation.
The server responds with a Server Hello, selecting the TLS version and cipher suite, and presents its SSL certificate containing the server’s public key and identity information.
The browser verifies the certificate, checking that it was issued by a trusted certificate authority, that it covers the domain being connected to, and that it has not expired or been revoked.
The browser and server perform a key exchange, using the server’s public key and various cryptographic mechanisms to derive shared symmetric session keys. In modern TLS this uses Diffie-Hellman key exchange, allowing both parties to derive the same session keys without ever transmitting the keys themselves across the network.
Both parties signal readiness and the encrypted session begins, all subsequent HTTP data is encrypted with the symmetric session keys.
Symmetric encryption for data: once session keys are established the actual data transmission uses symmetric encryption, both parties use the same key to encrypt and decrypt. Symmetric encryption is much faster than asymmetric encryption, practical for encrypting the continuous stream of data in a web session. The asymmetric cryptography of the handshake is used only to securely establish the symmetric keys, combining the security of asymmetric key exchange with the performance of symmetric encryption.
Message authentication: TLS includes message authentication codes, MACs, that verify the integrity of each encrypted message. Any modification of encrypted data in transit causes the MAC verification to fail, alerting the receiver that the data was tampered with and terminating the connection. Message authentication ensures that even if an attacker intercepts the encrypted traffic they cannot modify it without detection.
SSL certificates
An SSL certificate is a digital document that binds a public key to the identity of the entity, website, organisation, or individual, that controls the domain. Issued by trusted certificate authorities SSL certificates are the mechanism through which browsers verify they are connecting to the legitimate server for a domain rather than an impostor.
Certificate contents: an SSL certificate contains the domain name, or names, the certificate is valid for, the public key associated with the domain, information about the certificate authority that issued it, the validity period, issue date and expiry date, and the certificate authority’s digital signature vouching for the certificate’s authenticity.
Certificate trust chain: browsers do not trust SSL certificates directly, they trust certificate authorities whose root certificates are embedded in the browser’s or operating system’s trust store. A certificate authority signs certificates with its own private key. When a browser verifies an SSL certificate it checks the CA’s signature, if the signature is valid and the CA is in the browser’s trust store the certificate is trusted.
Most certificates are signed by intermediate CAs rather than root CAs directly, creating a chain of trust from the root CA through one or more intermediate CAs to the end-entity certificate. The browser verifies each link in the chain up to a trusted root.
Certificate types: SSL certificates come in several types distinguished by the level of validation the certificate authority performed before issuing.
Domain Validation, DV, certificates are the most common type. The CA verifies only that the certificate requester controls the domain, through DNS-based or HTTP-based domain verification. No organisation identity information is included. Let’s Encrypt issues free DV certificates. DV certificates are appropriate for most websites including redirect management domains.
Organisation Validation, OV, certificates include verified organisation information, the CA verifies the legal existence of the requesting organisation alongside domain control. OV certificates display organisation information in the certificate details, providing additional assurance that the certificate holder is a legitimate organisation.
Extended Validation, EV, certificates undergo the most rigorous validation, the CA verifies legal existence, physical presence, and operational identity of the organisation. EV certificates historically displayed the organisation name prominently in the browser’s address bar, the green bar. Modern browsers have de-emphasised EV display making them less distinguishable from DV certificates visually.
Wildcard certificates: cover all single-level subdomains of a domain, *.example.com covers www.example.com, blog.example.com, api.example.com and any other subdomain. A single wildcard certificate provides SSL coverage for unlimited subdomains without needing individual certificates for each.
Multi-domain SAN certificates: Subject Alternative Name certificates cover multiple specific domain names in one certificate. A SAN certificate can cover example.com, www.example.com, example.net, and example.org: different registered domains, under one certificate.
SSL and redirect management
SSL is non-negotiable for correct redirect management. Every domain involved in redirect configuration, whether it is a redirect source, redirect destination, or primary domain, must have valid SSL certificates for HTTPS to work correctly throughout the redirect chain.
SSL on redirect source domains: when a visitor types or clicks https://redirect-source.com the browser must establish a TLS connection to the redirect source before receiving any HTTP response, including the redirect response. Without a valid SSL certificate on the redirect source domain the TLS handshake fails and the browser displays a certificate error. The visitor never receives the redirect, they see an error page instead.
This is the most critical SSL requirement for redirect management and the most commonly overlooked. A brand protection domain configured with a redirect rule but without SSL provisioning silently fails for all HTTPS visitors, which in modern browsing is the majority of visitors. Dedicated redirect management platforms that automatically provision SSL for all connected domains solve this problem, every domain connected to the platform gets SSL without manual configuration.
SSL on redirect destination domains: the final destination of a redirect chain must serve HTTPS correctly. A redirect that sends visitors from a secure HTTPS source to an HTTP destination undermines the security purpose of the chain and triggers browser security warnings. Redirect destinations should always be HTTPS URLs.
Certificate coverage for all redirect domain variants: redirect configurations typically handle multiple variants of a domain, HTTP and HTTPS, www and non-www. SSL certificates must cover all variants that will be accessed over HTTPS. A certificate covering only www.example.com but not example.com causes certificate errors when visitors access the root domain directly. Certificate coverage must match the full set of domains and subdomains involved in redirect configurations.
SSL certificate provisioning automation: managing SSL certificates manually for a domain portfolio, obtaining certificates, installing them on servers, tracking expiry dates, renewing before expiry, is operationally significant. Automated certificate provisioning through ACME-based systems, Let’s Encrypt with Certbot or similar clients, handles the full lifecycle automatically. Redirect management platforms that integrate automated SSL provisioning eliminate certificate management from the operational burden of managing redirect configurations.
CAA records and SSL issuance: Certification Authority Authorization records in DNS specify which certificate authorities are permitted to issue SSL certificates for a domain. Domains with CAA records that do not include the CA used by the redirect management platform will have SSL provisioning fail, the CA checks the CAA record before issuing and refuses if it is not listed. Domain owners who have configured CAA records must ensure the platform’s CA is included before connecting domains to redirect management.
SSL certificate lifecycle
SSL certificates have defined validity periods and must be renewed before expiry, an expired certificate causes the same browser errors as a missing certificate.
Certificate validity periods: Let’s Encrypt certificates are valid for 90 days, intentionally short to encourage automation and reduce the risk of compromised certificates remaining valid for long periods. Commercial certificate authorities issue certificates with validity periods of one to two years, longer periods are no longer allowed following a CA/Browser Forum decision to cap maximum validity.
Renewal timing: certificates should be renewed before they expire, at least 30 days before expiry is the recommended practice. Let’s Encrypt recommends renewal when the certificate has 30 days or less remaining. Automated renewal tools, Certbot, acme.sh, typically renew Let’s Encrypt certificates when 30 days remain, providing a comfortable buffer.
Certificate revocation: if a private key is compromised the corresponding certificate must be revoked, marked as invalid before its natural expiry. Certificate authorities maintain Certificate Revocation Lists, CRLs, and support the Online Certificate Status Protocol, OCSP, allowing browsers to check whether a certificate has been revoked. A revoked certificate causes the same browser errors as an expired one.
Certificate Transparency: all publicly trusted SSL certificates must be logged in Certificate Transparency, CT, logs. CT is a system of public logs that record every certificate issued, allowing domain owners, researchers, and security teams to monitor what certificates have been issued for their domains. Services like crt.sh provide searchable access to CT logs. Certificate Transparency monitoring detects unauthorised certificate issuance, if a certificate is issued for a domain without the owner’s knowledge the CT logs reveal it.
SSL errors and what they mean
SSL errors in browsers indicate problems with the certificate or the TLS connection, each error type points to a specific issue.
Certificate not trusted: the certificate was not issued by a certificate authority in the browser’s trust store. Common causes include self-signed certificates, generated without CA involvement, expired CA certificates, or certificates from CAs that have been removed from browser trust stores. Fix by obtaining a certificate from a trusted CA.
Certificate expired: the certificate’s validity period has ended. The domain’s SSL certificate was not renewed before its expiry date. Fix by renewing the certificate immediately. Monitor certificate expiry dates to prevent this.
Certificate name mismatch: the domain being accessed does not match any of the domain names in the certificate. Accessing example.com with a certificate valid only for www.example.com produces this error. Fix by obtaining a certificate that covers all accessed domain variants.
Certificate revoked: the certificate authority has revoked the certificate, typically because the private key was compromised. Fix by obtaining a new certificate.
Protocol or cipher suite mismatch: the browser and server cannot agree on a mutually supported TLS version or cipher suite. Modern servers should support TLS 1.2 and TLS 1.3 with standard cipher suites. Disabling older TLS versions and weak ciphers on servers requires ensuring the remaining supported options are compatible with the browsers visitors use.
Checking SSL configuration
Several tools help verify that SSL is correctly configured for a domain.
SSL Labs SSL Test: the most comprehensive free SSL analysis tool. Querying ssllabs.com/ssltest/analyze.html?d=example.com provides a detailed report on the certificate, supported TLS versions, cipher suites, and overall configuration grade. The SSL Labs test is the standard tool for identifying SSL configuration issues.
Browser certificate inspection: clicking the padlock icon in the browser address bar for an HTTPS page shows certificate information, the issuing CA, validity period, and covered domain names. This provides a quick check of certificate details without external tools.
OpenSSL command line: the openssl tool provides detailed TLS connection information:
Shows the full certificate chain, negotiated TLS version, and cipher suite.
Certificate transparency search: searching crt.sh for a domain shows all certificates that have been issued for it, including certificates issued without the domain owner’s knowledge. Regular CT monitoring is a security best practice for domains with high value or high-security requirements.