What Does a Website Security Certificate Actually Prove?

When a browser opens a website using HTTPS, it does more than encrypt the connection. It also has to decide whether the website presenting the certificate is genuinely entitled to identify itself as the domain shown in the address bar.

To make that decision, the browser checks the website’s TLS certificate, the Certificate Authority that issued it, the chain of certificates leading back to a root certificate the browser already trusts, and details such as the domain name and certificate validity period. If those checks succeed, the browser can establish an authenticated and encrypted HTTPS connection.

This guide follows that process from beginning to end. It explains what a website certificate contains, what Certificate Authorities do, why browsers and operating systems maintain collections of trusted root certificates, how intermediate certificates create a chain of trust, what causes certificate warnings, and why organisations can sometimes add their own trusted certificates for managed HTTPS inspection.

Most importantly, it explains the limit of that trust. A valid certificate can help establish that the browser has made a protected connection to the domain represented by the certificate. It does not establish that everything on the website is safe, that the organisation behind it is reputable, or that files, links and instructions provided by the site can automatically be trusted.

Understanding that distinction also makes related controls such as DNSSEC, browser security, VPNs and Certificate Authority Authorization easier to understand.

Use the links below to jump to the sections most relevant to your question.

• What is a website security certificate?
• What happens when your browser connects to an HTTPS website?
• How does the browser decide whether to trust the certificate?
• What is the certificate chain?
• What does a valid certificate actually prove?
• What does a certificate not prove?
• Why might a browser show a certificate warning?
• Can a trusted Certificate Authority stop being trusted?
• Why can security systems sometimes inspect HTTPS traffic?
• How do DNS, HTTPS and certificates fit together?
• What controls who can issue certificates for a domain?
• What should people take from the browser’s HTTPS indication?
• Related guidance on this site
• Further Guidance and Support

A website security certificate is more accurately called a TLS certificate. TLS stands for Transport Layer Security, the technology used by HTTPS to protect communications between a browser and a website.

The certificate contains information that allows the browser to associate a public cryptographic key with one or more domain names. The website holds the corresponding private key.

The certificate is digitally signed by a Certificate Authority, usually through one or more intermediate certificates. This gives the browser a way to determine whether it should trust the certificate presented by the website rather than simply accepting whatever certificate a server chooses to provide.

This is important because encryption on its own is not enough. A browser also needs a way to establish that it is encrypting the connection to the intended domain.

Consider someone entering:

https://example.org

The connection involves several separate mechanisms.

First, the device normally uses DNS to determine which IP address it should contact for example.org.

The browser then begins a TLS connection with the server. As part of that process, the server presents its certificate and normally the intermediate certificates needed to establish its trust chain.

The browser then performs a series of checks. These include whether the certificate is valid for the requested hostname, whether it is within its permitted validity period, and whether the browser can establish an acceptable chain to a Certificate Authority it trusts.

The server must also demonstrate that it controls the private key corresponding to the public key represented by the certificate.

If the required checks succeed, the browser and server establish encryption keys for the session and the HTTPS connection can continue.

A simplified sequence is therefore:

Domain name → DNS lookup → server connection → TLS certificate → certificate validation → encrypted HTTPS session

Each part solves a different problem.

Browsers do not simply trust a certificate because a website presents one. The browser needs an independent basis for deciding whether that certificate should be accepted.

Browsers and operating systems therefore have access to collections of trusted root certificates. These collections are commonly called a root store or trust store.

A root certificate represents a Certificate Authority that the browser, operating system or device has been configured to trust for particular purposes. The website does not get to decide which roots are trusted. That decision comes from the trust policies used by the browser, operating system or, in some managed environments, the organisation controlling the device.

This creates an important starting point:

The website presents evidence of its identity, but the browser decides whether that evidence leads back to something it already trusts.

When a website presents its TLS certificate, the browser normally does not expect that website certificate to have been signed directly by one of those root certificates. Instead, it tries to build a chain from the website certificate through one or more intermediate Certificate Authorities until it reaches a trusted root.

A simplified example is:

Website certificate
www.example.org

↓ signed by

Intermediate Certificate Authority

↓ ultimately authorised by

Trusted Root Certificate Authority

↓ already trusted by

Browser or operating system

The browser verifies the cryptographic relationships between the certificates rather than merely recognising their names.

It also checks other important information. For example:

• • Is the certificate valid for the domain being requested?
  • Is the certificate within its permitted validity period?
  • Is it authorised for the purpose for which it is being used?
  • Can an acceptable certificate chain be built to a root that the browser or device trusts?
  • Can the server demonstrate that it possesses the private key associated with the certificate?

If those checks succeed, the browser has a basis for accepting the certificate and continuing with the protected HTTPS connection.

If the chain stops at a certificate the browser does not trust, the hostname is wrong, the certificate is outside its validity period or another required check fails, the normal trust decision may fail and the browser can show a certificate warning.

