The six questions that govern every credential

Infrastructure estates accumulate credentials faster than they accumulate understanding of them. A single service may hold a certificate, a database password, a cloud role, an SSH key and a token for the secret manager that hands out the rest. You cannot learn each of those as a separate topic and hope to keep up. What you can do is ask the same six questions of every one of them, and notice that the answers are what differ, not the questions.

The six questions

Ask them in this order. The order matters because each answer constrains the next: you cannot sensibly discuss storage before you know what kind of proof you are storing, and you cannot discuss lifetime before you know who is capable of issuing a replacement.

• Which principal is being trusted? A person, a host, a running workload, or an organisation. When this answer is vague, authorisation attaches to something like a shared service account inhabited by four engineers and a cron job, and no audit trail can afterwards say which of them acted.
• Which credential proves that identity? A memorised secret, a bearer token, a signature made with a private key, or a platform assertion. When this answer is weak, the credential can be replayed by anyone who observes it once.
• Who issued it, and who checks the issuer? Every credential traces back to something a relying party has decided to trust in advance. When this answer is missing, either nobody validates, or the validator trusts a far wider set of issuers than anyone intended.
• Where does the private material live? One file on one host, a hardware module, a secret manager, or six container images and a laptop. When this answer cannot be enumerated, you cannot reason about compromise, because you do not know how many copies exist.
• How long does it live? A fixed validity window, a lease, a session, or forever. When this answer is forever, the credential outlives the project, the team and the reason it was issued.
• What revokes it, and what enforces that? Not the intention to revoke: the mechanism, and the component that consults the mechanism. When this answer is decorative, compromise becomes permanent for the remaining lifetime.

flowchart LR
    S["Q1 principal\nwho is trusted"] --> C["Q2 credential\nwhat proves it"]
    I["Q3 issuer\nwho vouches"] --> C
    C --> K["Q4 storage\nwhere the private half rests"]
    C --> L["Q5 lifetime\nwhen it stops working"]
    C --> R["Q6 revocation\nwhat cancels it early"]
    K --> V["Relying party\naccepts or rejects"]
    L --> V
    R --> V

The diagram is worth reading as two halves. Everything on the left is issuance: a principal exists, an issuer vouches for it, and a credential comes into being. Everything on the right is validation: some other component, at some later moment, has to decide whether to accept what it is shown. Most credential incidents happen because the two halves were designed by different people at different times, and the validation side turned out never to check the thing the issuance side assumed it would.

Reading the answers off a server certificate

A certificate is unusually generous: four of the six answers are printed on its face, and you can read them without touching the private key or the server.

CERT=/etc/ssl/certs/app.lab.example.pem
openssl x509 -in "$CERT" -noout -subject -issuer -serial -dates
openssl x509 -in "$CERT" -noout -ext subjectAltName,keyUsage,extendedKeyUsage

subject=CN=app.lab.example
issuer=O=RunBook Academy Lab, CN=RunBook Lab Server Issuing CA
serial=21173B360D80F4A69A91164F1067F4F81A1B1B6E
notBefore=Aug 26 21:19:00 2026 GMT
notAfter=Nov 24 21:19:00 2026 GMT

X509v3 Key Usage: critical
    Digital Signature, Key Encipherment
X509v3 Extended Key Usage:
    TLS Web Server Authentication
X509v3 Subject Alternative Name:
    DNS:app.lab.example, DNS:www.app.lab.example

The principal is the set of names in the Subject Alternative Name extension, and only those names; a modern client identifies a service by that extension alone. The issuer line answers the third question, and the serial gives you the handle that any revocation record will use to name this exact certificate. The two date lines answer the fifth question exactly, to the second. The Extended Key Usage answers a question you did not think to ask: what this credential is permitted to be used for, which is server authentication and nothing else.

Two answers are not on the face of it. The certificate says nothing about where the matching private key is stored, and nothing about what would revoke it. Those are properties of your estate, not of the file, and they are exactly the two that get lost.

