SSL/TLS Certificates

SSL/TLS certificates are one of the most important trust layers on the web. They allow websites, APIs, dashboards, login forms, checkout pages, and customer portals to use HTTPS instead of plain HTTP. When certificates are valid and installed correctly, visitors can connect securely. When certificates expire or are misconfigured, browsers may block the site, APIs may fail, and customers may see security warnings even if the server itself is online.

This guide explains SSL/TLS in practical terms for website owners, developers, system administrators, support teams, and business operators who need to keep public services secure and available.

What SSL/TLS means

People often say “SSL certificate,” but modern HTTPS uses TLS, or Transport Layer Security. SSL, or Secure Sockets Layer, was the older protocol family. SSL 2.0 and SSL 3.0 are obsolete and should not be used. In everyday hosting and website conversations, the phrase “SSL certificate” usually means a certificate used for HTTPS with modern TLS.

Why SSL/TLS certificates matter

A valid certificate does more than remove browser warnings. It helps authenticate the website, encrypt traffic, protect session cookies, secure login forms, and prevent attackers from modifying traffic between the visitor and the server. For public websites, HTTPS is now an expected baseline.

• Encryption: prevents plain-text exposure of traffic between the browser and server.
• Authentication: helps prove the browser reached the intended hostname.
• Integrity: helps prevent content from being modified in transit.
• Trust: avoids browser warnings that can damage customer confidence.
• Availability: expired or invalid certificates can make an otherwise healthy website appear down.

How HTTPS works

When a browser opens an HTTPS website, it does not immediately send normal web traffic. It first performs a TLS handshake. During that handshake, the server presents a certificate, the browser validates it, and both sides agree on secure session keys.

SSL/TLS monitoring with Spark Uptime

Spark Uptime includes SSL/TLS certificate monitoring and SSL/TLS notifications with every plan. This helps website owners avoid preventable certificate outages by detecting problems before customers do.

Common certificate types

Domain validation methods

Before issuing a certificate, a certificate authority must validate that the requester controls the domain. Automated systems usually complete this through HTTP, DNS, or TLS-based validation.

AutoSSL and free certificates

Many hosting platforms offer free SSL/TLS certificates through automated systems such as Let’s Encrypt, Sectigo AutoSSL, cPanel AutoSSL, or a provider-managed certificate service. These systems are helpful because they can issue and renew certificates without manually purchasing a certificate each year.

Free automated certificates are commonly valid for 90 days or less. That shorter lifetime is normal, but it means renewals must work reliably. If renewal automation fails, a certificate can expire quickly and create a visible outage.

Common AutoSSL failure causes

• The A record points to the wrong server.
• The domain uses an external CDN or proxy that blocks validation.
• The hostname redirects to another domain before validation completes.
• The website blocks certificate authority validation traffic.
• The domain has IPv6 AAAA records pointing somewhere different from IPv4.
• The DNS zone is hosted at a different provider than expected.
• The server has the wrong virtual host or document root for the hostname.

Certificate lifetime changes

Public TLS certificate validity periods have been getting shorter over time. Shorter lifetimes reduce the amount of time a compromised, mistakenly issued, or stale certificate can remain trusted. They also push website owners and hosting providers toward automation instead of manual annual renewals.

The CA/Browser Forum approved Ballot SC-081v3, which introduces a phased schedule reducing maximum public TLS certificate validity and domain validation reuse periods. Under that schedule, certificate validity moves to 200 days in 2026, 100 days in 2027, and 47 days in 2029. The official ballot and related Server Certificate Working Group materials are available from the CA/Browser Forum.

Let’s Encrypt has also discussed moving toward shorter certificate lifetimes and has published guidance explaining why shorter lifetimes improve the security model and encourage automation. See Let’s Encrypt’s article From 90 to 45 for their discussion of shorter certificate lifetimes.

Generating a CSR

A CSR, or Certificate Signing Request, is a file generated from a private key that asks a certificate authority to issue a certificate for specific names. Many modern AutoSSL and ACME systems generate CSRs automatically. Manual certificates may still require generating one yourself.

openssl req -new -newkey rsa:2048 -nodes \
  -keyout example.com.key \
  -out example.com.csr

For modern deployments, many administrators prefer ECDSA keys or automated ACME clients, but RSA 2048 remains widely supported. The private key file must be protected carefully. Anyone with the private key can impersonate the site if they also obtain or control a valid certificate.

CSR fields commonly requested

Certificate chains

A browser usually does not trust a website certificate by itself. It trusts a chain that leads from the server certificate through one or more intermediate certificates to a trusted root certificate. If the server fails to provide the correct intermediate certificate, some clients may reject the site even though the leaf certificate appears valid.

Server certificate
  → Intermediate certificate
    → Root certificate trusted by browser or operating system

Common chain problems

• Missing intermediate certificate.
• Wrong intermediate certificate installed.
• Expired intermediate certificate.
• Certificate served for the wrong hostname.
• Server sends certificates in the wrong order.
• Old clients do not trust the root or intermediate path being used.

TLS versions and protocol configuration

A certificate proves identity and enables secure negotiation, but TLS protocol settings determine how the secure connection is negotiated. Old TLS versions should be disabled, and modern websites should support TLS 1.2 and TLS 1.3 unless there is a specific compatibility requirement.

SSL/TLS troubleshooting checklist

1. Check the certificate dates

Confirm the certificate is currently valid and not close to expiration.

echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null | openssl x509 -noout -dates

2. Check the hostname

Confirm the certificate includes the exact hostname being used by customers.

echo | openssl s_client -servername www.example.com -connect www.example.com:443 2>/dev/null | openssl x509 -noout -subject -issuer -ext subjectAltName

3. Check the certificate chain

Verify the server sends a complete and trusted chain.

openssl s_client -connect www.example.com:443 -servername www.example.com -showcerts

4. Compare IPv4 and IPv6

If a hostname publishes both A and AAAA records, test both paths. IPv4 may serve the correct certificate while IPv6 serves an old or mismatched certificate.

5. Confirm DNS points to the expected server

Certificate problems often begin with DNS. A hostname may resolve to the wrong server, old provider, staging environment, or CDN endpoint.

Common SSL/TLS errors

SSL/TLS best practices

• Use HTTPS for every public website and application hostname.
• Enable TLS 1.2 and TLS 1.3; disable obsolete SSL and legacy TLS versions.
• Monitor certificate expiration from outside your infrastructure.
• Use automated renewal when possible.
• Confirm AutoSSL domains point to the server responsible for validation.
• Check both A and AAAA records when troubleshooting certificate warnings.
• Install the full certificate chain, not only the leaf certificate.
• Protect private keys and never send them in tickets, chats, or email.
• Use SAN certificates to cover all required hostnames.
• Document where each production certificate is issued, installed, renewed, and monitored.

RFC and standards references

These external references are useful for deeper technical reading on TLS, certificates, ACME automation, HTTPS, and certificate identity validation.