What is a certificate authority

A certificate authority — CA — is an organisation that issues digital certificates. The certificate's job is to vouch that a particular public key really belongs to a particular entity (a website, a server, a user). Browsers, operating systems, and VPN clients trust a small set of CAs by default; everything else builds on that trust.

If you visit https://fexyn.com, the certificate the server presents was signed by a CA. Your browser checks the signature against the CA's public key (which it already has), confirms it matches, and decides the server is who it claims to be. Without CAs, every TLS connection would require pre-existing trust between you and the server — which doesn't scale.

The major CAs

The trust store on a typical machine has a few hundred root CAs from organisations including:

• Let's Encrypt — free, automated, dominates the long tail of small-site certs. Issues 90-day certs to encourage automation.
• DigiCert / Sectigo — commercial, broader product range, used heavily in enterprise.
• Entrust, GlobalSign, GoDaddy — also commercial.
• National CAs — some governments operate their own (China's CFCA, for example). These are sometimes politically controversial.

A few CAs have been removed from trust stores after misissuing certificates or weak security practices (Symantec was distrusted by browsers in 2018; WoSign and StartCom were distrusted earlier).

How CAs sign certificates

The mechanism is a chain. The root CA's private key signs an intermediate CA's certificate. The intermediate's private key signs end-entity certificates (websites, servers, users). The end-entity certificate proves chain back to the root.

When your browser receives a certificate, it walks this chain upward to a root in its trust store. If every signature validates and nothing is revoked, the chain is good.

The reason for intermediates: roots stay offline (ideally on hardware), used only to sign new intermediates. Day-to-day signing happens with online intermediates that can be replaced if compromised. A compromised intermediate is bad; a compromised root is catastrophic.

What can go wrong

CAs have failed in several ways over the years:

• Compromise. Attackers steal an intermediate key and issue valid-looking certs for arbitrary domains. DigiNotar, Comodo, and others have been hit.
• Misissuance. A CA issues a cert to the wrong party, often via flawed domain validation. Certificate Transparency logs make this detectable post-hoc.
• Coercion. A government compels a CA in their jurisdiction to issue certificates for surveillance purposes. The defence is Certificate Transparency plus public scrutiny.

Each failure forces browsers to distrust certificates from the affected CA. Some failures rebuild; some don't.

CAs in a VPN context

A VPN provider running its own PKI is its own CA — operating an internal root and intermediate that aren't in your browser's trust store, but are pinned in the VPN client.

Fexyn's clients pin Fexyn's intermediate CA. If a Fexyn server presents a certificate not signed by that intermediate, the client refuses the connection. This prevents a compromised public CA from being used to MITM Fexyn traffic — the client doesn't trust any public CA for VPN connections, only Fexyn's internal one. See short-lived certificates for how cert lifetime ties into this.

This structure is why a man-in-the-middle attack on a Fexyn connection requires compromising Fexyn's PKI specifically, not just any random CA.

Try Fexyn free for 7 days — the cert you get is from Fexyn's PKI and lives 24 hours.