Reading the answers off an SSH user certificate

The same analysis transfers to a completely different credential format with no change to the questions.

alice-cert.pub:
        Type: ssh-ed25519-cert-v01@openssh.com user certificate
        Public key: ED25519-CERT SHA256:/hOjaMxlXaTaWekzkFCIxR4PRU/c7eLkooB565Y7X6I
        Signing CA: ED25519 SHA256:6x39cg8OAp7PZgisHreCLRO7g0vp6s0VZIw+DcTgKtE (using ssh-ed25519)
        Key ID: "alice@runbook-lab"
        Serial: 1003
        Valid: from 2026-08-26T19:21:30 to 2026-08-26T20:21:30
        Principals:
                deploy
        Critical Options: (none)
        Extensions:
                permit-X11-forwarding
                permit-agent-forwarding
                permit-port-forwarding
                permit-pty
                permit-user-rc

The principal here is subtle and worth slowing down for. The Key ID names a human, alice@runbook-lab, which is what the audit log will record. The Principals list names deploy, which is what the certificate is authorised to log in as. Those are two different answers to question one, deliberately: one identifies who is accountable, the other identifies which account they may become. Question three is answered by the Signing CA fingerprint, question five by a validity window of exactly one hour, and question two by the certificate type, which tells you this is a signature-based proof rather than something transmissible.

The same six questions on a database password

Now apply the analysis to the least glamorous credential in the estate, and put the three side by side.

The password column is uncomfortable reading, and that is the point of the exercise. Four of its six answers are the weakest available: an ambiguous principal, a replayable proof, an unbounded lifetime and a revocation mechanism that is indistinguishable from a change that breaks every client at once. This is why the rest of this course spends so much of its time moving credentials out of that column, either by giving them certificates or by giving them short-lived, centrally issued leases.

Question six, and what actually enforces it

Ask a team how they would revoke a credential and you will usually get an answer about intent rather than mechanism. The useful form of the question is: name the component that consults the revocation record, and say what it does when the record is unavailable.

For publicly trusted TLS certificates the honest answer is uncomfortable. Mainstream browsers do not fetch live revocation status for ordinary certificates: Chrome disabled online checks by default and removed its extended-validation revocation checking in 2022, and Firefox from version 142 relies on its pushed CRLite data rather than fetching status for domain validated certificates that chain to the Mozilla root store. The consequence deserves stating plainly: for a compromised public TLS key, the effective control is a short lifetime plus fast reissuance, not revocation.

For SSH there is no revocation protocol at all. There are no intermediates, no CRL fetch and no responder; a certificate is one signature at one level. Revocation is a key revocation list file, and sshd consults it only because a RevokedKeys directive names it. If that directive is absent, revoking a certificate is an action with no effect anywhere.

Production discipline

1. Run the six questions on every new integration. Six answers in a ticket is a five-minute exercise that reliably surfaces the one nobody had thought about, which is almost always storage or revocation.
2. Write down the two answers the credential cannot tell you. Storage location and revocation enforcement live in your documentation or nowhere at all, and nowhere is the default.
3. Prefer a proof over a bearer secret whenever the platform offers one. Anything that can be copied and replayed converts an observation into an intrusion.
4. Make the principal precise before you make the policy. A permission attached to a shared identity cannot be revoked from one holder without revoking it from all of them.
5. Set lifetime from the enforcement answer, not from convenience. Where revocation is real and consulted, longer windows are defensible. Where it is not, short windows are the whole control.

Cross-course references

• Kubernetes for Production Sysadmins - Part LVII (Authentication) covers how an API server decides which principal a request belongs to, which is question one applied to a control plane.
• Linux for Production Sysadmins - Part XXVI (SSH) covers the server-side directives that decide which credentials sshd will accept, including the file that makes revocation real.
• Observability for Production Sysadmins - Part LXIV (TLSMonitoring) covers turning the validity window in question five into an alert that fires long before the window closes.

Quiz