An enterprise security team is upgrading its internal 802.1X EAP-TLS network authentication infrastructure. During validation testing, corporate endpoints fail to establish a TLS tunnel with the RADIUS server, returning certificate trust and capability errors. Further inspection confirms that the root and subordinate Intermediate CA certificates are properly installed in the endpoint trust stores. Which of the following certificate misconfigurations would cause endpoints to reject the RADIUS server certificate? (Select TWO.)
- The certificate lacks an Extended Key Usage (EKU) extension explicitly defining Server Authentication.Answer
- The certificate omits the Subject Alternative Name (SAN) extension, relying solely on the Subject Common Name (CN) field.Answer
- CThe Certificate Signing Request (CSR) was forwarded to target client supplicants for validation prior to Intermediate CA signing.
- DThe server certificate uses SHA-256 hashing, which eliminates the requirement for asymmetric digital signatures.
- EThe Certificate Authority generated symmetric AES-256 keys to establish asymmetric certificate trust chains.
Answer
The authentication failures are caused by omitting the Extended Key Usage (EKU) extension specifying Server Authentication and omitting the Subject Alternative Name (SAN) extension required for modern hostname and identity validation.
For an 802.1X EAP-TLS authentication server certificate to be validated successfully by endpoints, it must contain specific X.509 v3 extensions. First, the Extended Key Usage (EKU) field must explicitly specify Server Authentication so client supplicants verify the certificate's intended operational role. Second, modern clients strictly enforce RFC 6125 standards and require the Subject Alternative Name (SAN) extension to match server identity attributes. Omitting either extension leads to validation failure despite having trusted root and intermediate certificates.
Step-by-Step Solution
Key Concept
X.509 v3 Extension Attributes and Endpoint Validation Rules