1. PKI Trust Model

PKI Trust Model is treated as a reviewable PKI building block. The important point is not merely that a command creates a certificate, but that purpose, extensions, trust chain, validity, key usage, and cleanup are understandable.

openssl x509 -in certs/server.crt -noout -subject -issuer -dates
openssl x509 -in certs/server.crt -noout -text | sed -n '/X509v3 extensions:/,/Signature Algorithm/p'
openssl verify -CAfile certs/chain.pem certs/server.crt

A good solution also states whether it is a private lab PKI, an internal enterprise PKI, or publicly trusted TLS. Publicly trusted certificates have additional CA/Browser Forum Baseline Requirements; a lab CA workshop does not replace those requirements.

Practice and Review Expectation for PKI Trust Model

• Private keys are generated only in the lab and are not committed.
• Configurations use dummy DNs and documentation domains.
• CA certificates have CA:TRUE; end-entity certificates have CA:FALSE.
• Server certificates contain SANs; Common Name is not used as the only hostname check.
• The chain is verified with OpenSSL, not only inspected visually.
• Expiry, renewal, and revocation are documented as a lifecycle.
• Security topics describe attack surface, detection, and recovery.

Common Mistakes for PKI Trust Model

Submission Example for PKI Trust Model

submission/
  openssl/root-openssl.cnf
  openssl/intermediate-openssl.cnf
  csr/server.csr
  certs/server.crt
  certs/chain.pem
  evidence.md
  cleanup.md

Evidence contains relevant OpenSSL output, not private keys.

2. Root CA

Root CA is treated as a reviewable PKI building block. The important point is not merely that a command creates a certificate, but that purpose, extensions, trust chain, validity, key usage, and cleanup are understandable.

openssl x509 -in certs/server.crt -noout -subject -issuer -dates
openssl x509 -in certs/server.crt -noout -text | sed -n '/X509v3 extensions:/,/Signature Algorithm/p'
openssl verify -CAfile certs/chain.pem certs/server.crt

A good solution also states whether it is a private lab PKI, an internal enterprise PKI, or publicly trusted TLS. Publicly trusted certificates have additional CA/Browser Forum Baseline Requirements; a lab CA workshop does not replace those requirements.

Practice and Review Expectation for Root CA

• Private keys are generated only in the lab and are not committed.
• Configurations use dummy DNs and documentation domains.
• CA certificates have CA:TRUE; end-entity certificates have CA:FALSE.
• Server certificates contain SANs; Common Name is not used as the only hostname check.
• The chain is verified with OpenSSL, not only inspected visually.
• Expiry, renewal, and revocation are documented as a lifecycle.
• Security topics describe attack surface, detection, and recovery.

Common Mistakes for Root CA

Submission Example for Root CA

submission/
  openssl/root-openssl.cnf
  openssl/intermediate-openssl.cnf
  csr/server.csr
  certs/server.crt
  certs/chain.pem
  evidence.md
  cleanup.md

Evidence contains relevant OpenSSL output, not private keys.

3. Intermediate CA

Intermediate CA is treated as a reviewable PKI building block. The important point is not merely that a command creates a certificate, but that purpose, extensions, trust chain, validity, key usage, and cleanup are understandable.

openssl x509 -in certs/server.crt -noout -subject -issuer -dates
openssl x509 -in certs/server.crt -noout -text | sed -n '/X509v3 extensions:/,/Signature Algorithm/p'
openssl verify -CAfile certs/chain.pem certs/server.crt

A good solution also states whether it is a private lab PKI, an internal enterprise PKI, or publicly trusted TLS. Publicly trusted certificates have additional CA/Browser Forum Baseline Requirements; a lab CA workshop does not replace those requirements.

Practice and Review Expectation for Intermediate CA

• Private keys are generated only in the lab and are not committed.
• Configurations use dummy DNs and documentation domains.
• CA certificates have CA:TRUE; end-entity certificates have CA:FALSE.
• Server certificates contain SANs; Common Name is not used as the only hostname check.
• The chain is verified with OpenSSL, not only inspected visually.
• Expiry, renewal, and revocation are documented as a lifecycle.
• Security topics describe attack surface, detection, and recovery.

Common Mistakes for Intermediate CA

Submission Example for Intermediate CA

submission/
  openssl/root-openssl.cnf
  openssl/intermediate-openssl.cnf
  csr/server.csr
  certs/server.crt
  certs/chain.pem
  evidence.md
  cleanup.md

Evidence contains relevant OpenSSL output, not private keys.

4. End-Entity Certificates

