How SSL Certificates Work and Why They Matter for Trust

Every time someone visits a website whose address begins with https, an SSL certificate is quietly doing its job.

It proves to the visitor's browser that the site really belongs to the domain it claims to be, and it allows the browser and the server to set up an encrypted connection, so that passwords, payment details and personal information cannot be read or altered by anyone in between. Without a valid certificate, modern browsers warn visitors that a site is "Not secure", and many people simply leave.

For businesses, certificates are now a basic requirement rather than an optional extra. They protect customers' data, support compliance with data protection and payment security rules, avoid browser warnings that damage confidence, and form part of the technical foundation that search engines expect. They are also often free and can be renewed automatically. Yet certificate problems still cause real outages, including at large organisations, usually because a certificate expired unnoticed or was configured incorrectly.

This guide explains, in plain language, what SSL certificates are, how they work, what they do and do not protect against, the different types available, why they matter for trust and business, how the rules around them are changing and how to manage them so they never become the cause of an embarrassing outage.

SSL, TLS and what a certificate actually is

SSL is the old name; TLS is what is actually used

SSL stands for Secure Sockets Layer, a protocol developed in the 1990s to encrypt connections between browsers and websites. It was replaced by Transport Layer Security (TLS), and all versions of SSL are now considered insecure and have been formally deprecated by the Internet Engineering Task Force. Older versions of TLS, 1.0 and 1.1, have also been deprecated. Today, secure websites use TLS 1.2 or TLS 1.3, the latest version, published in 2018.

The name "SSL certificate" has stuck, so most hosting providers and certificate sellers still use it. Technically, these are TLS certificates, or simply digital certificates, and they work with whichever version of TLS the server and browser agree to use. When you see https at the start of a web address, the "s" means the connection is protected by TLS.

What a certificate contains

A certificate is a small data file installed on a web server. It contains the domain name or names it covers, information about the organisation that owns it if it has been verified, the public half of a cryptographic key pair, the dates it is valid from and until, and the digital signature of the certificate authority that issued it.

The matching private key stays secret on the server. The public key can be shared with anyone. Data encrypted or signed with one key can be checked or decrypted with the other, which is what allows browsers to verify a website and set up a secure connection without ever sending the secret key across the internet.

Who issues certificates

Certificates are issued by certificate authorities (CAs), organisations that verify that the applicant controls the domain and, for some types of certificate, that the organisation behind it exists. Browsers and operating systems include a list of trusted root certificate authorities. If a certificate can be traced back to one of those trusted roots, the browser accepts it. Rules for how certificate authorities operate are set largely by the CA/Browser Forum, an industry body that includes certificate authorities and browser makers such as Google, Apple, Mozilla and Microsoft.

How it works: the handshake and the chain of trust

You do not need to understand the mathematics to understand what happens when a browser connects to a secure website. The process happens in a fraction of a second, usually before the page starts to load.

The TLS handshake in plain terms

When someone visits a secure site, the browser and the server first exchange a short series of messages, known as the handshake. The browser says which versions of TLS and which encryption methods it supports. The server replies with its choice and sends its certificate. The browser then checks the certificate: that it has not expired, that it covers the domain being visited, that it was issued by a trusted certificate authority and that it has not been revoked. If everything checks out, the browser and server use the public key information to agree on fresh, temporary encryption keys for this session only. From then on, everything they send to each other, including passwords, form data and cookies, is encrypted with those session keys.

If any check fails, the browser shows a warning, often a full-page message telling the user the connection is not private. Most visitors will not click past it.

TLS 1.3 streamlined this process, cutting the number of back-and-forth messages needed to set up a connection and removing older, weaker encryption options. That makes connections both faster and more secure.

The chain of trust

Browsers do not trust a website's certificate on its own. They trust it because it was signed by an intermediate certificate authority, which was in turn signed by a root certificate authority that the browser or operating system already trusts. This is called the chain of trust. Root certificates are kept highly secure, often offline, and intermediates handle day-to-day issuing. If the chain is incomplete, for example because a server was configured without the intermediate certificate, some browsers and devices will reject the connection even though the site's own certificate is valid.

