What Are SSL Certificates?
Last Updated: March 14, 2026
An SSL/TLS certificate binds a public key to a domain name (and sometimes an organization) so browsers can authenticate the server and establish an encrypted HTTPS connection. Most public-facing websites should use TLS certificates to encrypt sensitive data (for example, credentials and payment details) in transit, and many browsers and compliance regimes effectively make HTTPS mandatory for key workflows.
What is SSL?
SSL (Secure Sockets Layer) is the original protocol for securing internet connections. Although TLS (Transport Layer Security) has superseded the original SSL (Secure Sockets Layer) protocol, ‘SSL’ remains the common term for the certificates used to secure web traffic. Modern ‘SSL’ certificates are used with TLS, which encrypts traffic and uses integrity checks so intercepted data can’t be read or altered without detection.
How Do SSL Certificates Work?
SSL/TLS certificates utilize Public Key Infrastructure (PKI), which relies on two distinct cryptographic keys:
- Public Key: Embedded in the certificate; used during the TLS handshake for key exchange and server authentication.
- Private Key: Resides securely on the web server; used to decrypt the pre-master secret or prove server identity during the handshake.
When a browser connects to an HTTPS site, the TLS handshake typically works like this:
- Identification Request: The browser requests server identification.
- Certificate Transfer: The server sends a copy of its SSL certificate and public key.
- Validation & Authentication: The browser validates the certificate against its trusted root store. The server then uses its private key to sign its portion of the key exchange parameters. The browser verifies this signature, confirming the server’s identity.
- Key Exchange: The client and server perform an ephemeral key exchange (typically ECDHE). Both parties generate temporary keys and exchange the public parts, allowing them to independently compute a shared secret without ever sending it over the network. This process provides forward secrecy.
- Encrypted Session Established: Both parties use the symmetric session key to encrypt all transmitted data for the duration of the connection.
What Are SSL Certificates Used For?
In practice, SSL/TLS (using certificates) provides three core properties:
- Encryption: Converting plaintext data into ciphertext to prevent unauthorised access during transit.
- Authentication: Confirming that the server belongs to the domain owner, mitigating Man-in-the-Middle (MITM) attacks.
- Data Integrity: Ensuring that data has not been modified or corrupted during transmission via cryptographic hashing.
Why Do Websites Need an SSL Certificate?
In many cases, SSL/TLS is required or strongly expected due to browser behavior and compliance requirements:
- Browser Requirements: Modern browsers flag non-HTTPS sites as ‘Not Secure’ and implement increasingly restrictive policies: blocking mixed content, preventing access to modern web APIs, and in some cases requiring additional user confirmation for downloads or form submissions.
- Regulatory Compliance: Frameworks such as PCI-DSS, HIPAA, and GDPR mandate the encryption of data in transit.
- Search Engine Optimization (SEO): Search engines like Google use HTTPS as a minor ranking signal. More significantly, HTTPS enables modern web features (like service workers) and preserves referrer data that can indirectly benefit SEO performance.
How to Implement and Inspect SSL Certificates
Obtaining a certificate involves generating a Certificate Signing Request (CSR). On a Linux/Apache/Nginx server, you would typically use OpenSSL to generate this:
openssl req -new -newkey rsa:2048 -nodes -keyout yourdomain.key -out yourdomain.csr
How to Check SSL Certificate Expiration
Once a certificate is installed, it is critical to verify that the configuration is correct and that the validity period is what you expect. You can manually check SSL certificate expiration and inspect the live certificate details via the command line (CLI) using this command:
openssl s_client -connect yourdomain.com:443 -servername yourdomain.com | openssl x509 -noout -dates
This command connects to the server, retrieves the active certificate, and filters the output to show the notBefore (start) and notAfter (expiration) dates.
Common Implementation Pitfalls
Even with a valid certificate, your site may show “Not Secure” due to:
- Intermediate Chain Issues: If you fail to install the “CA Bundle,” the browser cannot link your certificate back to the Root CA.
- Hostname Mismatch: The certificate’s Subject Alternative Names don’t match the requested hostname (e.g., accessing store.example.com with a certificate valid only for example.com).
- Mixed Content: The page is HTTPS, but images or scripts are being loaded via insecure HTTP.
Types Of SSL Certificates
SSL certificates are categorized by two main factors: their validation level and the number of domains they secure. The validation level reflects the depth of the background check performed by the Certificate Authority (CA).
By Validation Level
Instead of just looking at definitions, use this framework to match your site’s purpose with the appropriate validation level.
If your goal is… | Use this Validation Level | Verification Depth |
|---|---|---|
Speed & Encryption Only: Personal blogs, test environments, or internal wikis. | Domain Validation (DV) | Automated check of DNS/Email. Issued in minutes. |
Brand Identity: Corporate sites, B2B SaaS, or lead-generation pages. | Organization Validation (OV) | Human review of business registry and physical address. |
Maximum Trust: E-commerce, banking, or handling sensitive PII. | Extended Validation (EV) | Rigorous legal and operational audit. Provides the highest level of assurance. |
By Domains Secured
- Single Domain SSL: Secures one fully qualified domain name (FQDN) or subdomain (e.g., example.com).
- Multi-Domain SSL (UCC/SAN): Secures multiple distinct domain names under a single certificate (e.g., com, example.org).
- Wildcard SSL: (See below for a detailed explanation).
Wildcard SSL Certificates
A Wildcard SSL certificate secures a primary domain and an unlimited number of its first-level subdomains (e.g., *.example.com) under a single certificate. This reduces the administrative overhead of managing individual certificates for high-volume environments. However, they require strict security governance; if the private key is compromised, every associated subdomain becomes vulnerable.
Self-Signed vs. CA-Signed Certificates
A self-signed certificate is exactly what it sounds like: an SSL certificate signed by the developer who created it rather than an independent, trusted public Certificate Authority. Self-signed certificates can use the same cryptographic algorithms as CA-signed certificates, but browsers don’t trust them by default and will display warnings unless the certificate is explicitly installed as trusted. Because there is no independent ‘chain of trust,’ browsers display prominent security warnings and make it more difficult (but not impossible) for users to access sites with self-signed certificates. Self-signed certificates should only be used in private, internal development environments—never in production.
Free vs. Paid SSL Certificates
Yes. Thanks to initiatives like Let’s Encrypt, securing a basic Domain Validation (DV) certificate is completely free. These free certificates use the ACME (Automated Certificate Management Environment) protocol to automatically issue and renew certificates via scripts.
While free certificates (such as those from Let’s Encrypt) provide standard encryption, they typically have a 90-day validity period. This shorter lifespan necessitates automated renewal via the ACME protocol. If automation fails, the certificate will expire, resulting in security warnings that prevent most users from accessing the site without explicitly bypassing browser protections.
What is SSL Certificate Monitoring?
While understanding how SSL works is critical, ensuring your certificates stay active and valid requires continuous oversight. SSL certificate monitoring automatically checks endpoints for certificate validity (trusted chain and hostname match), expiration thresholds, and common TLS configuration problems. Certificate monitoring checks certificate validity, expiration dates, and common configuration issues (for example, missing intermediates) on a schedule. Alerts can notify your team before expiration so you can renew or fix the chain before browsers start showing warnings.
For details, see: “What is SSL Certificate Monitoring?”
Case Study: The “Intermediate” Trap
A common issue is a site that loads in some desktop browsers but shows a certificate warning on mobile browsers. This happens because browsers have different chain-building capabilities – some can fetch missing intermediates using AIA extensions or have more comprehensive local certificate stores, while others (particularly mobile browsers) require the server to provide the complete chain. When browsers encounter the incomplete chain for the first time, they cannot validate the certificate. If your server is misconfigured to only send the leaf certificate and not the intermediate chain, mobile users will hit a “Your connection is not private” wall. Continuous monitoring detects this “incomplete chain” error immediately, even if the site looks “fine” to your internal team.
FAQ
Is monitoring the same as certificate management?
No. While a robust certificate management strategy (using tools like Let’s Encrypt or DigiCert) handles the technical issuance and renewal of certificates, monitoring is the independent verification layer. Monitoring ensures those management processes executed correctly and that the site remains accessible to users.
How often should I check my certificates?
Expiration checks should occur daily at minimum. For business-critical sites, configuration and heartbeat checks should occur every few minutes to detect sudden changes.
Do I need to monitor subdomains?
Yes. Subdomains used for APIs, staging, or internal tools are frequent points of failure and are often overlooked during manual audits.
What is Certificate Transparency (CT) monitoring?
CT monitoring tracks public logs to identify every certificate issued for your domain, helping detect “Shadow IT” or unauthorized certificate issuance.
Does SSL monitoring help with PCI-DSS or SOC2 compliance?
Yes. Automated monitoring provides the audit trail required by security frameworks to prove the maintenance of encryption standards.
Can I monitor certificates on internal networks or behind firewalls?
Yes. Private monitoring agents can be deployed to track certificates on internal APIs and employee portals that are not accessible to public scanners.