End-Entity Certificates is treated as a reviewable PKI building block. The important point is not merely that a command creates a certificate, but that purpose, extensions, trust chain, validity, key usage, and cleanup are understandable.

openssl x509 -in certs/server.crt -noout -subject -issuer -dates
openssl x509 -in certs/server.crt -noout -text | sed -n '/X509v3 extensions:/,/Signature Algorithm/p'
openssl verify -CAfile certs/chain.pem certs/server.crt

A good solution also states whether it is a private lab PKI, an internal enterprise PKI, or publicly trusted TLS. Publicly trusted certificates have additional CA/Browser Forum Baseline Requirements; a lab CA workshop does not replace those requirements.

Practice and Review Expectation for End-Entity Certificates

• Private keys are generated only in the lab and are not committed.
• Configurations use dummy DNs and documentation domains.
• CA certificates have CA:TRUE; end-entity certificates have CA:FALSE.
• Server certificates contain SANs; Common Name is not used as the only hostname check.
• The chain is verified with OpenSSL, not only inspected visually.
• Expiry, renewal, and revocation are documented as a lifecycle.
• Security topics describe attack surface, detection, and recovery.

Common Mistakes for End-Entity Certificates

Submission Example for End-Entity Certificates

submission/
  openssl/root-openssl.cnf
  openssl/intermediate-openssl.cnf
  csr/server.csr
  certs/server.crt
  certs/chain.pem
  evidence.md
  cleanup.md

Evidence contains relevant OpenSSL output, not private keys.

5. Trust Stores

Trust Stores is treated as a reviewable PKI building block. The important point is not merely that a command creates a certificate, but that purpose, extensions, trust chain, validity, key usage, and cleanup are understandable.

openssl x509 -in certs/server.crt -noout -subject -issuer -dates
openssl x509 -in certs/server.crt -noout -text | sed -n '/X509v3 extensions:/,/Signature Algorithm/p'
openssl verify -CAfile certs/chain.pem certs/server.crt

A good solution also states whether it is a private lab PKI, an internal enterprise PKI, or publicly trusted TLS. Publicly trusted certificates have additional CA/Browser Forum Baseline Requirements; a lab CA workshop does not replace those requirements.

Practice and Review Expectation for Trust Stores

• Private keys are generated only in the lab and are not committed.
• Configurations use dummy DNs and documentation domains.
• CA certificates have CA:TRUE; end-entity certificates have CA:FALSE.
• Server certificates contain SANs; Common Name is not used as the only hostname check.
• The chain is verified with OpenSSL, not only inspected visually.
• Expiry, renewal, and revocation are documented as a lifecycle.
• Security topics describe attack surface, detection, and recovery.

Common Mistakes for Trust Stores

Submission Example for Trust Stores

submission/
  openssl/root-openssl.cnf
  openssl/intermediate-openssl.cnf
  csr/server.csr
  certs/server.crt
  certs/chain.pem
  evidence.md
  cleanup.md

Evidence contains relevant OpenSSL output, not private keys.

6. Chain Building

Chain Building is treated as a reviewable PKI building block. The important point is not merely that a command creates a certificate, but that purpose, extensions, trust chain, validity, key usage, and cleanup are understandable.

openssl x509 -in certs/server.crt -noout -subject -issuer -dates
openssl x509 -in certs/server.crt -noout -text | sed -n '/X509v3 extensions:/,/Signature Algorithm/p'
openssl verify -CAfile certs/chain.pem certs/server.crt

A good solution also states whether it is a private lab PKI, an internal enterprise PKI, or publicly trusted TLS. Publicly trusted certificates have additional CA/Browser Forum Baseline Requirements; a lab CA workshop does not replace those requirements.

Practice and Review Expectation for Chain Building

• Private keys are generated only in the lab and are not committed.
• Configurations use dummy DNs and documentation domains.
• CA certificates have CA:TRUE; end-entity certificates have CA:FALSE.
• Server certificates contain SANs; Common Name is not used as the only hostname check.
• The chain is verified with OpenSSL, not only inspected visually.
• Expiry, renewal, and revocation are documented as a lifecycle.
• Security topics describe attack surface, detection, and recovery.

Common Mistakes for Chain Building

Submission Example for Chain Building

submission/
  openssl/root-openssl.cnf
  openssl/intermediate-openssl.cnf
  csr/server.csr
  certs/server.crt
  certs/chain.pem
  evidence.md
  cleanup.md

Evidence contains relevant OpenSSL output, not private keys.

7. CRL and OCSP