The important idea is therefore not simply:

“This website has a certificate.”

It is:

“This website has presented a certificate for this domain, and the browser can validate that certificate through a chain that ultimately leads to a root certificate it already trusts.”

That is the mechanism behind the browser’s certificate trust decision.

Once the browser has established which root certificates it trusts, it still needs to connect the website certificate it has been presented with to one of those trusted roots. The linked sequence of certificates used to do this is commonly called the certificate chain.

A simplified chain can be viewed in two directions.

Starting with the website, the browser may validate:

Website certificate
↓ signed by
Intermediate Certificate Authority
↓ authorised through
Trusted Root Certificate Authority

Looking from the trust hierarchy down towards the website, the roles are:

Trusted Root Certificate Authority
↓ delegates certificate issuing authority to
Intermediate Certificate Authority
↓ signs
Website certificate

Each level has a different purpose.

The root certificate sits at the top of the trust hierarchy. It is important because the browser or operating system has already been configured to trust it. Root Certificate Authority private keys are therefore particularly sensitive and are normally subject to strong controls rather than being used routinely to issue individual website certificates.

The intermediate Certificate Authority operates between the trusted root and the website certificate. It receives delegated authority that allows it to issue or sign certificates within the limits applied to it. Using intermediates means that the root certificate and its private key do not need to be used for ordinary day-to-day website certificate issuance.

The website certificate, sometimes called the leaf certificate or end entity certificate, is associated with the website being visited. It contains information including the domain names for which it is valid and the public key used as part of the TLS connection.

The website normally provides its own certificate and the intermediate certificates needed to help the browser build the chain. The trusted root certificate itself will normally already be available through the browser or operating system’s trust store rather than needing to be trusted simply because the website sends it.

The browser checks the cryptographic signatures and relevant restrictions that connect the certificates. It is not simply comparing their names or assuming that one certificate is trustworthy because another certificate appears beside it.

A valid chain therefore allows the browser to establish a relationship from the website certificate back to a root certificate it already trusts. If an intermediate certificate is missing, a signature cannot be validated, the chain leads to an untrusted root, or another required certificate check fails, the browser may be unable to accept the chain normally.

The exact chain can vary between certificate providers and configurations, and some chains may contain more than one intermediate certificate. The important principle remains the same: the website certificate must be capable of being validated through an acceptable chain that leads back to a root the browser or device trusts.

For an ordinary public HTTPS connection, a valid certificate gives the browser several important pieces of evidence.

It helps establish that:

• • the certificate is valid for the domain name being requested;
  • the certificate falls within its permitted validity period;
  • the certificate can be linked through an acceptable chain to a trusted Certificate Authority;
  • and the server can use the private key associated with that certificate during the TLS connection.

This allows the browser to create an authenticated and encrypted connection to the domain represented by the certificate.

That is valuable. Without this authentication step, a browser could encrypt information while still sending it to the wrong server.

For many ordinary public certificates, the validation process is principally concerned with control of the relevant domain name. It should not be interpreted as a general assessment of the organisation, people, products or information behind the website.

Some certificate types can contain additional organisation identity information, but that still does not turn the certificate into a general statement that the website is safe or reputable.

This is the part that is most frequently misunderstood.

A valid HTTPS certificate does not prove that:

• • the website owner is honest;
  • the business is financially sound;
  • the website has not been compromised;
  • everything displayed on the site is accurate;
  • files offered for download are safe;
  • scripts running on the website are harmless;
  • links from the website lead to safe destinations;
  • the domain name itself is the intended destination;
  • or the organisation follows good cybersecurity practices elsewhere.

A fraudulent website can obtain a valid certificate for a domain legitimately controlled by the fraudster.

For example:

example-bank-login.co.uk

could potentially have a perfectly valid certificate for that exact domain.

The certificate could correctly establish:

This encrypted connection is to example-bank-login.co.uk.

It would not establish:

example-bank-login.co.uk is your bank.

The domain name remains important.

HTTPS protects the connection. It does not make an untrustworthy destination trustworthy.

A certificate warning means that the browser cannot complete one or more of the checks required for the connection in the expected way.

Examples can include:

The certificate has expired

Certificates are issued for defined validity periods. A certificate outside that period should not normally be accepted as a normal trusted public connection.

The hostname does not match

A certificate issued for one domain should not automatically be accepted for an unrelated domain.

For example, a certificate valid only for:

www.example.org

cannot simply be assumed to be valid for:

different-example.org

The certificate chain cannot be trusted

The browser may be unable to build an acceptable chain to a root it trusts.

The certificate or issuing authority is no longer accepted

Trust policies can change. Browsers and operating systems can stop trusting a Certificate Authority or particular certificate chain where necessary.

A certificate warning should not simply be bypassed because the website looks familiar or appears to be genuine.

