Question

Difficulty: HardPublic Key Infrastructure and Certificate Management

A security administrator is configuring a new high-security internal microservice that requires a valid server TLS certificate. Enterprise policy mandates hardware key protection, accurate Subject Alternative Name (SAN) extension mapping, intermediate CA trust anchoring, and OCSP stapling to eliminate direct client queries to the Certificate Authority. In what order should the administrator perform the following steps to deploy the certificate and enable OCSP stapling?

  1. 1Generate a private key within a Trusted Platform Module (TPM) and create a Certificate Signing Request (CSR) containing the required SAN extensions.
  2. 2Submit the CSR to the enterprise intermediate Certificate Authority (CA) for identity verification and digital signature.
  3. 3Install the issued X.509 server certificate and intermediate CA certificate chain onto the microservice server.
  4. 4Configure the microservice web server to query the CA's OCSP responder to fetch and cache a timestamped OCSP response.
  5. 5Enable OCSP stapling on the microservice server to attach the cached OCSP response during client TLS handshakes.

Answer

The correct sequence begins with generating the private key and CSR with SAN attributes, followed by submitting the CSR to the intermediate CA for issuance, installing the server certificate and intermediate CA chain, querying and caching the timestamped OCSP response from the responder, and finally enabling OCSP stapling on the web server.
The proper sequence follows standard PKI lifecycle principles: key generation and CSR creation must precede CA submission and signing. Once the CA returns the signed certificate, installing it along with the intermediate CA chain establishes local service readiness. Next, the server must query the OCSP responder to cache a valid, time-stamped status assertion. Finally, enabling OCSP stapling allows the server to serve this cached status to clients during TLS negotiation.

Step-by-Step Solution

1
Generate key pair and create CSR
A CSR containing the public key and SAN extensions is created, while the private key remains protected in the hardware module.
PKI certificate issuance requires a CSR that includes the public key and identity information before contacting a CA.
2
Submit CSR to Intermediate CA
The CA validates the request, signs the certificate, and returns the signed X.509 certificate.
The CA must sign the public key and SAN details to establish authenticity and issue the valid certificate.
3
Install server certificate and trust chain
The web server is configured with its identity certificate and intermediate CA chain.
The server requires the certificate and full intermediate chain to establish trust with clients during TLS handshakes.
4
Fetch and cache OCSP response
The server securely queries the CA's OCSP responder and receives a signed status payload.
OCSP stapling requires the server itself to periodically contact the OCSP responder and cache the time-stamped proof of validity.
5
Enable OCSP stapling for TLS handshakes
Connecting clients receive the server's OCSP response directly during the TLS handshake.
OCSP stapling delivers the pre-fetched revocation status to the client during negotiation, eliminating client-side CA lookup latency and preserving privacy.

Key Concept

PKI Certificate Enrollment and OCSP Stapling Lifecycle Workflow
Estimated Time:2m 0s
Rate this question