CRL and OCSP is treated as a reviewable PKI building block. The important point is not merely that a command creates a certificate, but that purpose, extensions, trust chain, validity, key usage, and cleanup are understandable.

openssl x509 -in certs/server.crt -noout -subject -issuer -dates
openssl x509 -in certs/server.crt -noout -text | sed -n '/X509v3 extensions:/,/Signature Algorithm/p'
openssl verify -CAfile certs/chain.pem certs/server.crt

A good solution also states whether it is a private lab PKI, an internal enterprise PKI, or publicly trusted TLS. Publicly trusted certificates have additional CA/Browser Forum Baseline Requirements; a lab CA workshop does not replace those requirements.

Practice and Review Expectation for CRL and OCSP

• Private keys are generated only in the lab and are not committed.
• Configurations use dummy DNs and documentation domains.
• CA certificates have CA:TRUE; end-entity certificates have CA:FALSE.
• Server certificates contain SANs; Common Name is not used as the only hostname check.
• The chain is verified with OpenSSL, not only inspected visually.
• Expiry, renewal, and revocation are documented as a lifecycle.
• Security topics describe attack surface, detection, and recovery.

Common Mistakes for CRL and OCSP

Submission Example for CRL and OCSP

submission/
  openssl/root-openssl.cnf
  openssl/intermediate-openssl.cnf
  csr/server.csr
  certs/server.crt
  certs/chain.pem
  evidence.md
  cleanup.md

Evidence contains relevant OpenSSL output, not private keys.

8. Registration Authority

Registration Authority is treated as a reviewable PKI building block. The important point is not merely that a command creates a certificate, but that purpose, extensions, trust chain, validity, key usage, and cleanup are understandable.

openssl x509 -in certs/server.crt -noout -subject -issuer -dates
openssl x509 -in certs/server.crt -noout -text | sed -n '/X509v3 extensions:/,/Signature Algorithm/p'
openssl verify -CAfile certs/chain.pem certs/server.crt

A good solution also states whether it is a private lab PKI, an internal enterprise PKI, or publicly trusted TLS. Publicly trusted certificates have additional CA/Browser Forum Baseline Requirements; a lab CA workshop does not replace those requirements.

Practice and Review Expectation for Registration Authority

• Private keys are generated only in the lab and are not committed.
• Configurations use dummy DNs and documentation domains.
• CA certificates have CA:TRUE; end-entity certificates have CA:FALSE.
• Server certificates contain SANs; Common Name is not used as the only hostname check.
• The chain is verified with OpenSSL, not only inspected visually.
• Expiry, renewal, and revocation are documented as a lifecycle.
• Security topics describe attack surface, detection, and recovery.

Common Mistakes for Registration Authority

Submission Example for Registration Authority

submission/
  openssl/root-openssl.cnf
  openssl/intermediate-openssl.cnf
  csr/server.csr
  certs/server.crt
  certs/chain.pem
  evidence.md
  cleanup.md

Evidence contains relevant OpenSSL output, not private keys.

9. Policy Authority

Policy Authority is treated as a reviewable PKI building block. The important point is not merely that a command creates a certificate, but that purpose, extensions, trust chain, validity, key usage, and cleanup are understandable.

openssl x509 -in certs/server.crt -noout -subject -issuer -dates
openssl x509 -in certs/server.crt -noout -text | sed -n '/X509v3 extensions:/,/Signature Algorithm/p'
openssl verify -CAfile certs/chain.pem certs/server.crt

A good solution also states whether it is a private lab PKI, an internal enterprise PKI, or publicly trusted TLS. Publicly trusted certificates have additional CA/Browser Forum Baseline Requirements; a lab CA workshop does not replace those requirements.

Practice and Review Expectation for Policy Authority

• Private keys are generated only in the lab and are not committed.
• Configurations use dummy DNs and documentation domains.
• CA certificates have CA:TRUE; end-entity certificates have CA:FALSE.
• Server certificates contain SANs; Common Name is not used as the only hostname check.
• The chain is verified with OpenSSL, not only inspected visually.
• Expiry, renewal, and revocation are documented as a lifecycle.
• Security topics describe attack surface, detection, and recovery.

Common Mistakes for Policy Authority

Submission Example for Policy Authority

submission/
  openssl/root-openssl.cnf
  openssl/intermediate-openssl.cnf
  csr/server.csr
  certs/server.crt
  certs/chain.pem
  evidence.md
  cleanup.md

Evidence contains relevant OpenSSL output, not private keys.

10. CA Database

