1. Goal

OCSP-relevant AIA extensions, the CA database and an offline responder model are made reviewable.

This document complements the main README with technical context, review questions and operational framing. It is not a public CA operating manual; it is a reproducible learning and analysis example.

2. What is done

The example runs locally, creates temporary artifacts only below work/ and writes evidence below work/evidence/. Depending on the topic it creates a root, intermediate, CSR, server certificate, client certificate, CRL, revocation event or automation model.

The steps are intentionally small:

1. Read the configuration files.
2. Run the script.
3. Inspect the evidence.
4. Interpret OpenSSL output.
5. Discuss the failure mode or operational question.
6. Confirm cleanup and private key protection.

3. Why it is done

PKI failures are rarely pure syntax failures. A certificate can be technically created but still be wrong: wrong issuer, wrong SAN, overly long validity, missing key usage, unclear chain, missing revocation model or exposed private key. This example therefore binds every technical action to a review structure.

4. Typical commands

openssl version
openssl req -in work/csr/server.csr.pem -noout -subject -text 2>/dev/null || true
openssl x509 -in work/certs/server.crt.pem -noout -subject -issuer -serial -dates 2>/dev/null || true
openssl x509 -in work/certs/server.crt.pem -noout -text 2>/dev/null | sed -n '/X509v3 extensions:/,/Signature Algorithm/p' || true
openssl verify -CAfile work/root/certs/root.crt.pem -untrusted work/intermediate/certs/intermediate.crt.pem work/certs/server.crt.pem 2>/dev/null || true
find work/evidence -type f -maxdepth 2 -print 2>/dev/null | sort || true

5. Verify success

• The script exits without an unexpected error.
• Evidence files match the topic of the example.
• End-entity certificates have CA:FALSE.
• CA certificates have CA:TRUE and suitable key usage.
• Server certificates contain SANs.
• Chain verification separates the root as trust anchor and the intermediate as an untrusted chain certificate.
• Revocation, OCSP or CRL behavior is not claimed without evidence or a clear lab boundary.

6. Common mistakes

7. Security aspects

Real PKIs must protect root and intermediate keys more strongly than this lab. Root keys are typically kept offline. Intermediate keys are protected by HSMs, strict file permissions, audit logs and separated roles. Publicly trusted certificates have additional requirements that this workshop can explain but does not simulate.

8. Realistic use

This pattern applies to internal TLS certificates, mTLS between services, Kubernetes Ingress, Vault PKI, cert-manager, Smallstep, SPIFFE/SPIRE and traditional enterprise PKIs. The decisive factor is not the tool but the evidence: who signs, what the certificate is valid for, how trust is distributed, when renewal starts and how revocation is handled.

9. Workshop flow

1. Read the goal aloud and limit the scope.
2. Distinguish repository files from runtime artifacts.
3. Open the OpenSSL configuration and mark relevant sections.
4. Identify private key paths.
5. Check CSR subject and SANs.
6. Explain CA extensions before signing.
7. Create the certificate or validate the model artifact.
8. Compare issuer and subject.
9. Interpret basic constraints and key usage.
10. Run chain verification.
11. Reproduce the failure mode intentionally if the example includes one.
12. Open evidence files and check for private keys.
13. Ask the operational question: who owns this certificate?
14. Ask the security question: how would compromise be detected?
15. Ask the renewal question: when must action start?
16. Ask the revocation question: which clients check CRL or OCSP?
17. Ask the audit question: which decision is traceable?
18. Run cleanup.
19. Document deviations.
20. Convert the result into a short review summary.

10. Review matrix

Official References

• RFC 5280: Internet X.509 Public Key Infrastructure Certificate and CRL Profile: https://datatracker.ietf.org/doc/html/rfc5280
• CA/Browser Forum Baseline Requirements: https://cabforum.org/working-groups/server/baseline-requirements/requirements/
• NIST SP 800-57 Part 1 Revision 5: https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final
• OpenSSL Manual Pages: https://www.openssl.org/docs/manpages/

Example Appendix: Evidence, Transfer and Operations

This appendix makes the example more complete as a training component. It is intentionally limited to real PKI questions: certificate content, trust chain, key material, revocation, renewal, audit and operational handover.

Evidence Checklist

• openssl version was recorded so output can be tied to a concrete tool version.
• Subject, issuer, serial and validity were checked with openssl x509 -noout.
• SAN, basic constraints, key usage and EKU were extracted from the certificate text.
• The chain was verified with the root as trust anchor and the intermediate as chain certificate.
• Failure modes were not merely described; they were made visible with a controlled exit code or evidence file.
• Private keys were not copied into evidence files.
• Runtime artifacts live below work/ and are separated from repository content.
• Cleanup is possible by removing work/.

Transfer Questions

1. Who owns the certificate and who may approve issuance?
2. Which CA signs it and how is that CA protected?
3. Which clients or systems must trust the trust anchor?
4. Which validity period is justified and when does renewal start?
5. How is revocation distributed and how is client behavior checked?
6. Which logs or tickets prove request, approval, issuance and change?
7. Which deviation would not be acceptable for a public CA?
8. Which parts of the lab should be automated by HSM, Vault, cert-manager, ACME or SPIFFE?

Operational Notes

Review Summary

An example is complete only when technical execution, technical explanation and security evidence fit together. For CA workshops this matters more than the command sequence alone, because a certificate can still be dangerous even when OpenSSL created it successfully.