# Certificate, key and secret lifecycle

An expired TLS certificate can cause an outage; a leaked API key can enable unauthorized operations. These are different objects. This guide distinguishes certificates, private keys and application secrets, connecting copies, consumers and recovery dependencies to a controlled lifecycle.

Original SecNet educational content with fictional examples, not publication/endorsement by referenced organizations. Page exercise choices last only for the open session; no real organizational data is collected.

2026.10 · 2026-10-21

## What should I do tomorrow?

1. Inventory certificate and secret consumers for one critical service.
2. Verify one renewal along the actual client path.
3. Plan tests for old-secret rejection and independent key recovery.

## Concepts

**Sertifika** — A signed structure binding identity to a public key; not the private key.

**Özel anahtar** — Secret key material enabling the associated cryptographic operations.

**Uygulama sırrı** — A confidential access value such as an API key or password.

**Rotasyon** — Controlled transition to new material and termination of the old authority.

**Kripto çevikliği** — The ability to change algorithms, protocols and keys with their dependencies.

## Process map

### 1. Discover

Service owner

Record uses and consumers.

Owned inventory.

### 2. Set policy

PKI + security

Define generation, storage and renewal rules.

Approved profile.

### 3. Deploy and validate

Operations

Deploy to authorized consumers and test at the real endpoint.

Service validation.

### 4. Renew or revoke

PKI + responders

Change under control for expiry or compromise.

Evidence of old/new state.

### 5. Reconcile and improve

Independent reviewer

Reconcile copies, access and recovery dependencies.

Closed exceptions.

## Distinguish objects and owners

TLS certificates, signing keys, disk-encryption keys and API tokens have distinct purposes and risks. Record purpose, service, environment, owner, issuer/provider, expiry and consumer references. Never put actual secret values in a spreadsheet or CMDB description.

One domain may involve different certificates at the load balancer, application and internal services. External scans miss internal certificates and unused copies. Reconcile discovery with owners and separately assess reuse of one key across locations.

- [ ] The inventory contains controlled references instead of secrets.

