TLS Certificate Authorities

A Certificate Authority (CA) issues digital certificates that bind a domain (or other identity) to a public key. The certificate is signed by a key whose root is pre-trusted by browsers and operating systems. When a client connects over TLS, it validates the chain back to a root it already trusts, and only then encrypts traffic with the server’s public key.

Public vs private CAs

Public CAs issue certificates for names on the public internet, and their root keys ship in browser/OS trust stores.
Private CAs (such as AWS Private CA, HashiCorp Vault PKI, internal Active Directory CS) issue certificates trusted only by systems explicitly configured to trust them. Used for internal service-to-service traffic, mutual TLS (mTLS), and devices not on the public internet.

Free vs paid public CAs

Historically all public certificates were paid. The introduction of Let’s Encrypt in 2015 changed the economics by making domain-validated (DV) certificates free and automatable.

Free public CAs

Let’s Encrypt — the most widely used free public CA, run by the Internet Security Research Group (ISRG). Issues 90-day DV certificates over the ACME protocol. Auto-renewal is expected; humans should not be in the loop after initial setup.
Google Trust Services — also free, also ACME, also 90-day cycle. Backed by Google’s infrastructure. Functionally interchangeable with Let’s Encrypt for most use cases.
ZeroSSL — free for non-commercial use, ACME-compatible.
Buypass Go SSL — another ACME-based free CA option.

Paid public CAs

DigiCert, Sectigo, GoDaddy, Entrust, GlobalSign, and others sell certificates that include:

Organisation Validation (OV) — CA verifies the requesting organisation exists.
Extended Validation (EV) — heavier vetting; historically rendered as a green bar in browsers, though modern browsers no longer display this distinctly.
Vendor support contracts and SLAs.
Longer validity periods (legacy — the industry has moved toward shorter validity for everyone).
Code-signing and document-signing certificates outside the TLS use case.

For pure TLS termination on a web property, free DV certificates from Let’s Encrypt or Google are usually sufficient.

Wildcard and SAN certificates

A SAN (Subject Alternative Name) certificate covers a list of explicit names: example.com, www.example.com, api.example.com.
A wildcard certificate covers *.example.com, matching one label of subdomain. It does not cover the apex example.com and does not cover deeper names like a.b.example.com.
A common pattern is a single cert with SANs example.com + *.example.com.

Wildcard certificates can only be issued via DNS-based ACME validation; HTTP validation cannot prove control of arbitrary subdomains.

Certificate chains

A served certificate chain looks like:

Leaf — the certificate for your domain.
Intermediate(s) — issued by the CA, signed by the root.
Root — self-signed, in the client’s trust store.

Servers must serve the leaf plus intermediates. Roots are not served — clients already have them. A misconfigured chain (missing intermediate) breaks validation on clients that lack the AIA fetch capability. Web servers (see Webservers) must be configured to present the full chain.

ACME validation methods

The ACME protocol (RFC 8555) supports three challenges to prove domain control:

HTTP-01 — the client serves a token at http://example.com/.well-known/acme-challenge/<token>. Cannot be used for wildcards.
DNS-01 — the client publishes a TXT record at _acme-challenge.example.com. Required for wildcard certificates. Works behind firewalls and for non-public services.
TLS-ALPN-01 — the client presents a special certificate during a TLS handshake that uses the acme-tls/1 ALPN protocol. Useful when only port 443 is exposed.

Choosing between Let’s Encrypt and Google Trust Services

Both are free, both use ACME, both issue 90-day certificates, both have high uptime. Considerations:

Issuance reliability: Let’s Encrypt has had several notable outages and rate-limit incidents over the years. Diversification across two CAs is a defensive posture some teams adopt.
Rate limits: Let’s Encrypt enforces per-account and per-domain rate limits. Google Trust Services has its own.
CA-pinning (CAA records): the CAA DNS record restricts which CAs can issue for your domain. Set this carefully if you list only one CA. Consider DNSSEC to protect those DNS answers.
Failover: production-critical services sometimes configure clients (e.g. cert-manager, lego) with multiple ACME issuers and fall back automatically.

Some Cloudflare for SaaS workflows prefer one CA over the other based on ACME issuance stability for high-volume customer domain onboarding.

Certificate Transparency

All publicly-trusted certificates are logged to Certificate Transparency (CT) logs. Any party can inspect what certificates have been issued for a domain by querying tools such as crt.sh or Censys. This is useful for:

Detecting mis-issuance (a CA wrongly issuing for your domain).
Discovering shadow infrastructure (test certs revealing internal hostnames) — relates to Shadow IT.
Threat intelligence (tracking adversary infrastructure) — see Threat Analysis and MITRE ATT&CK.

CT logs are append-only and globally distributed. Browsers reject certificates not embedded with SCTs (Signed Certificate Timestamps) from approved logs.

Self-signed certificates

A self-signed cert is one where the issuer is also the subject — there is no trusted root. Clients reject these by default. Used for:

Local development with an explicit trust override.
Internal-only systems where deployment automation distributes the trust anchor.

Renewal hygiene

Treat 90-day certs as the norm. Automate renewal at ~60 days remaining.
Monitor expiry independently of the renewal job (the alert that fires because the renewal job failed is the one that matters). See CloudWatch Alarms SLO Driven.
Avoid one-shot manual cert installs; they will be forgotten. Manage certificates with ACM or via Terraform / IaC.

Key takeaways

A CA binds a domain to a public key with a chain rooted in pre-trusted authorities.
Free DV certs (Let’s Encrypt, Google Trust Services) cover the common web TLS case at no cost.
Paid CAs add OV/EV vetting, support, and code/document signing.
Wildcards require DNS-01 ACME validation and do not cover the apex.
CT logs make every public cert publicly visible — useful for monitoring, important to remember when issuing for internal-sounding names.

References

RFC 8555 — Automatic Certificate Management Environment (ACME)
RFC 6962 — Certificate Transparency
Let’s Encrypt operational documentation
Google Trust Services public documentation
Mozilla Root Store policy

mgarden

Explorer