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?
- Generate a new Certificate Signing Request (CSR) requesting the Client Authentication EKU extension and submit it to the Certificate Authority for issuance.Cevap
- BExport the private keys from the API gateways and embed them into the client microservice configuration files to enable non-repudiation hashing.
- CReplace the asymmetric certificate authentication mechanism with a shared symmetric pre-shared key (PSK) across all microservices.
- DInstall 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
Anahtar Kavram
Extended Key Usage (EKU) extensions in PKI certificate issuance