CA Database is treated as a reviewable PKI building block. The important point is not merely that a command creates a certificate, but that purpose, extensions, trust chain, validity, key usage, and cleanup are understandable.

openssl x509 -in certs/server.crt -noout -subject -issuer -dates
openssl x509 -in certs/server.crt -noout -text | sed -n '/X509v3 extensions:/,/Signature Algorithm/p'
openssl verify -CAfile certs/chain.pem certs/server.crt

A good solution also states whether it is a private lab PKI, an internal enterprise PKI, or publicly trusted TLS. Publicly trusted certificates have additional CA/Browser Forum Baseline Requirements; a lab CA workshop does not replace those requirements.

Practice and Review Expectation for CA Database

• Private keys are generated only in the lab and are not committed.
• Configurations use dummy DNs and documentation domains.
• CA certificates have CA:TRUE; end-entity certificates have CA:FALSE.
• Server certificates contain SANs; Common Name is not used as the only hostname check.
• The chain is verified with OpenSSL, not only inspected visually.
• Expiry, renewal, and revocation are documented as a lifecycle.
• Security topics describe attack surface, detection, and recovery.

Common Mistakes for CA Database

Submission Example for CA Database

submission/
  openssl/root-openssl.cnf
  openssl/intermediate-openssl.cnf
  csr/server.csr
  certs/server.crt
  certs/chain.pem
  evidence.md
  cleanup.md

Evidence contains relevant OpenSSL output, not private keys.

11. Key Ceremony

Key Ceremony is treated as a reviewable PKI building block. The important point is not merely that a command creates a certificate, but that purpose, extensions, trust chain, validity, key usage, and cleanup are understandable.

openssl x509 -in certs/server.crt -noout -subject -issuer -dates
openssl x509 -in certs/server.crt -noout -text | sed -n '/X509v3 extensions:/,/Signature Algorithm/p'
openssl verify -CAfile certs/chain.pem certs/server.crt

A good solution also states whether it is a private lab PKI, an internal enterprise PKI, or publicly trusted TLS. Publicly trusted certificates have additional CA/Browser Forum Baseline Requirements; a lab CA workshop does not replace those requirements.

Practice and Review Expectation for Key Ceremony

• Private keys are generated only in the lab and are not committed.
• Configurations use dummy DNs and documentation domains.
• CA certificates have CA:TRUE; end-entity certificates have CA:FALSE.
• Server certificates contain SANs; Common Name is not used as the only hostname check.
• The chain is verified with OpenSSL, not only inspected visually.
• Expiry, renewal, and revocation are documented as a lifecycle.
• Security topics describe attack surface, detection, and recovery.

Common Mistakes for Key Ceremony

Submission Example for Key Ceremony

submission/
  openssl/root-openssl.cnf
  openssl/intermediate-openssl.cnf
  csr/server.csr
  certs/server.crt
  certs/chain.pem
  evidence.md
  cleanup.md

Evidence contains relevant OpenSSL output, not private keys.

12. Offline Root

Offline Root is treated as a reviewable PKI building block. The important point is not merely that a command creates a certificate, but that purpose, extensions, trust chain, validity, key usage, and cleanup are understandable.

openssl x509 -in certs/server.crt -noout -subject -issuer -dates
openssl x509 -in certs/server.crt -noout -text | sed -n '/X509v3 extensions:/,/Signature Algorithm/p'
openssl verify -CAfile certs/chain.pem certs/server.crt

A good solution also states whether it is a private lab PKI, an internal enterprise PKI, or publicly trusted TLS. Publicly trusted certificates have additional CA/Browser Forum Baseline Requirements; a lab CA workshop does not replace those requirements.

Practice and Review Expectation for Offline Root

• Private keys are generated only in the lab and are not committed.
• Configurations use dummy DNs and documentation domains.
• CA certificates have CA:TRUE; end-entity certificates have CA:FALSE.
• Server certificates contain SANs; Common Name is not used as the only hostname check.
• The chain is verified with OpenSSL, not only inspected visually.
• Expiry, renewal, and revocation are documented as a lifecycle.
• Security topics describe attack surface, detection, and recovery.

Common Mistakes for Offline Root

Submission Example for Offline Root

submission/
  openssl/root-openssl.cnf
  openssl/intermediate-openssl.cnf
  csr/server.csr
  certs/server.crt
  certs/chain.pem
  evidence.md
  cleanup.md

Evidence contains relevant OpenSSL output, not private keys.

13. HSM/KMS

HSM/KMS is treated as a reviewable PKI building block. The important point is not merely that a command creates a certificate, but that purpose, extensions, trust chain, validity, key usage, and cleanup are understandable.