Keeping certificate authorities honest

Because trust rests on certificate authorities, the system includes safeguards. Certificate Transparency requires publicly trusted certificates to be recorded in public logs, so that mistakenly or maliciously issued certificates can be spotted. Browser makers also monitor certificate authorities and can remove their trust if serious problems emerge, as Google Chrome did with Symantec's certificates in 2018 and announced for new certificates from Entrust in 2024.

What HTTPS protects, and what it does not

Certificates provide important protections, but they are often misunderstood. Knowing their limits matters as much as knowing their benefits, both for businesses and for the customers they serve.

What it protects

HTTPS provides three things. Confidentiality: data travelling between the browser and the server is encrypted, so people on the same Wi-Fi network, internet providers or attackers in between cannot read passwords, card details, messages or form submissions. Integrity: the data cannot be secretly altered in transit, for example by injecting adverts or malicious code into a page. Authentication of the domain: the browser has confirmed that it is talking to a server that controls the domain in the address bar, not an impostor intercepting the connection.

What it does not protect

A certificate does not mean that a website is honest, safe or legitimate. It only confirms that the connection is encrypted and that the site controls its domain. Criminals can obtain certificates for phishing sites as easily as anyone else, and anti-phishing organisations such as the Anti-Phishing Working Group have reported that a large majority of phishing sites now use HTTPS. A site called secure-yourbank-login.com can have a perfectly valid certificate.

HTTPS also does not protect data once it reaches the server. If a website's database is breached, its software is vulnerable or its staff are tricked into handing over access, encryption in transit offers no protection. Nor does it protect against malware on a user's own device.

The padlock problem

For years, browsers showed a padlock next to secure addresses. Research and browser makers found that many people interpreted the padlock as meaning a site was trustworthy, rather than simply that the connection was encrypted. In 2023, Google Chrome replaced the padlock with a neutral settings-style icon, explaining that the padlock had become misleading now that almost all sites use HTTPS. Instead, Chrome focuses on warning users when a connection is not secure.

For businesses, the lesson is that HTTPS is a baseline expectation, not a mark of distinction. Its absence damages trust, but its presence alone does not create it. Trust also depends on a clear identity, good security practices and honest communication.

Types of certificate and how to choose

Certificates vary in two main ways: how much the certificate authority checks before issuing them, and how many domains they cover. All of them provide the same strength of encryption.

Validation levels

Domain Validated (DV) certificates confirm only that the applicant controls the domain, usually by placing a file on the website, adding a DNS record or responding to an email. They can be issued in minutes, often automatically, and are the most common type. Organisation Validated (OV) certificates add checks that the organisation named in the certificate exists, and include its name in the certificate details. Extended Validation (EV) certificates involve the most thorough checks of the organisation's legal identity and existence.

EV certificates were once displayed prominently, with the company's name shown in green in the address bar. Major browsers removed this display around 2019, after research suggested that users did not notice or rely on it as intended. The organisation details are still available if a user clicks to view the certificate, but most visitors never do. For most websites, a DV certificate now provides the same visible result in the browser. OV or EV certificates may still be useful where customers, partners or procurement processes specifically ask for them, or where an organisation wants its verified identity embedded in the certificate.

Coverage

A single-domain certificate covers one name, such as www.example.com, usually along with the bare domain example.com. A wildcard certificate covers a domain and all its subdomains at one level, such as shop.example.com and help.example.com. A multi-domain certificate, sometimes called a SAN certificate, covers several different names in one certificate. Wildcards are convenient but mean that one private key protects many services, so the key must be guarded carefully.

Type

What is checked

Typical use

Domain Validated

Control of the domain

Most websites, blogs, small business sites, online shops

Organisation Validated

Domain plus organisation details

Business sites where verified identity in the certificate is wanted

Extended Validation

Domain plus thorough legal identity checks

Organisations whose customers or partners specifically require it

Free or paid?

