What is CA (Certificate Authority)?

A Certificate Authority (CA) is a trusted organisation or system that verifies an identity and issues a digitally signed certificate linking that identity to a public key. In the public Web PKI, browsers and operating systems trust selected root CAs, allowing them to validate certificates presented by websites. A CA is therefore part of the trust system behind HTTPS and TLS, but it does not encrypt your internet connection by itself.

The key distinction is simple: the certificate contains identity information and a public key, while the CA signs the certificate to vouch for the binding it has validated. The corresponding private key remains with the certificate holder and must be protected.

What does a Certificate Authority do?

A CA sits inside a Public Key Infrastructure and performs controlled certificate lifecycle functions. The exact validation and issuance rules depend on the certificate type and trust ecosystem.

• Validates the information required by the relevant certificate policy, such as control of a domain name for a publicly trusted TLS certificate.

• Issues a digital certificate containing the subject information, public key and other certificate fields.

• Digitally signs the certificate using a CA private key so relying parties can verify who issued it and whether the certificate has been altered.

• Publishes or supports status information used to determine whether certificates have been revoked.

• Operates under policies, security controls and audit requirements appropriate to the trust ecosystem.

How does a CA work?

For a typical public website certificate, the trust process can be reduced to a sequence, although the real Web PKI includes additional policy, logging, validation and operational controls.

1. A website operator generates or controls a cryptographic key pair and requests a certificate.

2. The CA validates the required information, commonly control of the requested domain name.

3. The CA creates and digitally signs the certificate.

4. The server presents its certificate and usually the required intermediate certificate or certificates during the TLS handshake.

5. The browser builds a certification path towards a root CA it already trusts, then validates signatures, names, validity and other certificate requirements.

6. If the checks succeed, TLS can continue and establish protected session keys for the encrypted connection.

Root CA, intermediate CA and end-entity certificate

Public CAs normally use a hierarchy rather than signing every website certificate directly with a root key.

• Root CA: the trust anchor. Its root certificate is distributed through browser, operating system or application trust programmes.

• Intermediate CA: a subordinate CA whose certificate is signed by a root CA or another intermediate CA. It can issue certificates within its permitted constraints.

• End-entity certificate: the certificate issued to the website, service, person, device or other subject. It is not normally permitted to issue further certificates.

Keeping root CA private keys highly protected and using intermediate CAs for day-to-day issuance limits the exposure of the root trust anchor.

What is inside a digital certificate?

For public TLS, certificates are X.509 version 3. A certificate can contain the subject public key, issuer, serial number, validity period, signature algorithm and extensions that define names and permitted uses. For modern website certificates, the Subject Alternative Name extension identifies the DNS names or IP addresses covered by the certificate.

• The public key associated with the certificate holder.

• The issuer that signed the certificate.

• A validity period with not-before and not-after times.

• A serial number unique within the issuer's scope.

• Extensions such as Subject Alternative Name, Key Usage, Extended Key Usage and Basic Constraints where applicable.

• A digital signature created by the issuing CA.

A certificate does not contain the matching private key. If a private key is exposed, the certificate may need to be revoked and replaced.

Public CA vs private CA

A public CA and a private CA can use similar cryptographic concepts, but the trust distribution is different.

• Public CA: intended for certificates that must be trusted by unrelated users on the public internet. Trust depends on the relevant root being accepted by browser, operating system or application trust programmes.

• Private CA: operated for a controlled environment such as an organisation. Managed devices must be configured to trust the organisation's private root CA.

• Self-signed certificate: signed by its own private key rather than by a separate issuing CA. It is not automatically trusted merely because it is cryptographically valid.

Certificate Authority vs PKI

A CA is one component of Public Key Infrastructure (PKI). PKI is the broader system of keys, certificates, authorities, policies, validation, issuance, renewal, revocation, trust stores and operational controls.

Certificate Authority vs authentication

A CA supports authentication by creating verifiable bindings between public keys and validated identities or identifiers. For a domain-validated public TLS certificate, the central check is control of the relevant domain, not a broad endorsement of the organisation behind the website.

Does a CA encrypt your traffic?

