HTTPS, SSL & Security
What is an SSL certificate?
An SSL certificate, also called a TLS certificate or digital certificate, is a cryptographic credential issued by a trusted certificate authority that serves two essential purposes, verifying the identity of a website and enabling encrypted HTTPS connections between browsers and servers. The certificate binds a public cryptographic key to a specific domain name, proving that whoever controls the certificate controls the domain, and contains the information browsers need to establish a secure, authenticated connection.
When a browser connects to https://example.com the server presents its SSL certificate. The browser examines the certificate, checking that it was issued by a trusted authority, that it is valid for example.com, and that it has not expired or been revoked. If all checks pass the browser proceeds with the TLS handshake and establishes an encrypted connection. If any check fails the browser displays a certificate error warning, blocking the connection or warning the visitor that the connection cannot be trusted.
SSL certificates are the identity documents of the web, analogous to passports or driver’s licences in the physical world. Just as a passport proves identity by being issued by a trusted government authority and containing verifiable information, an SSL certificate proves domain identity by being issued by a trusted certificate authority and containing verifiable cryptographic information. The trust chain from browser to certificate authority to certificate to domain creates the foundation for secure web communication.
For redirect management SSL certificates are non-negotiable infrastructure. Every domain involved in redirect configuration, redirect source domains, redirect destination domains, primary domains, requires valid SSL certificates for HTTPS connections to work. Without SSL on a redirect source domain HTTPS visitors receive certificate errors rather than redirect responses. The certificate is the prerequisite for the redirect to function at all for the majority of modern web visitors.
What an SSL certificate contains
An SSL certificate is a structured digital document following the X.509 standard, a format defining what information certificates contain and how it is organised. Understanding certificate contents clarifies what is being verified when browsers check certificates.
Subject, the certificate holder: identifies the entity the certificate was issued to. For domain validation certificates the subject contains only the domain name. For organisation validation and extended validation certificates the subject contains organisation name, location, and other identity information alongside the domain name.
Subject Alternative Names, SANs: the list of domain names the certificate is valid for. Modern certificates use SANs as the authoritative list of covered domains, a certificate may cover multiple domains and subdomains in a single SAN list. The Common Name field was historically used for the primary domain but modern browsers use SANs exclusively for domain validation.
A certificate for example.com might have SANs including example.com and www.example.com: covering both the apex domain and www subdomain. A wildcard certificate has a SAN like *.example.com: covering all single-level subdomains. A multi-domain SAN certificate lists multiple distinct domains, example.com, example.net, example.org.
Public key: the cryptographic public key associated with the certificate. During the TLS handshake the server uses the corresponding private key to prove it legitimately controls the certificate, demonstrating that it is the authorised holder of the public key in the certificate.
Issuer, the certificate authority: identifies which certificate authority issued the certificate. The issuer field contains the CA’s distinguished name, the formal identifier of the CA in X.509 format. Browsers use this to find the CA’s certificate in the trust chain and verify the CA’s signature on the certificate.
Validity period: the date range during which the certificate is valid, the not-before and not-after dates. Certificates presented before the not-before date or after the not-after date are considered invalid. Modern certificates have validity periods of 90 days, for Let’s Encrypt: to one to two years for commercial certificates.
Serial number: a unique identifier assigned by the certificate authority to each certificate it issues. Used to identify specific certificates in revocation databases and certificate transparency logs.
Certificate authority signature: the CA’s cryptographic signature over the certificate contents. The signature is created with the CA’s private key and can be verified by anyone with access to the CA’s public key, which browsers have through the CA’s certificate in their trust store. The signature proves the certificate was genuinely issued by the CA and has not been tampered with.
Certificate transparency log references, SCTs: Signed Certificate Timestamps from certificate transparency logs. Modern certificates must be submitted to CT logs before issuance, the SCTs embedded in the certificate prove that the certificate is publicly logged. Browsers require SCTs as part of certificate trust evaluation.
Types of SSL certificates
SSL certificates come in several types, distinguished by the scope of identity verification the certificate authority performed and the domains they cover.
Domain Validation, DV certificates: the most common and most accessible certificate type. To issue a DV certificate the certificate authority verifies only that the requester controls the domain, through DNS-based or HTTP-based domain verification challenges. No organisation identity information is verified or included. DV certificates are available for free through Let’s Encrypt and are the appropriate choice for the vast majority of websites and redirect management use cases.
DV certificates provide full encryption and domain authentication, they prove the server controls the domain. They do not provide organisation identity information, the certificate does not confirm who owns the domain beyond the fact of DNS or HTTP control.
Organisation Validation, OV certificates: the CA verifies both domain control and the legal existence and identity of the requesting organisation. OV certificates include organisation name, country, and state in the certificate subject. Browsers do not typically display OV information prominently, it is visible in certificate details but not in the address bar. OV certificates are appropriate for organisations that want to include verified identity information in their certificates.
Extended Validation, EV certificates: the most rigorous validation level. The CA verifies legal existence, physical address, operational status, and legal authority of the requesting organisation, a more thorough process than OV. EV certificates historically triggered a prominent green address bar display in browsers. Modern browsers have removed this visual distinction, EV certificates look identical to DV certificates in the address bar. The practical differentiation of EV has diminished significantly as a result.
Wildcard certificates: cover a domain and all its single-level subdomains, *.example.com covers www.example.com, blog.example.com, api.example.com and any other subdomain. A single wildcard certificate provides coverage for unlimited subdomains without requiring individual certificates for each. Wildcard certificates are available in DV, OV, and EV validation levels.
Wildcard certificates have one important limitation, they cover only single-level subdomains. *.example.com covers shop.example.com but not app.shop.example.com. The apex domain, example.com: is also not covered by a wildcard certificate unless explicitly added as a SAN.
Multi-domain SAN 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. Multi-domain SAN certificates are useful for organisations managing multiple domains that should share a certificate, particularly for redirect management portfolios where multiple source domains can be covered by one certificate.
Self-signed certificates: generated without CA involvement, the certificate is signed by its own private key rather than by a trusted CA. Browsers do not trust self-signed certificates, they display prominent certificate error warnings for any site using one. Self-signed certificates are appropriate only for internal development environments where browsers can be configured to trust the self-signed certificate manually. They should never be used on public-facing websites or redirect infrastructure.
Certificate authorities
Certificate authorities are the organisations trusted to verify domain ownership and organisation identity before issuing certificates. Browsers maintain trust stores, lists of trusted root CA certificates, embedded in the browser or operating system. Certificates issued by CAs in the trust store are automatically trusted. Certificates from unknown CAs trigger warnings.
Let’s Encrypt: a non-profit certificate authority that provides free, automated DV certificates through the ACME protocol. Let’s Encrypt has transformed SSL certificate deployment, making free certificates available to anyone with a domain and an ACME-compatible client. Let’s Encrypt issues 90-day certificates through automated renewal, the short validity period encourages automation and reduces the risk of compromised certificates remaining valid long-term. Most redirect management platforms use Let’s Encrypt for automated certificate provisioning.
Commercial certificate authorities: DigiCert, Sectigo, GlobalSign, Entrust, and others charge for certificates but offer OV and EV certificates with organisation identity verification, longer validity periods, and additional services like warranty coverage and dedicated support. Commercial CAs are appropriate for organisations requiring OV or EV validation.
Cloud provider CAs: major cloud providers including AWS Certificate Manager, Google-managed SSL, and Cloudflare operate their own certificate infrastructure or partner with CAs to provide certificates for resources on their platforms. AWS Certificate Manager provides free certificates for use with AWS services. Cloudflare provisions certificates automatically for all domains using its proxy service.
Trust store management: the set of trusted root CAs is managed by browser vendors, Google for Chrome, Mozilla for Firefox, Apple for Safari, and by operating system vendors, Microsoft for Windows, Apple for macOS and iOS. CAs must meet strict requirements to be included in trust stores, including auditing requirements, policy compliance, and incident response standards. CAs that fail to meet these requirements can be removed from trust stores, immediately causing all their certificates to trigger browser errors.
SSL certificate lifecycle
SSL certificates have defined validity periods and require renewal before expiry. Understanding the certificate lifecycle prevents the most common SSL failure, expired certificates.
Certificate issuance: the certificate request begins with generating a key pair, a private key kept secret on the server and a public key included in the certificate request. The certificate signing request, CSR, contains the public key and the domain names to be covered. The CSR is submitted to the CA, either through a manual interface or automated ACME protocol. The CA performs domain validation and issues the certificate.
Installation: the issued certificate is installed on the web server alongside the private key. The server is configured to present the certificate during TLS handshakes. The full certificate chain, including intermediate CA certificates connecting the end-entity certificate to the trusted root, must be included in the server configuration for browsers to verify the trust chain.
Renewal: certificates must be renewed before their expiry date. For Let’s Encrypt certificates renewal is recommended when 30 days or less remain, the automated renewal tools attempt renewal at this threshold. For commercial certificates with longer validity periods renewal is typically initiated 30 to 60 days before expiry.
Automated renewal through ACME clients, Certbot, acme.sh, and others, handles Let’s Encrypt renewal without manual intervention. The client performs domain validation, obtains a new certificate, installs it, and reloads the web server, all automatically on a scheduled basis.
Revocation: if a certificate’s private key is compromised the certificate should be revoked, marked as invalid before its natural expiry. The CA maintains a Certificate Revocation List and OCSP responder that browsers can check to determine if a certificate has been revoked. Certificate revocation notifies browsers that the certificate should no longer be trusted even though it has not expired.
Expiry consequences: an expired certificate triggers the same browser errors as a missing certificate, visitors see a full-screen warning that the connection is not private. For redirect management domains with expired certificates HTTPS visitors cannot reach the redirect response, they see the certificate error page instead. Certificate expiry monitoring, alerting when certificates approach expiry, prevents this failure mode.
SSL certificates and redirect management
SSL certificates are prerequisite infrastructure for redirect management, every domain in a redirect configuration requires valid certificate coverage.
Every source domain needs SSL: the most commonly overlooked SSL requirement in redirect management. A domain configured as a redirect source must have a valid SSL certificate for HTTPS connections to succeed before the redirect response is served. Common failure scenarios include brand protection domains registered and configured with redirect rules but without SSL, HTTPS visitors see certificate errors rather than being redirected. Legacy domains maintained as redirect sources but with expired certificates, visitors who follow HTTPS links to the old domain encounter errors rather than being redirected to the new domain.
Automated SSL provisioning: managing SSL certificates for redirect domain portfolios, potentially dozens or hundreds of source domains, requires automation. Manually obtaining, installing, and renewing certificates for each domain is not scalable. Dedicated redirect management platforms integrate automated SSL provisioning, connecting a domain to the platform triggers automatic certificate issuance through Let’s Encrypt or another ACME-compatible CA. Certificates are renewed automatically before expiry. No manual certificate management is required.
CAA records and certificate issuance: domains with CAA records that restrict certificate issuance to specific CAs must include the CA used by the redirect management platform. If the platform uses Let’s Encrypt, as most do, the domain’s CAA records must include letsencrypt.org in both issue and issuewild records. Missing CAA record configuration blocks certificate provisioning, causing redirect setup to fail or SSL coverage to be absent on connected domains.
Certificate coverage for all domain variants: redirect configurations handle multiple URL variants, HTTP and HTTPS, www and non-www. SSL certificates must cover all variants accessed over HTTPS. A certificate covering only www.example.com but not example.com leaves the apex domain uncovered, HTTPS visitors to the apex receive certificate errors before the redirect fires. Multi-domain SAN certificates or separate certificates for each variant ensure complete coverage.
Checking SSL certificates
Several tools verify SSL certificate configuration, confirming validity, coverage, and correct installation.
Browser certificate inspection: clicking the padlock icon in the browser address bar shows certificate information, the issuing CA, validity period, and SANs. Quick and accessible, appropriate for basic confirmation that a certificate is present and valid.
SSL Labs SSL Test: comprehensive analysis at ssllabs.com/ssltest: provides certificate chain validation, expiry date, SAN coverage, and configuration grading. The standard tool for thorough SSL configuration assessment.
OpenSSL certificate inspection:
Shows the full certificate details, SANs, validity period, issuer, and all certificate fields, from the command line.
Certificate expiry monitoring: services including UptimeRobot, Uptime Kuma, and dedicated certificate monitoring services check certificate expiry dates and alert when certificates approach expiry. Essential for redirect domain portfolios where certificate expiry would silently break HTTPS redirects.
Certificate transparency monitoring: crt.sh provides a searchable interface to certificate transparency logs, showing all certificates issued for a domain. Regular monitoring detects unauthorised certificate issuance and confirms that expected certificates have been logged correctly.