Let's Encrypt, a non-profit certificate authority that began issuing certificates to the public in 2015 and 2016, provides free DV certificates through an automated process and now secures a very large share of websites. Many hosting providers and content delivery networks also include free certificates. Paid certificates can make sense when you need OV or EV validation, particular warranties, support arrangements or features required by enterprise policies. For most small and mid-sized business websites, a free, automatically renewed DV certificate is entirely appropriate.

Why certificates matter for business

Almost all web traffic is now encrypted. Google's Transparency Report has shown for several years that the large majority of pages loaded in Chrome use HTTPS. A site without a valid certificate therefore stands out, and not in a good way.

Avoiding browser warnings

Since 2018, Google Chrome has labelled pages loaded over plain HTTP as "Not secure", and other browsers show similar warnings, particularly on pages with forms. If a certificate has expired, does not match the domain or cannot be verified, browsers display a full-page warning that most visitors will not click through. For a business, that can mean lost sales, abandoned enquiries and damage to reputation within minutes.

Search visibility

Google announced in 2014 that HTTPS would be used as a lightweight ranking signal. It is not a major factor on its own, but it forms part of the page experience Google expects, and browser warnings on insecure pages can increase the number of visitors who leave immediately.

Protecting customer data and meeting obligations

Data protection laws such as the UK GDPR and EU GDPR require organisations to protect personal data with appropriate technical and organisational measures, and encryption is specifically mentioned as an example. Sending personal information over an unencrypted connection would be difficult to justify. If you accept card payments, the Payment Card Industry Data Security Standard requires strong cryptography to protect cardholder data sent over open, public networks. Sector regulators and enterprise customers often expect encryption in transit as a minimum.

Enabling modern web features

Many modern browser capabilities only work on secure connections, including service workers used by progressive web apps, geolocation, camera and microphone access and some performance features. A site without HTTPS will find itself unable to use them.

Protecting more than the website

Certificates also secure email servers, APIs, mobile app back ends, internal tools, customer portals and connections between services. An expired certificate on an API can break a mobile app or an integration just as surely as one on a website, often without the public-facing site showing any sign of a problem.

Shorter certificate lifespans and why automation matters

One of the most important changes for anyone managing websites is that certificates are being issued for shorter and shorter periods. That makes manual renewal increasingly impractical.

How lifespans have shrunk

Publicly trusted certificates were once available with validity periods of several years. Over time, browser makers and certificate authorities have reduced the maximum. Since September 2020, the maximum has been 398 days, roughly 13 months, after Apple announced it would stop trusting longer certificates and other browsers followed.

In April 2025, the CA/Browser Forum approved a further reduction, proposed by Apple, to take place in stages: a maximum of 200 days from March 2026, 100 days from March 2027 and 47 days from March 2029. The time for which certificate authorities can reuse earlier domain validation checks is also being cut sharply. Check the current rules, but the direction is clear: certificates will need renewing many times a year.

Why the industry is doing this

Shorter lifespans limit the damage if a private key is stolen or a certificate is issued wrongly, because the certificate expires sooner. They also make sure certificates reflect current information about domain ownership, and they push organisations towards automation, which makes it easier to respond quickly when the whole industry needs to replace certificates, for example after a security problem with a certificate authority.

Automate renewal

With 47-day certificates, manually renewing through a web form and copying files to servers simply will not be sustainable. The standard solution is the ACME protocol, originally developed for Let's Encrypt and now widely supported by certificate authorities, which allows servers to request, validate and install certificates automatically. Many hosting platforms, content delivery networks, load balancers and cloud providers handle certificates automatically for the domains they serve. Cloud services such as AWS Certificate Manager can issue and renew certificates for supported services without manual intervention.

If any of your certificates are still renewed by hand, now is the time to move them to automated renewal, or to platforms that manage certificates for you.

Common certificate problems and how to avoid them

Certificate problems are rarely caused by weak encryption. They are almost always operational: something expired, was configured incorrectly or was forgotten.

Expired certificates

Expiry is the most common and most avoidable problem, and it affects large organisations as well as small ones. In February 2020, Microsoft Teams suffered an outage that the company attributed to an expired authentication certificate. In December 2018, an expired certificate in software supplied by Ericsson disrupted mobile data services for millions of customers of networks including O2 in the UK and SoftBank in Japan. In both cases, the underlying technology worked; someone simply had not renewed a certificate in time.

