The certificate's Common Name (CN) and Subject Alternative Name (SAN) use the arubalab.local domain. The .local top-level domain (TLD) is reserved for specific uses like Multicast DNS (mDNS) within a local network and is not a globally unique, routable domain. Best practices for Public Key Infrastructure (PKI) and requirements from the CA/Browser Forum prohibit the use of such internal-only names in publicly trusted certificates. While this certificate is from an internal CA, using a .local FQDN can cause validation failures on client devices (supplicants) whose operating systems or security policies do not trust or cannot resolve this type of address, which is a critical issue for EAP authentication.

A: The certificate's subject common name is cppm.arubalab.local. This is a specific hostname and does not contain a wildcard () character.

C: A Uniform Resource Identifier (URI) in the Subject Alternative Name is not a standard or mandatory requirement for RADIUS/EAP or RadSec server certificates.

D: An IP address in the Subject Alternative Name is only necessary if clients are configured to connect to the server via its IP address. Standard practice is to use the FQDN.

1. Aruba ClearPass Deployment Guide: In sections discussing certificate usage

the guide consistently refers to using a Fully Qualified Domain Name (FQDN) that is resolvable by clients. For example

the ClearPass 6.7 Deployment Guide states

"The FQDN of the certificate must be resolvable by the clients." (p. 110). A .local address is not universally resolvable and relies on local network configurations (mDNS or internal DNS)

which can cause validation to fail on many supplicants.

2. CA/Browser Forum

Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates: While this standard applies to public CAs

its principles are considered PKI best practices. Version 1.3.0 (and subsequent versions) officially deprecated the issuance of certificates for internal server names and reserved IP addresses. Section 7.1.4.2.1 explicitly states CAs must not issue certificates containing internal names

which includes any name that does not end in a public TLD. This established the industry-wide practice of avoiding names like .local for interoperability and security.

3. RFC 6762 - Multicast DNS: This IETF standard formally reserves the .local TLD for use with Multicast DNS. "The domain name "local" is a special-use domain name reserved for hostnames in local networks. [...] Any DNS query for a name ending in ".local" MUST be sent to the mDNS IPv4 link-local multicast address" (Section 3). This confirms that .local is not a standard DNS name and can cause resolution conflicts or failures in environments not configured for mDNS.