Skip to content
DomainVigil
Sign up

Reference guide

What is a certificate chain?

A certificate never stands alone. Another certificate signs it, a third signs that one, and so on up to a root your system already knows. When a link is missing, the site works for you and fails for the client.

7 min readUpdated September 12, 2026

In short

A certificate chain is the run of certificates linking your site's certificate to an authority the visitor's system trusts. It has at least three links: the site certificate, an intermediate certificate from the authority, and a root certificate already installed in the browser or operating system. Your server sends the first two; it does not send the third.

Why there is a chain rather than a certificate

A visitor's browser does not know your site and has no reason to trust it. What it does know in advance is a hundred or so authorities, whose root certificates ship with the operating system. The whole of HTTPS security comes down to walking your certificate up to one of those roots through a run of signatures.

Authorities never sign directly with their root. That key is too precious: it stays offline, in a vault, and only ever signs intermediate certificates. The intermediates issue the millions of site certificates day to day. If one is compromised, it gets revoked without touching the root or breaking trust for everybody.

That design explains the commonest incident in the trade: your server has to send not just its own certificate but the intermediates linking it to the root. Plenty of configurations send only the first. Desktop browsers can often cover for the missing link by fetching it themselves; mobile apps and command-line clients cannot.

The chain, from the site certificate to the root

Three links, and one traffic rule: the server sends the ones at the bottom, the visitor already holds the one at the top.

  1. 1

    The site certificate

    Issued for your domain names, valid for a few months, signed by an intermediate. This is the one you install and renew.

    issued for example.com and www.example.com

  2. 2

    The intermediate certificate

    It belongs to the certificate authority and signs thousands of site certificates. Valid for several years, and your server has to send it alongside yours.

  3. 3

    The root certificate

    Self-signed, and the end of the line. The server never sends it: it is already in the trust store of the visitor's system or browser.

  4. 4

    What the server transmits

    The site certificate, then the intermediates, in order. Leave the root out — sending it adds nothing and weighs down every connection.

  5. 5

    What the visitor checks

    It walks the chain signature by signature until it finds a root it knows. Along the way it checks the dates, the names covered and the revocation status of every link.

The links, and what breaks when one is missing

Each link has its own issuer, its own home and its own failure mode. The right-hand column is how you recognize a symptom.

LinkWho issues itWhere it livesWhat breaks without it
Site certificateThe authority, via an intermediate.On your server.No secure access at all. The browser shows a full-page warning.
IntermediateThe authority's root.On your server, sent with the site certificate.The sneakiest failure of the lot: the site works in desktop browsers and fails on mobile, in apps, and in server-to-server calls.
RootItself: it is self-signed.In the trust store of the visitor's system.The authority is not recognized and the certificate is refused. This happens on older devices that no longer receive updates.
Cross-signatureA second, usually older root.Sent by the server as well, where one exists.Nothing on recent hardware. On older hardware, this link is the difference between a reachable site and a refused one.
Private keyYou, at the time of the request.On your server, and never transmitted.The certificate becomes unusable: it proves an identity the server can no longer back up.

Check your own domain, right now

Enter a domain name: the tool reads its certificate, its issuing authority, its expiry date and the names it covers.

No sign-up, no email required. You can paste a full address — we'll pull the domain out of it.

The schedule for shorter certificate lifetimes

The industry sets the maximum lifetime of a site certificate, not the authority issuing it. It shrinks in steps that are already dated, and each step makes manual renewal a little less tenable.

FromMaximum lifetimeWhat it implies
today200 daysTwo renewals a year. Miss one and you pay in hours of total site downtime.
15 March 2027100 daysAround four renewals a year. A manual calendar becomes a source of incidents in its own right.
15 March 202947 daysAround eight renewals a year. Nothing manual survives that pace.

Before 15 March 2026 the maximum was 398 days — one renewal a year. That is the rhythm many internal procedures were written around, and have not yet moved off.

The four chain failures

  • The site works on desktop and not on mobile

    What causes it: The chain is incomplete: the server sends only the site certificate. Desktop browsers go and fetch the missing intermediate, other clients give up.

    What fixes it: Install the full chain file supplied by the authority. Test from a tool with no certificate cache, never from the browser that has already visited the site.

  • The certificate expired without warning

    What causes it: Automatic renewal stopped — a CAA record gone stale, a firewall rule, a failed scheduled job — and nobody was watching the date.

    What fixes it: Restart the renewal and watch the date from outside. With lifetimes shrinking, a note in a calendar no longer counts as a check.

  • The certificate does not cover the requested name

    What causes it: The certificate was issued for www.example.com only, and the visitor arrives at example.com — or the other way round. And a wildcard does not cover the root domain.

    What fixes it: Request a certificate listing every name served. Check the list of covered names, not the expiry date alone.

  • The authority changed its intermediate

    What causes it: The server keeps sending the old chain file, which no longer matches the renewed certificate.

    What fixes it: Redeploy the chain supplied with the new certificate. Automated setups do it on their own; manual installations keep the old file for ever.

The questions that come next

Should the root certificate be sent with the others?

No. The visitor already has it, otherwise nothing would work anyway. Sending it weighs down every connection for no benefit, and the standard explicitly allows omitting it.

How do I check that my chain is complete?

From an outside tool that opens a fresh connection without reusing a cache. A browser that has already visited the site may have cached the missing intermediate, and will show you a perfectly valid site that is not valid for a new visitor.

Does a wildcard certificate cover the domain itself?

No. A wildcard covers names one level down, not the root domain and not deeper levels. The domain itself has to be listed alongside the wildcard.

What happens when a root certificate expires?

Up-to-date devices already hold the replacement root and see nothing. Devices that no longer receive updates flatly refuse sites that worked the day before — an outage that does not come from your server and cannot be fixed there.

An incomplete chain is invisible from your own browser

It is the failure you hear about from a client who cannot pay, or from an integration that refuses to connect. DomainVigil checks the chain and the expiry date of the certificate on every domain you own, from outside, every day.

Start for free

Five domains free, forever. No card required.

The other reference guides