openssl x509 -in certs/server.crt -noout -subject -issuer -dates
openssl x509 -in certs/server.crt -noout -text | sed -n '/X509v3 extensions:/,/Signature Algorithm/p'
openssl verify -CAfile certs/chain.pem certs/server.crt

A good solution also states whether it is a private lab PKI, an internal enterprise PKI, or publicly trusted TLS. Publicly trusted certificates have additional CA/Browser Forum Baseline Requirements; a lab CA workshop does not replace those requirements.

Practice and Review Expectation for HSM/KMS

• Private keys are generated only in the lab and are not committed.
• Configurations use dummy DNs and documentation domains.
• CA certificates have CA:TRUE; end-entity certificates have CA:FALSE.
• Server certificates contain SANs; Common Name is not used as the only hostname check.
• The chain is verified with OpenSSL, not only inspected visually.
• Expiry, renewal, and revocation are documented as a lifecycle.
• Security topics describe attack surface, detection, and recovery.

Common Mistakes for HSM/KMS

Submission Example for HSM/KMS

submission/
  openssl/root-openssl.cnf
  openssl/intermediate-openssl.cnf
  csr/server.csr
  certs/server.crt
  certs/chain.pem
  evidence.md
  cleanup.md

Evidence contains relevant OpenSSL output, not private keys.

14. Automation

Automation is treated as a reviewable PKI building block. The important point is not merely that a command creates a certificate, but that purpose, extensions, trust chain, validity, key usage, and cleanup are understandable.

openssl x509 -in certs/server.crt -noout -subject -issuer -dates
openssl x509 -in certs/server.crt -noout -text | sed -n '/X509v3 extensions:/,/Signature Algorithm/p'
openssl verify -CAfile certs/chain.pem certs/server.crt

A good solution also states whether it is a private lab PKI, an internal enterprise PKI, or publicly trusted TLS. Publicly trusted certificates have additional CA/Browser Forum Baseline Requirements; a lab CA workshop does not replace those requirements.

Practice and Review Expectation for Automation

• Private keys are generated only in the lab and are not committed.
• Configurations use dummy DNs and documentation domains.
• CA certificates have CA:TRUE; end-entity certificates have CA:FALSE.
• Server certificates contain SANs; Common Name is not used as the only hostname check.
• The chain is verified with OpenSSL, not only inspected visually.
• Expiry, renewal, and revocation are documented as a lifecycle.
• Security topics describe attack surface, detection, and recovery.

Common Mistakes for Automation

Submission Example for Automation

submission/
  openssl/root-openssl.cnf
  openssl/intermediate-openssl.cnf
  csr/server.csr
  certs/server.crt
  certs/chain.pem
  evidence.md
  cleanup.md

Evidence contains relevant OpenSSL output, not private keys.

15. Audit and Evidence

Audit and Evidence is treated as a reviewable PKI building block. The important point is not merely that a command creates a certificate, but that purpose, extensions, trust chain, validity, key usage, and cleanup are understandable.

openssl x509 -in certs/server.crt -noout -subject -issuer -dates
openssl x509 -in certs/server.crt -noout -text | sed -n '/X509v3 extensions:/,/Signature Algorithm/p'
openssl verify -CAfile certs/chain.pem certs/server.crt

A good solution also states whether it is a private lab PKI, an internal enterprise PKI, or publicly trusted TLS. Publicly trusted certificates have additional CA/Browser Forum Baseline Requirements; a lab CA workshop does not replace those requirements.

Practice and Review Expectation for Audit and Evidence

• Private keys are generated only in the lab and are not committed.
• Configurations use dummy DNs and documentation domains.
• CA certificates have CA:TRUE; end-entity certificates have CA:FALSE.
• Server certificates contain SANs; Common Name is not used as the only hostname check.
• The chain is verified with OpenSSL, not only inspected visually.
• Expiry, renewal, and revocation are documented as a lifecycle.
• Security topics describe attack surface, detection, and recovery.

Common Mistakes for Audit and Evidence

Submission Example for Audit and Evidence

submission/
  openssl/root-openssl.cnf
  openssl/intermediate-openssl.cnf
  csr/server.csr
  certs/server.crt
  certs/chain.pem
  evidence.md
  cleanup.md

Evidence contains relevant OpenSSL output, not private keys.

16. Operational Boundaries

Operational Boundaries is treated as a reviewable PKI building block. The important point is not merely that a command creates a certificate, but that purpose, extensions, trust chain, validity, key usage, and cleanup are understandable.

