A certificate authority checks before it signs for a website. It confirms that the web address really belongs to the organisation asking for the certificate. The UK’s security agency adds that an authority should confirm the request is genuine and allowed. Your browser then leans on that work every time it shows a padlock.

A close-up of a browser address bar showing a green padlock beside https.
more
HTTPS BrowserLicence: CC BY 2.0

That ownership check is where the trust comes from. When you accept a site’s certificate, you are relying on the authority to have checked the organisation’s identity on your behalf, as the US Cybersecurity and Infrastructure Security Agency (CISA) puts it.

What the padlock is standing in for

Any organisation that wants its website to encrypt traffic needs a site certificate, which CISA also calls a host certificate. Two signs tell you a page uses one. A closed padlock appears near the address bar, and the address starts with “https:” rather than “http:”.

A valid certificate means an authority has taken steps to confirm that the address belongs to the organisation named on it. That is the promise. The padlock is only the badge that shows it.

Who is allowed to ask

The UK’s National Cyber Security Centre (NCSC) describes the authority as the trusted part of a public key infrastructure. When it issues a certificate, it is vouching that whoever holds the matching public key also owns the private key.

To give that assurance, the authority has to be confident about two people. One is the requester. The other is the approver, which the NCSC calls the registration authority. The NCSC suggests a mutual TLS connection for this, or another strong method such as a central identity provider.

Its stated aim is that every request reaching the authority gets checked for identity and for permission.

What a requester may ask for

Proving who you are is not the end of it. Once authenticated, a requester should get only the certificates relevant to its role, according to the NCSC.

Its example is a web server. A server that has logged in to the authority should be able to ask only for a certificate fit for TLS, the protocol behind encrypted web traffic.

Why no single person holds the keys

The NCSC wants the people who run the system kept apart. It recommends segregation of duty, with role-based access so each administrator reaches only their own part. Running separate authorities for separate jobs helps with that too, it says.

The riskiest requests get a second check. Signing a certificate for an intermediate authority, which happens when an authority is renewed or newly installed, should bring in a second factor or a second person.

What your browser checks after that

The authority’s checks happen once, when the certificate is issued. Your browser runs its own checks on every visit. It confirms that the address you reached matches the one on the certificate. It also confirms that an authority it treats as trusted signed it.

If something is wrong, you may see a warning about the site certificate. CISA lists three usual causes:

  • the name on the certificate does not match the site
  • you chose not to trust the company that issued it
  • the certificate has expired

Expiry dates carry their own clue. CISA says most site certificates last one or two years, and it advises caution about any valid for longer. An authority’s own certificate is the exception and can run to ten years, because it is so widely distributed.

The catch in the chain

Your browser ships with a list of more than 100 trusted authorities. Trusting the padlock means trusting every one of them to do its checks properly.

They do not all check with equal rigour. CISA warns that authorities vary in how strictly they validate requests and how well they protect their data. The only way to be certain, it says, is to confirm the certificate’s fingerprint by calling the organisation yourself.

Few people will ever make that call. CISA’s advice is to hold back personal details whenever you doubt a certificate.