Soru

Zorluk: OrtaPublic Key Infrastructure and Certificate Management

A security systems engineer is deploying mutual TLS (mTLS) for communication between internal microservices. During testing, client microservice instances fail to authenticate to target API gateways. Inspection of the certificate validation logs reveals that the client certificates were rejected because their Extended Key Usage (EKU) attribute is configured exclusively for "Server Authentication" (1.3.6.1.5.5.7.3.1) rather than "Client Authentication" (1.3.6.1.5.5.7.3.2). Which of the following actions should the security engineer take to resolve the authentication failures while adhering to PKI best practices?

  1. Generate a new Certificate Signing Request (CSR) requesting the Client Authentication EKU extension and submit it to the Certificate Authority for issuance.Cevap
  2. B
    Export the private keys from the API gateways and embed them into the client microservice configuration files to enable non-repudiation hashing.
  3. C
    Replace the asymmetric certificate authentication mechanism with a shared symmetric pre-shared key (PSK) across all microservices.
  4. D
    Install the client certificates directly into the Root CA trusted store prior to generating the Certificate Signing Request (CSR).

Cevap

Generate a new Certificate Signing Request (CSR) requesting the Client Authentication EKU extension and submit it to the Certificate Authority for issuance.
Generating a new Certificate Signing Request (CSR) with the Client Authentication EKU extension directly addresses the root cause of the mTLS handshake failure. PKI certificates explicitly define their intended applications via Key Usage and Extended Key Usage fields; client-side mTLS endpoints require the Client Authentication object identifier (1.3.6.1.5.5.7.3.2) to pass validation.

Adım Adım Çözüm

1
Analyze the error log
Identified that the client certificate lacks the required Client Authentication EKU extension.
During a TLS handshake, mutual authentication requires the client certificate to explicitly allow client identity verification.
2
Determine the proper PKI issuance workflow
Create a updated CSR with the correct Extended Key Usage extension requested.
Certificate attributes such as EKU cannot be modified post-issuance; a new CSR must be signed by the CA.
3
Deploy and test the newly issued certificate
The client microservice presents a valid certificate containing Client Authentication EKU, resolving the mTLS handshake failure.
The API gateway trusts the CA and successfully verifies the EKU field during peer authentication.

Anahtar Kavram

Extended Key Usage (EKU) extensions in PKI certificate issuance
Bu soruyu puanla