Question

Difficulty: HardPublic Key Infrastructure and Certificate Management

A security engineer is establishing a secure mutual TLS (mTLS) framework between microservices operating within air-gapped container clusters. During deployment testing, client microservices fail TLS handshakes because they cannot reach external certificate revocation lists (CRLs) or online responders to check server certificate validity. Additionally, security compliance mandates that private keys must originate exclusively within the local trusted execution environment of each microservice during certificate enrollment. Which of the following solutions should the engineer implement to resolve the revocation validation failures and satisfy the key generation compliance requirement? (Select TWO.)

  1. Configure server-side microservices to utilize OCSP stapling, enabling them to include a time-stamped, CA-signed revocation status assertion directly within the TLS handshake.Answer
  2. Ensure each client microservice generates its asymmetric key pair locally inside its local hardware security module and submits only the public key within the Certificate Signing Request (CSR) to the CA.Answer
  3. C
    Configure the Certificate Authority to generate both public and private keys centrally during enrollment and distribute the key pair to client microservices inside PKCS#12 containers.
  4. D
    Replace the asymmetric certificate key pair with a shared symmetric AES-256 key embedded inside the subject alternative name (SAN) extension of the X.509 certificate.
  5. E
    Substitute digital signature validation with standalone SHA-256 payload hashing in HTTP headers to guarantee identity non-repudiation without performing PKI trust chain checks.

Answer

The security engineer should enable OCSP stapling on the server-side microservices and require each client microservice to generate its key pair locally inside its hardware security module prior to submitting a CSR.
Enabling OCSP stapling resolves the revocation checking issue in air-gapped environments because the server periodically retrieves the signed OCSP response and delivers it directly to the client during the TLS handshake, eliminating the need for client outbound access. Furthermore, generating key pairs locally within an HSM and submitting only the public key in the Certificate Signing Request (CSR) ensures the private key never leaves the client boundary.

Step-by-Step Solution

1
Analyze the certificate revocation validation failure in an isolated, air-gapped network segment.
Identify that clients cannot initiate outbound connections to check CRL or OCSP endpoints external to the cluster.
Air-gapped environments block direct internet or cross-segment egress traffic from client nodes.
2
Select a revocation mechanism that delivers status proof without client-initiated outbound traffic.
Implement OCSP stapling on server microservices.
The server periodically fetches the signed OCSP response from the CA/responder and appends ('staples') it to the TLS handshake, allowing the client to verify revocation offline.
3
Evaluate the key generation requirement for certificate enrollment.
Enforce local key generation within the microservice's local hardware security module (HSM) / secure enclave before creating the Certificate Signing Request (CSR).
Submitting a CSR with a locally generated public key guarantees the private key is never exposed or transferred across network boundaries.

Key Concept

PKI Certificate Lifecycle & Revocation Optimization (OCSP Stapling and CSR Key Management)
Estimated Time:2m 0s
Rate this question