openssl x509 -in certs/server.crt -noout -subject -issuer -dates
openssl x509 -in certs/server.crt -noout -text | sed -n '/X509v3 extensions:/,/Signature Algorithm/p'
openssl verify -CAfile certs/chain.pem certs/server.crt

A good solution also states whether it is a private lab PKI, an internal enterprise PKI, or publicly trusted TLS. Publicly trusted certificates have additional CA/Browser Forum Baseline Requirements; a lab CA workshop does not replace those requirements.

Practice and Review Expectation for Operational Boundaries

• Private keys are generated only in the lab and are not committed.
• Configurations use dummy DNs and documentation domains.
• CA certificates have CA:TRUE; end-entity certificates have CA:FALSE.
• Server certificates contain SANs; Common Name is not used as the only hostname check.
• The chain is verified with OpenSSL, not only inspected visually.
• Expiry, renewal, and revocation are documented as a lifecycle.
• Security topics describe attack surface, detection, and recovery.

Common Mistakes for Operational Boundaries

Submission Example for Operational Boundaries

submission/
  openssl/root-openssl.cnf
  openssl/intermediate-openssl.cnf
  csr/server.csr
  certs/server.crt
  certs/chain.pem
  evidence.md
  cleanup.md

Evidence contains relevant OpenSSL output, not private keys.

Sources and Further References

• RFC 5280: https://datatracker.ietf.org/doc/html/rfc5280
• CA/Browser Forum Baseline Requirements: https://cabforum.org/working-groups/server/baseline-requirements/requirements/
• CA/Browser Forum TLS BR Documents: https://cabforum.org/working-groups/server/baseline-requirements/documents/
• NIST SP 800-57 Part 1 Rev. 5: https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final
• NIST SP 800-57 Rev. 6 Initial Public Draft: https://csrc.nist.gov/pubs/sp/800/57/pt1/r6/ipd
• OpenSSL Documentation: https://docs.openssl.org/
• OpenSSL ca: https://docs.openssl.org/3.0/man1/openssl-ca/
• OpenSSL x509: https://docs.openssl.org/3.0/man1/openssl-x509/
• Let's Encrypt Documentation: https://letsencrypt.org/docs/
• HashiCorp Vault PKI Secrets Engine: https://developer.hashicorp.com/vault/docs/secrets/pki
• cert-manager Documentation: https://cert-manager.io/docs/
• Smallstep Documentation: https://smallstep.com/docs/

Practice Appendix: CA Evidence for this reference document

This appendix makes the file more complete as workshop material: it connects the topic with repeatable evidence, review questions, operational decisions and security expectations. The points are not invented product features; they are real review criteria for PKI work with X.509, OpenSSL and common CA operating models.

A.1 Scope and Boundary

Every CA task starts by separating a private lab PKI, an internal enterprise PKI and publicly trusted server certificates. That distinction changes responsibilities, audit requirements, validity periods, revocation handling and which clients may trust the certificate.

Concrete review questions:

• Which entity is protected or signed?
• Which file or output backs the statement?
• Which role is played by the root, intermediate, leaf or client?
• Which assumption needs additional production review?
• Which change must be traceable in audit?
• Which cleanup or protection step prevents accidental secret leaks?

A.2 Trust Model

The trust model states which root is distributed as trust anchor, which intermediates may sign and which relying parties evaluate the chain. Without that model a technically valid certificate can still be operationally unclear.

Concrete review questions:

• Which entity is protected or signed?
• Which file or output backs the statement?
• Which role is played by the root, intermediate, leaf or client?
• Which assumption needs additional production review?
• Which change must be traceable in audit?
• Which cleanup or protection step prevents accidental secret leaks?

A.3 Root CA Handling

A root CA is a local learning artifact in this workshop. In real environments the root key is kept offline or in an HSM and controlled through ceremonies, separated roles, logs and recovery plans.

Concrete review questions:

• Which entity is protected or signed?
• Which file or output backs the statement?
• Which role is played by the root, intermediate, leaf or client?
• Which assumption needs additional production review?
• Which change must be traceable in audit?
• Which cleanup or protection step prevents accidental secret leaks?

A.4 Intermediate CA Operations

Intermediate CAs are the operational signing layer. Their certificates need CA:TRUE, keyCertSign, cRLSign, suitable path length constraints and a clear lifecycle and rotation plan.

Concrete review questions:

• Which entity is protected or signed?
• Which file or output backs the statement?
• Which role is played by the root, intermediate, leaf or client?
• Which assumption needs additional production review?
• Which change must be traceable in audit?
• Which cleanup or protection step prevents accidental secret leaks?

