Every website with a padlock in the address bar is quietly relying on a small bundle of data most business owners have never looked at. Understanding the parts of an SSL certificate is not just a technical curiosity; it is what lets you work out why a certificate has failed, whether the one you have bought is the one you actually need, and what your web developer is talking about when they mention “the chain”.

We say this to clients all the time: you do not need to be able to build a certificate, but you should be able to read one.

A certificate is really just a signed identity document

An SSL certificate (technically a TLS certificate these days, though almost everyone still says SSL) does two jobs at once. It proves that your website is who it claims to be, and it hands the visitor’s browser the key material needed to encrypt the conversation that follows.

Think of it as a passport. The passport contains details about the holder, it contains security features that are hard to forge, and it is issued by an authority that other people already trust. Take away the trusted issuer and the document is just a nicely printed booklet.

The parts of an SSL certificate, one by one

• Subject: who the certificate is for. At minimum this is a domain name, and for higher-assurance certificates it also includes the legal company name and location.
• Common Name and Subject Alternative Names: the exact hostnames the certificate covers, such as yourbusiness.co.uk and www.yourbusiness.co.uk. Modern browsers care about the SAN list, which is why a certificate can secure several names at once.
• Issuer: the certificate authority that signed it, for example Let’s Encrypt, Sectigo or DigiCert.
• Validity period: the not-before and not-after dates. Certificates are deliberately short-lived now, often 90 days, which is why automated renewal matters so much.
• Public key: the half of the key pair that the browser uses to start an encrypted session. The matching private key never leaves your server, and never should.
• Signature algorithm and signature: the maths proving the certificate authority really did sign this document and that nobody has altered it since.
• Serial number and fingerprint: unique identifiers, useful when you need to revoke a certificate or check that the one installed is the one you expect.
• Extensions: extra instructions, including what the certificate may be used for and where to check whether it has been revoked.

The chain is the part that breaks most often

A certificate is rarely signed directly by the certificate authority’s most protected key. Instead, there is a chain: your certificate is signed by an intermediate certificate, and that intermediate is signed by a root certificate which is already trusted by every browser and operating system.

Your server must serve your certificate and the intermediate together. Miss the intermediate out and something maddening happens: the site works perfectly in your desktop browser (which may have cached the intermediate from another site) and throws security warnings on a customer’s phone. If you have ever had someone insist your site is broken while it looks fine on your screen, an incomplete chain is one of the usual suspects.

How to inspect a certificate yourself

Step 1: Click the padlock

In any browser, click the padlock next to the address and choose the option to view the connection or certificate details. This is the fastest route to the subject, issuer and expiry date.

Step 2: Read the three things that matter

Check that the name matches your domain exactly, that the issuer is who you expect, and that the expiry date is comfortably in the future.

Step 3: Check the chain

Expand the certification path. You should see your certificate, at least one intermediate, and a root. If the chain stops early, the installation is incomplete.

Step 4: Test from outside your own machine

Use an online SSL checker, or simply load the site on mobile data with a phone you have never used to visit it. This bypasses anything cached locally and shows you what a real customer sees.

Step 5: Confirm renewal is automated

Find out what renews the certificate, and confirm it is running. Expiry is by far the most common cause of an SSL emergency, and it is entirely preventable.

Certificate types compared

• Domain Validated (DV): proves control of the domain and nothing more. Issued in minutes, usually free, and perfectly adequate for most small business websites and blogs.
• Organisation Validated (OV): the certificate authority checks your company exists. The company details appear inside the certificate, which some corporate buyers like to see.
• Extended Validation (EV): the most thorough vetting of your legal identity. Browsers no longer give it a green bar, so its practical marketing value has largely gone, though it still carries weight in some regulated sectors.
• Wildcard: covers a domain and all of its subdomains, which is handy if you run shop, blog and app on the same domain.
• Multi-domain (SAN): covers several different domains on one certificate, useful if you own multiple brand names.

For the overwhelming majority of small businesses, a well-installed DV certificate with automatic renewal beats an expensive certificate that nobody remembers to renew.

Best practices worth adopting

• Automate renewal: if a human has to remember it, it will eventually be forgotten, usually on a bank holiday.
• Protect the private key: it should never be emailed, never be committed to a code repository, and never leave the server.
• Serve the full chain: test on mobile, not just on the machine you built the site on.
• Redirect HTTP to HTTPS: a certificate that exists but is not enforced does very little.
• Fix mixed content: one image loaded over plain HTTP will strip the padlock from an otherwise secure page.
• Monitor expiry independently: a simple uptime service that watches your certificate costs nothing and saves a very bad morning.