Automated renewal, monitoring that alerts well before expiry and a complete inventory of certificates are the main defences.

Name mismatch

A certificate is only valid for the names it lists. If a site is reached at example.com but the certificate only covers www.example.com, or a new subdomain is added without updating the certificate, browsers will show an error. Check that every hostname customers and systems use is covered.

Incomplete chain

If a server sends its own certificate but not the intermediate certificate, some browsers and many apps and devices will reject the connection, even though it may work on the developer's own computer. Online testing tools can quickly show whether the chain is complete.

Mixed content

A page loaded over HTTPS may still pull in images, scripts or styles over plain HTTP. Browsers block much of this mixed content or show warnings, and it can break pages or undermine security. After moving a site to HTTPS, update all internal links and resources, and use redirects so that HTTP requests are sent to HTTPS.

Outdated protocols and settings

Servers that still allow old versions of SSL or TLS 1.0 and 1.1, or weak encryption settings, may fail security scans, compliance checks or customer security questionnaires. Configure servers to support TLS 1.2 and TLS 1.3, and use recommended settings from your platform or a trusted guide such as Mozilla's server configuration recommendations.

Exposed private keys

If a private key is copied into a code repository, shared by email or left on an old server, anyone who obtains it could impersonate the site. Store keys securely, limit who can access them and revoke and replace certificates if a key may have been exposed.

Certificate authority distrust

Occasionally, browsers stop trusting a certificate authority because of serious compliance failures. Businesses using certificates from that authority must replace them before the deadline. Keep an eye on announcements from your certificate provider and browser makers, and make sure you could switch providers quickly if needed.

Best practices for managing certificates

Good certificate management is mostly about routine and visibility. These practices prevent nearly all of the problems described above.

Know what you have

Keep an inventory of every certificate your business depends on: websites, subdomains, APIs, email servers, load balancers, customer portals, internal tools and third-party services that use your domains. Record which provider issued each one, when it expires, how it is renewed and who is responsible. Certificate Transparency search tools can help find certificates issued for your domains that you may not know about.

Automate renewal and monitor expiry

Use automated issuance and renewal wherever possible, through ACME clients, your hosting platform or your cloud provider. Even with automation, set up independent monitoring that alerts a named person or team well before any certificate expires, because automated renewals can fail silently if a configuration changes.

Use HTTPS everywhere

Serve every page over HTTPS, redirect all HTTP requests to HTTPS and fix mixed content. Consider enabling HTTP Strict Transport Security (HSTS), which tells browsers to always use HTTPS for your site, preventing certain downgrade attacks. HSTS preloading, which builds this instruction into browsers, offers stronger protection but is hard to reverse, so only use it once you are confident that every subdomain supports HTTPS.

Configure servers securely

Support TLS 1.2 and TLS 1.3, disable older protocols and weak encryption settings and keep server software up to date. Free online tools, such as Qualys SSL Labs' server test, can check your configuration and highlight problems.

Control who can issue certificates for your domains

A DNS record called CAA (Certification Authority Authorization) lets you specify which certificate authorities are allowed to issue certificates for your domain. It is a simple way to reduce the risk of certificates being issued by an authority you do not use.

Protect private keys

Keep private keys on the servers or services that need them, restrict access, never store them in code repositories or shared folders and replace certificates promptly if a key may have been exposed. Many cloud services and load balancers manage keys for you, which reduces the risk of mishandling.

Assign ownership

Certificates often fall between teams: marketing owns the website, IT owns the email server, a supplier hosts the customer portal. Make it clear who is responsible for each certificate and for responding to alerts.

Certificates are a small part of website security, but they have an outsized effect on whether customers trust your site and whether services stay online. If you are unsure how many certificates your business relies on, or whether they are renewed automatically, an experienced cloud and security partner can audit your certificates, automate renewal and monitoring, and harden your server configuration as part of a broader approach to website security and performance.