A.5 Registration Authority

The RA or approval function decides whether a request may be signed. For internal servers this means at least system owner, DNS name, environment, purpose, lifetime, responsible team and change window are traceable.

Concrete review questions:

• Which entity is protected or signed?
• Which file or output backs the statement?
• Which role is played by the root, intermediate, leaf or client?
• Which assumption needs additional production review?
• Which change must be traceable in audit?
• Which cleanup or protection step prevents accidental secret leaks?

A.6 Private Key Protection

Private keys are the most sensitive PKI asset. Repositories should contain configurations, CSRs, public certificates and evidence only. Keys are created below work/ in labs or in protected systems and are not committed.

Concrete review questions:

• Which entity is protected or signed?
• Which file or output backs the statement?
• Which role is played by the root, intermediate, leaf or client?
• Which assumption needs additional production review?
• Which change must be traceable in audit?
• Which cleanup or protection step prevents accidental secret leaks?

A.7 CSR Review

A CSR proves possession of a private key, but not authorization for a name. Review the subject, SANs, public key algorithm, key size, requester and intended certificate type.

Concrete review questions:

• Which entity is protected or signed?
• Which file or output backs the statement?
• Which role is played by the root, intermediate, leaf or client?
• Which assumption needs additional production review?
• Which change must be traceable in audit?
• Which cleanup or protection step prevents accidental secret leaks?

A.8 X.509 Extensions

Extensions are security logic, not decoration. Basic constraints, key usage, extended key usage, subject alternative name, subject key identifier and authority key identifier define what a certificate may be accepted for.

Concrete review questions:

• Which entity is protected or signed?
• Which file or output backs the statement?
• Which role is played by the root, intermediate, leaf or client?
• Which assumption needs additional production review?
• Which change must be traceable in audit?
• Which cleanup or protection step prevents accidental secret leaks?

A.9 SAN and Naming Model

Server identity is checked through SANs. The common name alone is not sufficient for modern hostname verification. Internal namespaces, documentation domains and production domains must remain separate.

Concrete review questions:

• Which entity is protected or signed?
• Which file or output backs the statement?
• Which role is played by the root, intermediate, leaf or client?
• Which assumption needs additional production review?
• Which change must be traceable in audit?
• Which cleanup or protection step prevents accidental secret leaks?

A.10 Chain Verification

A reliable check separates trust anchor and chain certificates. In practice: root through -CAfile, intermediate through -untrusted, leaf as the target certificate and hostname verification where needed.

Concrete review questions:

• Which entity is protected or signed?
• Which file or output backs the statement?
• Which role is played by the root, intermediate, leaf or client?
• Which assumption needs additional production review?
• Which change must be traceable in audit?
• Which cleanup or protection step prevents accidental secret leaks?

A.11 Revocation

Revocation is an operating process, not an afterthought. CRL or OCSP data must be produced, published, monitored and actually consumed by relevant clients.

Concrete review questions:

• Which entity is protected or signed?
• Which file or output backs the statement?
• Which role is played by the root, intermediate, leaf or client?
• Which assumption needs additional production review?
• Which change must be traceable in audit?
• Which cleanup or protection step prevents accidental secret leaks?

A.12 Expiry and Renewal

Certificates need a renewal window before they become critical. The decision covers a new serial, new signature, optionally a new key, rollout order and rollback plan.

Concrete review questions:

• Which entity is protected or signed?
• Which file or output backs the statement?
• Which role is played by the root, intermediate, leaf or client?
• Which assumption needs additional production review?
• Which change must be traceable in audit?
• Which cleanup or protection step prevents accidental secret leaks?

A.13 Automation

Automation through Vault PKI, cert-manager, ACME, Smallstep or SPIFFE reduces manual work, but does not replace policy. Roles, TTLs, issuers, approvers and audit remain explicit.

Concrete review questions:

• Which entity is protected or signed?
• Which file or output backs the statement?
• Which role is played by the root, intermediate, leaf or client?
• Which assumption needs additional production review?
• Which change must be traceable in audit?
• Which cleanup or protection step prevents accidental secret leaks?

A.14 Audit and Evidence

Evidence must show what was created, checked and approved. Good evidence contains OpenSSL output, fingerprints, serial numbers, chain verification, CRL or OCSP status and no secrets.

Concrete review questions:

• Which entity is protected or signed?
• Which file or output backs the statement?
• Which role is played by the root, intermediate, leaf or client?
• Which assumption needs additional production review?
• Which change must be traceable in audit?
• Which cleanup or protection step prevents accidental secret leaks?