No. The CA establishes certificate trust. Encryption of an HTTPS session is performed by TLS between the endpoints. The certificate and its key material help authenticate the server and support the handshake, while symmetric session keys are then used to protect application traffic.

How browsers decide whether to trust a CA

Browsers and operating systems maintain trust stores or root programmes. Public root inclusion is not automatic. CA operators must meet the policies of the relevant software supplier and, for publicly trusted TLS certificates, industry requirements such as the CA/Browser Forum Baseline Requirements. A root trusted by one platform is not guaranteed to be trusted by every possible client.

What happens when a CA or certificate is not trusted?

If a browser cannot build and validate an acceptable path to a trusted root, the user can receive a certificate warning and the connection may be blocked or require an explicit exception.

• Missing or incorrect intermediate certificate.

• Hostname does not match the certificate.

• Certificate has expired or is not yet valid.

• Root CA is not trusted by the client.

• Certificate has been revoked or fails relevant status checks.

• System clock is significantly wrong.

• Certificate or chain violates client security policy.

Certificate revocation and expiry

Certificates are deliberately time-limited. A CA can also revoke a certificate before expiry, for example after a private-key compromise or certain issuance problems. Revocation information can be distributed using mechanisms such as Certificate Revocation Lists and the Online Certificate Status Protocol, although client behaviour and ecosystem implementation vary.

Why certificate automation matters

Certificate lifetimes and validation reuse periods are becoming shorter in the public Web PKI. Automated issuance and renewal, inventory, expiry monitoring and controlled key handling reduce the chance of an avoidable outage caused by an expired or missing certificate.

Techie Broadband practical trust check

When diagnosing a certificate warning, separate the network connection from the identity and trust checks. A working broadband connection does not mean a certificate is valid, and a certificate error does not necessarily mean the broadband line is faulty.

1. Confirm the device date, time and time zone are correct.

2. Check the exact hostname in the browser against the certificate names.

3. Inspect the certificate issuer and validity dates.

4. Check whether the server is presenting the required intermediate chain.

5. Test from another current browser or operating system to identify a client-specific trust-store issue.

6. For an internal service, confirm the private root CA has been deliberately deployed to the managed client.

7. If you operate the service, check renewal automation, certificate inventory and revocation status before replacing components at random.

Common Certificate Authority misconceptions

• A padlock does not mean a website is honest. It means the browser established a protected connection to a name covered by a certificate it accepted.

• A CA does not normally hold the website's private key. The certificate contains the public key; the private key must remain controlled and protected by its owner or authorised key-management service.

• HTTPS does not mean the CA is encrypting every packet. TLS performs the session encryption.

• A private CA is not inherently inferior. It is appropriate where the organisation controls which clients should trust it.

• A self-signed certificate is not automatically insecure, but clients need a deliberate way to establish trust.

Frequently asked questions

What does CA stand for in networking?

CA stands for Certificate Authority. It is an authority that issues digitally signed certificates used to establish trust in public-key systems.

Is a Certificate Authority the same as an SSL certificate?

No. The CA is the issuer or trust authority. The certificate is the signed data object issued to a website or other subject. The older term SSL certificate is commonly used for a TLS server certificate.

Can anyone become a Certificate Authority?

Anyone can technically create a private CA, but that does not make it publicly trusted. Public trust requires acceptance into relevant browser or operating system root programmes and compliance with their policies and applicable industry requirements.

Does a CA know my private key?

Normally, no. The certificate request process is designed so the certificate holder can prove possession of the corresponding private key without giving that private key to the CA.

What is the difference between a root CA and an intermediate CA?

A root CA is the trust anchor. An intermediate CA is signed by a root or another intermediate and performs delegated certificate issuance, reducing routine exposure of the root key.

Why does my browser say a certificate is not trusted?

Common causes include an unknown root CA, a missing intermediate, an expired certificate, a hostname mismatch, a revoked certificate, an incorrect device clock or a certificate chain that violates client policy.

Key takeaway

A Certificate Authority is a trust issuer, not the encryption itself. It validates the information required by a certificate policy, signs certificates that bind public keys to identities or identifiers, and participates in a chain of trust that browsers, operating systems and applications can verify.

To explore the related technical concepts used in this CA (Certificate Authority) guide, visit our broadband terminology guide.