What Is an SSL Certificate, and What Does It Actually Protect?

01

The browser warning arrived before the support alert

Imagine a customer portal that has worked quietly for years. Staff use it to share documents, customers use it to check progress and the certificate renews automatically. Then, at 9.04 on a Monday morning, customers start seeing a warning that their connection is not private.

The application is still running. The database is healthy. Nobody has changed the code. The problem is that the certificate presented by one public endpoint has expired, so browsers no longer trust the connection.

Support calls begin before the technical team sees an alert. Customers do not know whether the problem is an expired certificate, a fake website or a cyber attack. They only know the browser has told them to stop.

Installing a replacement certificate restores service, but it does not answer the more important questions. Why did renewal fail? Which server still held the old certificate? Who owned the alert? Which other domains depend on the same process?

That is the useful business context for understanding SSL certificates. The technology is straightforward. Keeping the trust relationship working across hosting, domains and changing infrastructure is the operational job.

02

SSL is the familiar name, but modern websites use TLS

People still say SSL certificate because the phrase has become familiar. Modern secure web connections use Transport Layer Security, or TLS. SSL was the earlier protocol and its old versions should not be used.

The certificate itself is a digital credential. It connects a domain name to a public key and carries a signature from a certificate authority that browsers are configured to trust.

When a website uses HTTPS, HTTP traffic travels inside the protected TLS connection. The certificate helps the browser authenticate the server and establish that secure session. It is therefore reasonable to describe it as an SSL certificate in everyday conversation, even though TLS is the accurate name for the protocol doing the work.

The terminology matters less than the outcome. A customer opening the portal should reach the intended domain through an encrypted connection without having to ignore a warning or understand cryptography.

03

What information is inside the certificate?

A public website certificate normally contains the domain names it covers, the public key, the organisation that issued it, its validity dates and the certificate authority's digital signature. It can also include information describing its permitted uses and the chain needed to reach a trusted root certificate.

The private key is not placed inside the public certificate. It must stay protected on the server, hosting platform, load balancer or secure key service that uses it. The public certificate can be sent to every browser. The private key is the sensitive proof that the server controls the certified key pair.

This distinction is important during a handover. A copy of the certificate file is not necessarily enough to operate the service. The business also needs to know where the private key is held, how a replacement certificate is requested and which systems terminate the TLS connection.

04

What happens when a browser opens an HTTPS page?

Before the application sends a login page or customer record, the browser and server perform a TLS handshake. They agree a supported version of TLS and suitable cryptographic methods. The server presents its certificate and proves it controls the corresponding private key.

The browser checks that the requested hostname appears on the certificate, that the certificate is within its valid dates and that the signatures form a chain to a certificate authority the browser trusts. It also checks whether the certificate is suitable for the intended server use.

If those checks succeed, the browser and server establish temporary session keys. Those faster keys protect the HTTP headers and content that move during the rest of the connection. Modern TLS does not use the certificate's public key to encrypt every page, image and form submission directly.

If a check fails, the browser warns or blocks the user. That reaction is deliberately disruptive. Quietly continuing would remove the identity check that helps protect customers from an impostor or a connection that cannot be trusted.

05

HTTPS protects three useful things in transit

TLS gives a web connection three related protections: confidentiality, integrity and authentication. Together they stop an ordinary network observer reading or silently changing traffic while helping the browser confirm which server it reached.

That covers information moving between the browser and the HTTPS endpoint. The boundary matters. If a content delivery network or load balancer receives the public connection, the traffic may then make another connection to the origin application. That second connection needs its own secure configuration rather than being assumed safe because the customer saw HTTPS.

06

A valid certificate does not make the whole application secure

The browser padlock answers a narrow question about the connection. It does not review the application behind it.

A website can have a perfectly valid certificate and still contain weak passwords, broken access controls, vulnerable dependencies, malicious downloads or a convincing phishing page. An attacker can obtain a certificate for a domain they legitimately control and then use that domain for dishonest activity.

