cybersecurity pki

Certificate Authority (CA)

certificate-authority ca pki x509 tls certificates trust
Plain English

A Certificate Authority is a trusted stamp machine. When you have a public key and you want others to trust it belongs to you, you go to a CA. The CA verifies your identity, then stamps a certificate on your public key - a cryptographically signed document saying “I vouch that this key belongs to this person or server.” Anyone who trusts the CA will trust the certificate it issued. Your browser ships with a list of about 150 public CAs it already trusts. For a private network or homelab, you run your own.

Technical Definition

A Certificate Authority is a cryptographic entity that issues X.509 certificates by signing a Certificate Signing Request (CSR) with its own private key. Verifiers check the CA’s signature against a trusted root to establish validity.

Two-Tier PKI Structure (most common):

Root CA (offline, air-gapped)
  └── Intermediate CA (online, issues end-entity certs)
        ├── Server certificate (TLS)
        ├── Client certificate (mTLS, PIV)
        └── Code signing certificate

The Root CA’s private key is kept offline. If the Intermediate CA is compromised, revoke it and issue a new one from the Root. The Root never needs to come online again.

Certificate Signing Request (CSR) flow:

  1. Requestor generates a key pair
  2. Requestor creates a CSR containing the public key, subject (CN, O, SAN), and a self-signature proving private key possession
  3. CA validates identity out-of-band (or via an ACME challenge for domain validation)
  4. CA signs the CSR to produce a certificate, embedding its own signature and the validity period
  5. Requestor installs the certificate; verifiers trust it because they trust the CA

Key CA operations:

  • Issuance: Sign a CSR to produce a certificate
  • Revocation: Invalidate a certificate before expiry via CRL (Certificate Revocation List) or OCSP (Online Certificate Status Protocol)
  • Renewal: Re-sign with a new validity period (same or new key pair)

step-ca configuration (Smallstep):

step-ca is an open source CA with ACME support, JWK and X5C provisioners, and configurable certificate lifetimes. It runs as a single binary and stores its state in a JSON config file. Default provisioner type for homelab use is JWK (password-protected). Certificate lifetimes are configurable per provisioner.

Trust anchor distribution:

Client systems must install the Root CA certificate into their trust store to validate certificates issued by the CA. On macOS: step certificate install. On Debian/Ubuntu: copy to /usr/local/share/ca-certificates/ and run update-ca-certificates.

In the Wild

Every HTTPS website you visit is trusted because its TLS certificate was signed by a CA your browser already trusts. Let’s Encrypt automated this for public websites in 2015, making free TLS certificates standard. For internal infrastructure (VPNs, mTLS between services, PIV cards, SSH), public CAs are not appropriate - they cannot issue certificates for private IPs or internal hostnames, and you do not want to depend on an external service for internal auth. A private CA (step-ca, EJBCA, Vault PKI, Microsoft ADCS) gives you complete control. For a homelab running hardware-token authentication, the CA is the root of trust for everything: it signs the YubiKey certificates that authenticate every SSH session. The CA can be powered off between certificate operations - it is not in the authentication path once certs are issued.

← Back to Dictionary