A padlock is not decoration; it is the price of entry.

Common mistakes we see all the time

• Buying an expensive certificate for a brochure site: the encryption is identical. You are paying for identity vetting, not stronger security.
• Installing the certificate but not the intermediate: the classic half-installation that only shows up on customers’ phones.
• Covering yourbusiness.co.uk but not www.yourbusiness.co.uk: both names need to be on the certificate.
• Forgetting subdomains: shop, mail and staging all need coverage if they are public.
• Letting renewal depend on one person’s inbox: when they leave, the certificate leaves with them.
• Ignoring the warning emails: thirty days of notice is plenty, right up until it is not.

Where certificates are heading

The direction is shorter lifetimes and more automation. Certificate validity has already fallen dramatically, and the industry is steadily pushing it lower, on the reasonable logic that a stolen certificate is less dangerous if it expires quickly. That only works if issuance and renewal are fully automated, which is why tools that handle this silently in the background have become standard rather than clever.

Longer term, there is serious work underway on post-quantum cryptography, preparing for a day when today’s algorithms are no longer safe. That is not something a small business needs to act on now, but it is a good reason to be on managed hosting that keeps up with these changes for you.

Your SSL certificate checklist

• Check the expiry date today, and note what renews it.
• Confirm both www and non-www versions are covered.
• Test the full chain using an external checker or a mobile connection.
• Force HTTPS with a site-wide redirect.
• Hunt down mixed content so the padlock stays intact on every page.
• Set an independent expiry alert that does not rely on one person.
• Store the private key securely and know who has access to it.

Who issues certificates, and why trust flows downhill

Certificate authorities exist because trust has to start somewhere. Your operating system and browser ship with a list of root certificates they already trust, curated by the people who build them. Everything else inherits trust from those roots, one signature at a time.

This is why you cannot simply generate your own certificate and expect the world to accept it. You can, technically, and it will encrypt traffic perfectly well; but no browser has ever heard of you, so every visitor gets a warning. Self-signed certificates have their place on internal systems and development environments, and no place at all on a customer-facing website.

It is also why revocation exists. If a private key is stolen, the certificate authority can publish the fact that a specific serial number should no longer be trusted, and browsers can check that list before completing a connection. Revocation is imperfect in practice, which is another argument for short-lived certificates: expiry is a blunt but extremely reliable safety net.

What a certificate does not do

A padlock proves the connection is encrypted and that the domain is what it claims to be. It does not prove the business behind the domain is honest, competent or even real. Phishing sites routinely have perfectly valid certificates, because getting a DV certificate for a domain you control takes minutes and costs nothing.

So by all means reassure customers that their data travels securely to your site, but do not lean on the padlock as a trust signal in your marketing. Real trust comes from clear pricing, honest copy, visible reviews, a proper address and a phone number that a human answers. The certificate is the floor, not the ceiling.

What happens if my SSL certificate expires?

Browsers show a full-page security warning, and most visitors will leave immediately. Search engines are unimpressed too. The fix is quick once you know, but the damage happens in the hours before anyone notices, which is exactly why automated renewal and monitoring matter.

Is a free certificate less secure than a paid one?

No. The encryption is the same. What you buy with a paid certificate is a higher level of identity verification, a warranty, and sometimes support. For a typical small business site, a free automated certificate is genuinely fine.

Why does my site show as insecure even though I have a certificate?

Usually one of three things: the certificate does not cover the exact hostname being used, the intermediate certificate is missing, or the page is loading images or scripts over plain HTTP. All three are fixable in an afternoon.

Do I need a wildcard certificate?

Only if you run several subdomains. If your site is one domain with www, a standard certificate covering both names is all you need, and it will be cheaper and simpler to manage.

Can I move a certificate to a new server?

Yes, if you have the private key as well as the certificate. In practice it is often easier to issue a fresh certificate on the new server, especially where issuance is automated, and it avoids moving a private key around.

Let us take the padlock off your to-do list

If reading about the parts of an SSL certificate has left you wondering whether yours is set up properly, that is a perfectly sensible instinct, and it is exactly the sort of thing we check when we take on a website. From hosting and security to the design and content that persuades people to get in touch, we look after the whole thing so you can get back to running your business. Contact Us for a straight-talking review of your website and hosting.