Certificate Management for EAP-TLS and RadSec
A financial institution is deploying EAP-TLS for wireless 802.1X using Aruba ClearPass and Mobility Controllers. They have 10,000 employee devices (Windows, macOS, iOS) and 2,000 IoT devices. The security team wants to use certificates for both user and device authentication (dual-EAP-TLS). They plan to use an internal Microsoft Certificate Authority (CA) for issuing certificates to domain-joined devices via auto-enrollment, and a separate CA for IoT devices. ClearPass will validate certificates using OCSP. The institution also wants to secure RADIUS traffic between the Aruba controllers and ClearPass using RadSec (RADIUS over TLS). The network team is concerned about certificate revocation checking latency and the impact on authentication times. They also need to ensure that the ClearPass server certificate is trusted by all clients and that the controllers trust ClearPass for RadSec. The institution has a strict change management policy requiring certificate renewals to be seamless.
1. Design the certificate infrastructure and ClearPass configuration to support dual-EAP-TLS with OCSP validation, addressing revocation latency and seamless renewal. Include how to handle IoT certificates from a separate CA.
Read the worked answer
Certificate Infrastructure:
- Use Microsoft CA for employees: issue user certificates (for EAP-TLS user auth) and device certificates (for device auth) via auto-enrollment with Group Policy. For dual-EAP-TLS, the supplicant presents both user and machine certificates; ClearPass must validate both.
- For IoT, use a separate CA (e.g., OpenSSL or public CA) to issue device certificates. Ensure the IoT CA is trusted by ClearPass.
ClearPass Configuration:
- Import the root and intermediate certificates of both CAs into ClearPass trusted certificates store.
- Create a certificate authentication source for EAP-TLS that validates the certificate chain and checks revocation via OCSP. Configure OCSP responder URLs in the certificates (AIA field).
- To reduce latency, enable OCSP caching in ClearPass (if supported) or use CRL with a local cache. Alternatively, configure OCSP stapling on the CA side if possible. ClearPass can cache OCSP responses for a configurable period; set it to a reasonable time (e.g., 1 hour) to balance freshness and performance.
- For dual-EAP-TLS, create an enforcement policy that requires both user and device certificate authentication. In ClearPass, the EAP-TLS authentication can be configured to request both certificates; the service will validate both. Role mapping can check attributes from both certificates (e.g., user principal name and device serial).
Seamless Renewal:
- Configure certificate templates with auto-renewal and overlapping validity (e.g., renew when 80% of lifetime is reached). Ensure ClearPass accepts both old and new certificates during the overlap period by not enforcing strict serial number matching. Use OCSP to check revocation; old certificates remain valid until expiry.
- For IoT, implement a renewal process (e.g., SCEP or EST) that allows devices to obtain new certificates before expiry. ClearPass should trust the CA and validate new certificates automatically.
RadSec:
- Obtain a server certificate for ClearPass from a trusted CA (internal or public) with the FQDN of the ClearPass server. Ensure controllers trust the CA that issued the ClearPass certificate.
- Configure RadSec on ClearPass (enable RadSec service on port 2083) and on Aruba controllers (specify RadSec profile with ClearPass FQDN and trusted CA). Use TLS 1.2+ with strong ciphers.
- Ensure controllers have the CA certificate installed to validate ClearPass's RadSec certificate.
Client Trust:
- Distribute the ClearPass server certificate's root CA to all clients (via GPO/MDM) so they trust the server during EAP-TLS. For IoT, pre-install the CA certificate.
This design addresses OCSP latency via caching, seamless renewal via overlapping validity, and secure RadSec with proper certificate trust.
2. What are the risks of using OCSP without caching, and how would you monitor and troubleshoot OCSP-related authentication failures in ClearPass?
Read the worked answer
Risks of OCSP without caching:
- Increased authentication latency: each EAP-TLS authentication triggers an OCSP request to the CA, adding network round-trip time. With 10,000 devices, this can cause significant delays and timeouts.
- OCSP responder unavailability: if the OCSP responder is down or unreachable, authentication may fail or fall back to CRL, causing outages.
- Scalability: high volume of OCSP requests can overload the responder, leading to failures.
- Privacy: OCSP requests reveal certificate serial numbers to the CA, but this is inherent.
Monitoring and troubleshooting:
- In ClearPass, enable detailed logging for certificate authentication. Use the Access Tracker to view authentication events; filter by EAP-TLS and check for OCSP errors in the logs.
- Configure ClearPass to log OCSP response times and status. Use the ClearPass Insight or external syslog to monitor trends.
- Set up alerts for OCSP failures (e.g., via ClearPass Policy Manager alerts or SNMP traps).
- Test OCSP connectivity from ClearPass to the OCSP responder using tools like openssl ocsp. Ensure DNS resolution and firewall rules allow traffic.
- If OCSP fails, ClearPass may be configured to soft-fail (allow authentication) or hard-fail (deny). For security, hard-fail is recommended, but with caching to mitigate. Monitor for soft-fail events if configured.
- Use ClearPass OnGuard or endpoint profiling to detect clients with revoked certificates and remediate.
- For troubleshooting, capture packets on ClearPass to see OCSP requests/responses. Check the CA's OCSP responder logs for errors.
To mitigate risks, implement OCSP caching and consider CRL as a fallback with caching. Monitor latency and failure rates to ensure authentication performance.