Stop reading whenever you have enough

Certificates, in twelve questions.

Each one is the question the previous answer makes you ask. The ones that matter come with the command, because that is the part you meet at work.

Not technical? The first three questions are written for you, and they are enough to follow any conversation about this.

Rungs
12
Hands on
4
Read
~8 min
01

What it is

01–03

Every workload carries a short lived ID card, signed by an authority. Someone has to own the authority.

three minutes, no cluster needed · for anyone

  1. 01

    What is the chain, top to bottom?

    Not knowing this costs

    Three lifetimes, from a decade to a day, each on purpose.

    • A root: long lived, kept cold, rarely touched
    • An intermediate: istiod signs with this daily
    • Leaves: per workload, 24 hours, fully automatic
  2. 02

    Which parts renew themselves?

    Not knowing this costs

    The certificates that page you are the two nobody automated.

    • Leaves: entirely automatic, nobody thinks about them
    • Intermediate and root: humans, calendars, change windows
    • The automation ends exactly where the blast radius grows
  3. 03

    Who should own the root?

    Not knowing this costs

    The default root is generated in the cluster and dies with it.

    • Default: istiod invents one inside the cluster
    • Production: your PKI team issues an intermediate
    • The cluster should never hold a root key

Before you scroll on

0/3

You should now be able to

02

The chain you will run

04–05

Three certificates, three lifetimes, three very different blast radii.

root, intermediate, leaf, and where each lives · for whoever owns the platform

  1. 04

    How does my company CA plug in?

    hands on

    Not knowing this costs

    Mounting the root key hands cluster admins your whole PKI.

    • A cacerts secret in istio-system, before install
    • Intermediate cert and key, plus the root chain
    • istiod signs leaves with your intermediate from then on
    shellthe handover
    kubectl create secret generic cacerts -n istio-system \
  --from-file=ca-cert.pem \
  --from-file=ca-key.pem \
  --from-file=root-cert.pem \
  --from-file=cert-chain.pem

kubectl rollout restart deploy/istiod -n istio-system
# new leaves chain to your root from the next issuance on
    ca-cert.pem is the intermediate, never the root. If the file you are about to mount is your root key, stop: the cluster is the wrong place for it to live.
  2. 05

    Are gateway certificates the same system?

    Not knowing this costs

    Two certificate systems, two expiry calendars, one word: certificates.

    • No. Public TLS certs come from a public CA
    • They live in secrets named by credentialName
    • cert-manager typically owns their renewal

Before you scroll on

0/3

You should now be able to

03

Proving it works

06–07

Expiry dates are facts you read, not settings you trust.

commands that answer yes or no · for whoever has to sign it off

  1. 06

    What chain is a workload actually carrying?

    hands on

    Not knowing this costs

    The chain you configured and the chain in the pods can differ for days.

    • Pull the cert off the proxy and read it
    • Issuer, expiry and SPIFFE identity in one look
    shellthe leaf, in the open
    istioctl proxy-config secret deploy/payment-svc -n payments -o json \
  | jq -r '.dynamicActiveSecrets[0]
    .secret.tlsCertificate.certificateChain.inlineBytes' \
  | base64 -d | openssl x509 -noout -issuer -enddate -ext subjectAltName

# issuer=O = YourCorp Mesh Intermediate     <- your chain, in force
# notAfter=Jul 27 09:14:02 2026 GMT         <- ~24h away, correct
# URI:spiffe://cluster.local/ns/payments/sa/payment-svc
    issuer still reading O = cluster.local after a cacerts handover means old pods are on the old chain: leaves only re chain as they renew or restart.
  2. 07

    When does the root expire?

    hands on

    Not knowing this costs

    An expired root does not degrade. Everything stops at once.

    • Read it from the secret, put it in a calendar
    • Roots expire on schedule, meshes forget on schedule
    shellthe date that ends everything
    kubectl get secret cacerts -n istio-system \
  -o jsonpath='{.data.root-cert\.pem}' | base64 -d \
  | openssl x509 -noout -enddate

# notAfter=Mar 14 00:00:00 2032 GMT
# alertable version: istiod exports
# citadel_server_root_cert_expiry_timestamp
    The metric makes it an alert instead of a memory. Alert a year out and again at ninety days: root rotation is a project, not a task.

Before you scroll on

0/3

You should now be able to

04

When it breaks

08–10

Certificate incidents are calendars, not surprises. The pages come from unread calendars.

the two expiries and the rotation · for whoever gets paged

  1. 08

    istiod is down. When do certificates become the problem?

    Not knowing this costs

    An istiod outage is quiet for hours, then everything fails at once.

    • Leaves renew at roughly half life, so ~12 hours of slack
    • Past that, renewals fail and workloads age out
    • The outage clock and the cert clock are different clocks
  2. 09

    How does an intermediate rotate without downtime?

    hands on

    Not knowing this costs

    Intermediate rotation is routine only if the root is not moving too.

    • Replace cacerts with the new intermediate
    • Restart istiod, then roll workloads in waves
    • Old and new leaves coexist, both chain to the root
    shellthe rotation, in order
    kubectl create secret generic cacerts -n istio-system \
  --from-file=ca-cert.pem --from-file=ca-key.pem \
  --from-file=root-cert.pem --from-file=cert-chain.pem \
  --dry-run=client -o yaml | kubectl apply -f -

kubectl rollout restart deploy/istiod -n istio-system
# then, over hours not seconds:
kubectl rollout restart deploy -n payments   # wave one, watch, continue
    This works because both intermediates chain to the same root, so peers validate either. That is also exactly why root rotation cannot work this way.
  3. 10

    Why is root rotation a different animal?

    Not knowing this costs

    Skipping the dual trust window partitions the mesh by certificate.

    • Peers must trust old and new roots simultaneously
    • Distribute the combined trust bundle first, everywhere
    • Only then re issue, then retire the old root

Before you scroll on

0/3

You should now be able to

05

Where it ends

11–12

The mesh manages its own identities, and nothing else it touches.

the limits, where people get caught · for whoever reviews the design

  1. 11

    What does the mesh not manage?

    Not knowing this costs

    The mesh calendar covers one of your three certificate estates.

    • Public certs for browsers, databases, external APIs
    • Anything TLS outside proxy to proxy
    • cert-manager and your PKI own those calendars
  2. 12

    What is the one alert that covers this page?

    Not knowing this costs

    Three lines of alerting convert this whole topic from pages to chores.

    • Root and intermediate expiry, from the istiod metrics
    • istiod availability, because leaves depend on it
    • Gateway cert expiry, from cert-manager or blackbox

Before you scroll on

0/3

You should now be able to

Go deeper

4 links, each earning its place.

Plug in CA certificates↗

The cacerts procedure from rung 4, with the exact file layout.

istio-csr, cert-manager integration↗

The automated alternative: cert-manager issues for the mesh and the cluster never holds ca-key.pem at all.

Istio certificate management concepts↗

The chain from rung 1 as the project describes it.

Root transition guidance↗

The dual trust window from rung 10, as a documented procedure.

Where this leaves you

Rungs 6 and 7 are the two reads that belong in your runbook. Rung 12 turns the rest of the page into three alerts.

If you keep one thing: leaves renew themselves and the other two links never do. Every certificate page you will ever get is about the two that need a calendar.