HTTPS also does not protect information after it reaches either end of the connection. Malware on a customer device can read what the user sees. A compromised server can expose data after decryption. A staff member with excessive access can still export records. Backups, logging, authentication, authorisation, patching and secure development remain necessary.

Treat the certificate as one control in the security design. It is essential for public web software, but it is not a security assessment or a guarantee about the organisation operating the site.

07

Certificate errors usually point to ordinary operational gaps

An expired certificate is the best known failure, but it is not the only one. A certificate may cover www.example.com but not portal.example.com. A server may send the end certificate without the intermediate certificates the browser needs to build its trust chain. A load balancer may keep serving an older file after another server was updated.

Dates can fail when a system clock is badly wrong. A self-signed certificate may encrypt a connection but still trigger a warning because public browsers do not trust the signer. A page delivered over HTTPS can also load scripts, images or fonts over plain HTTP, creating mixed content that browsers may upgrade or block.

• The certificate has expired or is not valid yet.
• The requested hostname is missing from the certificate.
• The server is presenting the wrong certificate for the domain.
• An intermediate certificate is missing or misconfigured.
• A CDN, load balancer or secondary server still has the old certificate.
• The application loads insecure HTTP resources inside an HTTPS page.
• The browser does not trust a private or self-signed issuer.

These are rarely fixed by buying a more expensive certificate. They are fixed by knowing which names the service uses, configuring the complete chain, protecting keys, deploying consistently and testing the endpoint that customers actually reach.

08

Free certificates changed the cost, not the responsibility

A public TLS certificate no longer needs to be a large annual purchase. Certificate authorities such as Let's Encrypt issue free certificates, while many hosting platforms and content delivery networks manage certificates as part of the service.

The ACME protocol allows software to prove control of a domain, request a certificate and repeat the process for renewal without a person completing the same manual steps. That is a significant improvement because routine certificate work is safer when it is repeatable.

Automation is not the same as assurance. A renewal job can report success while the new certificate is stored on the wrong machine, a deployment fails or one forgotten endpoint continues presenting the old certificate. The useful check is the certificate and TLS configuration seen from outside the live service.

Monitor the public website, customer portal and APIs separately. Alert before expiry and send the warning to an owned team route rather than one developer's inbox. After renewal, confirm the live endpoint presents the new certificate and the complete chain.

09

The public edge and the application origin may be different connections

Many business applications sit behind a CDN, reverse proxy, web application firewall or cloud load balancer. The customer's TLS connection can end at that public edge rather than on the application server itself.

That is not inherently a problem. These services can manage certificates well and protect the origin from direct traffic. The risk appears when the next connection, from the edge to the origin, is poorly understood or left unencrypted.

Document both sides. Record which platform owns the public certificate, how it validates the domain and how traffic reaches the origin. Use TLS to the origin with proper certificate validation where the architecture supports it. Do not rely on a mode that encrypts only the customer-facing part while sending sensitive information across an unprotected internal or public route.

During an application takeover, this is one of the places where assumptions hide. The domain, DNS, CDN, hosting service and origin certificate may all be controlled through different accounts. A working padlock today does not prove the business can renew or recreate the route tomorrow.

10

Make certificate ownership boring and visible

Return to the customer portal that failed on Monday morning. The useful repair is not only a fresh certificate. The business records every public hostname, the platform that terminates TLS, the issuer, the renewal method and the accountable owner. Monitoring checks the live endpoint and alerts a shared support route before customers see a warning.

The team also confirms that HTTP redirects to HTTPS, the application does not load mixed content and traffic from the public edge to the origin is protected. Private keys stay in managed secret or certificate services rather than source code repositories and shared folders.

Nobody needs to remember the renewal date because automation handles the routine work. Somebody still owns the result, investigates a failed check and can replace or revoke a certificate when the infrastructure changes.

That is the right role for an SSL certificate in business software. It quietly supports identity, encrypted traffic and customer trust. It becomes visible only when the lifecycle around it has been neglected.

I help businesses review inherited applications, hosting, domains and integrations before taking responsibility for them. If nobody can explain where certificates terminate, how they renew or who controls the DNS needed to replace them, an application takeover review can turn those assumptions into a usable ownership map.