The warning may be caused by a configuration problem, but it may also mean that the browser cannot establish the certificate trust expected for the connection.

Yes.

Certificate trust is not permanent simply because a Certificate Authority was trusted in the past.

Browser and operating system vendors maintain rules governing which root Certificate Authorities are accepted in their trust stores. A CA may be required to meet technical, operational and security requirements to remain trusted.

If serious problems occur, a browser vendor can restrict or remove trust in a CA or particular certificate hierarchy.

That demonstrates an important feature of the system:

Website certificate trust is not based only on cryptography. It also depends on governance of the Certificate Authorities that browsers choose to trust.

The browser’s trust store is therefore an active part of the security model rather than a permanent list that never changes.

There is another situation that helps demonstrate how certificate trust works.

Some organisations use security products, web gateways or filtering systems that inspect HTTPS traffic on managed computers.

To do this, the organisation may install its own trusted root certificate on those devices.

The security system can then establish one encrypted connection to the external website and a separate encrypted connection to the managed computer. It presents the computer with a locally generated certificate that chains back to the organisation’s trusted root.

Because the organisation’s root has deliberately been added to the device’s trust store, the browser can treat that locally generated certificate as trusted.

This does not mean the public website’s original certificate has changed.

It demonstrates something important about certificate trust:

A browser can trust a certificate chain only when that chain ultimately leads to a root certificate the browser or device is configured to trust.

On an ordinary unmanaged device, that will normally involve the roots accepted through the browser or operating system’s trust system. On a managed business computer, an organisation may deliberately add an additional trusted root for purposes such as HTTPS inspection.

This is why two devices can potentially treat the same locally generated certificate differently: one device may have been deliberately configured to trust the organisation’s root certificate while another has not.

This type of TLS inspection should therefore be intentional, controlled and appropriate to the organisation’s environment. It also creates operational and privacy considerations because the inspecting system can see traffic that would otherwise remain encrypted between the browser and the destination website.

DNS and TLS certificates protect different parts of a connection.

DNS normally helps the device determine where a domain name should be reached.

HTTPS then protects the communication between the browser and the website and uses the TLS certificate as part of authenticating that connection.

This distinction matters when considering attacks involving manipulated DNS.

If a device is incorrectly directed towards an attacker-controlled server, the attacker still needs to satisfy the browser’s certificate requirements for the domain being requested. Simply controlling the IP address returned by DNS does not automatically provide a valid certificate for the legitimate domain.

DNSSEC adds another control by allowing signed DNS information to be validated. It is therefore concerned with the integrity and authenticity of DNS information rather than replacing TLS certificates.

The controls complement each other:

DNSSEC helps validate DNS information.

TLS certificates help authenticate and encrypt the subsequent HTTPS connection.

Neither control replaces the other.

The certificate trust process answers:

Should the browser trust the certificate it has been presented?

There is a related but different question:

Which Certificate Authorities should be allowed to issue certificates for this domain in the first place?

DNS has a mechanism called Certification Authority Authorization, or CAA, which allows a domain owner to publish information about which public Certificate Authorities are permitted to issue certificates for that domain.

CAA therefore concerns certificate issuance, not the strength of HTTPS encryption or the browser’s normal certificate-chain validation process.

It is useful to keep these mechanisms separate.

This guide concentrates on browser trust and what a website certificate proves. CAA requires its own explanation because restricting certificate issuance needs to take account of legitimate certificate providers, hosting platforms, CDNs and automated certificate renewal.

The most useful interpretation of a normal HTTPS connection is quite specific.

It means the browser has been able to establish the certificate and encryption conditions it requires for that domain and connection.

It is reasonable to take from this:

My browser has established a protected connection to the domain shown in the address bar.

It is not reasonable to extend that to:

My browser has confirmed that everything associated with this website is trustworthy.

Before entering sensitive information, downloading software or following financial instructions, the domain name and wider context still matter.

HTTPS is an essential security control, but it is one part of a layered model.

Browser certificate requirements, Certificate Authority policies and browser trust decisions can change over time. The examples in this guide should therefore be understood as an explanation of the underlying trust model rather than a permanent checklist of browser behaviour, and certificate configurations should be reviewed where an organisation manages its own websites, certificates or security controls.

Several other Evening Computing guides cover controls that operate before, alongside or after certificate validation.

Why DNSSEC matters and how DNS attacks can redirect internet traffic

Explains how DNS information can be manipulated and how DNSSEC helps validate signed DNS responses.

How to improve browser security in Chrome and other browsers

Explains wider browser protections and why browser security involves more than the HTTPS connection itself.

What does a VPN protect you from, and does it slow down your internet?

Explains how VPN encryption differs from HTTPS and why the two technologies solve different problems.

Can Websites in Google Search Results Still Be Dangerous?

Explains why appearing in a search engine does not establish that a website itself is safe.