Reference: [NIST SP 1800-16B — TLS Certificate Management](https://www.nccoe.nist.gov/publication/1800-16/VolB/index.html)

## Generation, storage and access

Generate keys within an appropriate security boundary and justify export or backup requirements. Give workload identities only necessary secret access. Separate development, test and production material. Moving a secret into a vault does not remove copies already exposed in logs or source code.

Test access paths and authorized deputies for keys needed during recovery. Keeping the only backup key inside the encrypted backup creates a circular dependency. Log identity, object reference, action and outcome rather than secret contents.

Objects and closure differences

| Subject | Focus | Validation / boundary |
| --- | --- | --- |
| TLS certificate | Identity and chain presented to clients | New-certificate test at the actual endpoint |
| API secret | Consumers and access scope | New succeeds, old fails |
| Encryption key | Protected data and recovery dependency | Authorized restoration and key access |

- [ ] Recovery dependencies and environment separation are tested.

Reference: [NIST SP 1800-16B — TLS Certificate Management](https://www.nccoe.nist.gov/publication/1800-16/VolB/index.html), [NIST SP 800-53 Rev. 5 — control catalog](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final)

## Validate renewal at the actual endpoint

A successful renewal job may leave the old certificate on a load balancer. Reconcile inventory and deployment targets. Test names/SANs, trust chains, validity and protocol compatibility along the actual client path. Include reload requirements in the change plan.

Choose alert thresholds for deployment lead time and risk; there is no single mandatory day count for every certificate. Escalate failed renewal, unreachable owners and incomplete deployment before expiry. Monitor the automation’s own authorization and failure reporting.

- [ ] The served certificate is validated, not merely the renewal job.

Reference: [NIST SP 1800-16B — TLS Certificate Management](https://www.nccoe.nist.gov/publication/1800-16/VolB/index.html)

## Rotation and consumer transition

For a fictional integration secret, identify authorized consumers and rollback limits first. A product-supported dual-key window may help transition but must be bounded. Distribute the new value, validate business outcomes, disable old access and test its rejection.

Do not wait for routine schedules after compromise. Issuing a new secret does not automatically revoke the leaked value; sessions and derived tokens may persist. Establish scope and coordinate secret/session invalidation with incident response and service continuity.

- [ ] Rejection of old values and associated sessions are checked.

Reference: [NIST SP 800-53 Rev. 5 — control catalog](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final)

## Decisions after key compromise

Investigate exposure location, access time, permissions and affected services. Preserve evidence under control without copying the leaked value into reports. For certificate revocation assess CA and product behaviour; not every client enforces revocation checks in the same way.

Signing-key compromise and encryption-key loss have different effects. Past signatures, software distribution or old encrypted records may be affected. Owners coordinate impact, replacement and notification assessment. Do not restore a compromised key under an ordinary rollback pretext.

- [ ] The compromise plan distinguishes identity, data and service impact.

Reference: [NIST SP 1800-16B — TLS Certificate Management](https://www.nccoe.nist.gov/publication/1800-16/VolB/index.html)

## Crypto agility and sustainable operation

An algorithm list is insufficient; map protocols, libraries, hardware, signed artifacts and external dependencies. Establish test environments and transition order for cryptographic changes. Post-quantum readiness does not mean replacing all encryption without a plan.

Report ownerless objects, expiry risk, failed renewal, unverified old-secret revocation and untested recovery paths. Audit samples should trace inventory to endpoints and consumer tests. State discovery coverage and never count unknown objects as controlled.

- [ ] Cryptographic transition is bound to dependency and test plans.

Reference: [NIST SP 1800-16B — TLS Certificate Management](https://www.nccoe.nist.gov/publication/1800-16/VolB/index.html), [NIST — Crypto Agility](https://csrc.nist.gov/projects/crypto-agility)

## Common mistakes and better approaches

**Writing secret values into inventory.** — Use controlled references to authorized storage.

**Assuming a new key revokes the old one.** — Separately verify rejection of old access.

**Counting external certificates only.** — Discover internal services and backup/key dependencies too.

## Decision examples and explained answers

### Renewed but unchanged

Renewal succeeded but the external endpoint serves the old certificate.

**Close the successful job.** — Revisit

Issuance and serving are separate steps. If clients still receive the old object, expiry risk remains; job status alone cannot justify closure.

**Validate deployment targets and the client path.** — Supported approach

Reconcile load balancers and backends, deploy through approved change, then verify chain, name and validity on the actual client path.

### Leaked API key

An active key was found in source code.

**Delete the line and wait.** — Revisit

Deleting a line does not remove past clones, logs or copied values. Access risk continues while the credential remains usable.

**Start revocation/replacement and usage review.** — Supported approach

Preserve evidence, establish permissions and consumers, transition under control, invalidate old material and associated sessions, and investigate suspicious use.

### Recovery key

The backup key exists only inside the same encrypted backup.

**The backup exists, so it is enough.** — Revisit

A key locked inside the data it decrypts makes the backup unusable. An inventory record alone does not establish recoverability.

**Test independent authorized key recovery.** — Supported approach

Separate key custody, deputies and access paths, then exercise recovery of both keys and data with authority. Record elapsed time and business validation.

## Official references

- [NIST SP 1800-16B — TLS Certificate Management](https://www.nccoe.nist.gov/publication/1800-16/VolB/index.html) — TLS certificate-management reference; API-secret examples are SecNet teaching.

- [NIST SP 800-53 Rev. 5 — control catalog](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) — Reference for control families; example workflows are SecNet adaptations, not automatic compliance mappings.

- [NIST — Crypto Agility](https://csrc.nist.gov/projects/crypto-agility) — Project reference for transition capability; not a product or deadline recommendation.