A.15 Incident Response

For key compromise the order matters: identify affected serials, revoke, update CRL or OCSP, issue replacements, notify operators, preserve logs and document the root cause.

Concrete review questions:

• Which entity is protected or signed?
• Which file or output backs the statement?
• Which role is played by the root, intermediate, leaf or client?
• Which assumption needs additional production review?
• Which change must be traceable in audit?
• Which cleanup or protection step prevents accidental secret leaks?

A.16 Policy and CPS

A Certificate Policy describes what is allowed. A Certification Practice Statement describes how it is operated. Even private PKIs benefit from this separation because it stabilizes review and operations.

Concrete review questions:

• Which entity is protected or signed?
• Which file or output backs the statement?
• Which role is played by the root, intermediate, leaf or client?
• Which assumption needs additional production review?
• Which change must be traceable in audit?
• Which cleanup or protection step prevents accidental secret leaks?

A.17 Environment

WSL, VMs, bare metal and cloud differ in trust store behavior, file permissions, package versions and paths. Commands and evidence must therefore name the local environment.

Concrete review questions:

• Which entity is protected or signed?
• Which file or output backs the statement?
• Which role is played by the root, intermediate, leaf or client?
• Which assumption needs additional production review?
• Which change must be traceable in audit?
• Which cleanup or protection step prevents accidental secret leaks?

A.18 Security Hardening

Hardening covers file permissions, separated roles, short lifetimes, minimal EKUs, safe algorithms, offline root, controlled intermediates and monitoring for expiry or unusual issuance.

Concrete review questions:

• Which entity is protected or signed?
• Which file or output backs the statement?
• Which role is played by the root, intermediate, leaf or client?
• Which assumption needs additional production review?
• Which change must be traceable in audit?
• Which cleanup or protection step prevents accidental secret leaks?

A.19 Troubleshooting

PKI troubleshooting starts with the chain: does the private key match, is the CSR correct, was the certificate signed correctly, is the chain complete and does the client trust the root?

Concrete review questions:

• Which entity is protected or signed?
• Which file or output backs the statement?
• Which role is played by the root, intermediate, leaf or client?
• Which assumption needs additional production review?
• Which change must be traceable in audit?
• Which cleanup or protection step prevents accidental secret leaks?

A.20 Team Workflow

In workshops and real teams one person should create, a second person should review and a third person should be able to reproduce the evidence. This makes PKI mistakes visible earlier.

Concrete review questions:

• Which entity is protected or signed?
• Which file or output backs the statement?
• Which role is played by the root, intermediate, leaf or client?
• Which assumption needs additional production review?
• Which change must be traceable in audit?
• Which cleanup or protection step prevents accidental secret leaks?

A.21 Submission Format

A solid submission contains configuration, public artifacts, evidence, failure analysis, cleanup notes and a short operational assessment. Private keys and production data are intentionally absent.

Concrete review questions:

• Which entity is protected or signed?
• Which file or output backs the statement?
• Which role is played by the root, intermediate, leaf or client?
• Which assumption needs additional production review?
• Which change must be traceable in audit?
• Which cleanup or protection step prevents accidental secret leaks?

A.22 Production Transfer

Moving from lab to production is not copying OpenSSL commands. It requires roles, safe key storage, monitoring, backup, revocation distribution, documentation and regularly practiced recovery.

Concrete review questions:

• Which entity is protected or signed?
• Which file or output backs the statement?
• Which role is played by the root, intermediate, leaf or client?
• Which assumption needs additional production review?
• Which change must be traceable in audit?
• Which cleanup or protection step prevents accidental secret leaks?

A.23 Minimal Evidence Set

evidence/
  context.md
  openssl-version.txt
  csr-review.txt
  certificate-summary.txt
  certificate-extensions.txt
  chain-verification.txt
  revocation-or-renewal-note.md
  cleanup.md

This set is intentionally minimal. Advanced exercises add CA database state, CRL, OCSP response, audit log, policy excerpt, role decision and incident timeline.

A.24 Quality Criteria

• The technical scope is clear before execution.
• The chain is technically verified, not only described.
• SAN, key usage, EKU and basic constraints are explicitly evaluated.
• Revocation and renewal are covered as lifecycle concerns.
• Private keys stay outside versioned content.
• Public standards are separated correctly: RFC 5280 describes profile and processing, the CA/Browser Forum governs publicly trusted server certificates, and NIST SP 800-57 informs key management and lifetimes.