Certificate Services Rollout for 802.1X Wireless
Fabrikam is deploying WPA2-Enterprise wireless with PEAP-MSCHAPv2 for 2,500 domain-joined laptops and 300 non-domain mobile devices. They plan to stand up an internal enterprise certification authority (CA) to issue server certificates to the NPS/RADIUS servers and client certificates to laptops. The security team insists clients validate the RADIUS server certificate. The network team wants a single standalone root CA and an issuing enterprise CA. The company has one AD forest with two domains. There is no existing PKI. Laptops are managed by Group Policy; mobile devices are enrolled manually by IT.
1. Evaluate the proposed CA hierarchy (standalone root + enterprise issuing CA) against the requirements and recommend a design, including where the root should be kept.
Read the worked answer
The two-tier design is appropriate and matches best practice: an offline standalone root CA that issues only the issuing CA's certificate, and an enterprise issuing CA joined to the domain that auto-enrolls certificates via Group Policy.
Recommendations:
- Root CA: keep it offline (powered down, physically secured) after issuing the subordinate CA certificate. Its only job is to sign the issuing CA cert and publish its CRL/AIA. Because it is standalone, it cannot use AD auto-enrollment, which is fine.
- Issuing CA: enterprise, domain-joined, running on a hardened member server (not a DC). It publishes CRLs and AIA to an HTTP location reachable by all clients, including non-domain mobile devices.
- Validity and CRL: root 15-20 years, issuing CA 5-10 years, CRL overlap configured so clients can always fetch a current CRL.
- Single forest, two domains: one enterprise CA can serve both domains if trust and permissions allow; ensure the CA's enrollment permissions and the Certificate Templates ACLs grant the appropriate groups in both domains.
Risk: a standalone root that is brought online frequently defeats the purpose; document the offline procedure.
2. Clients must validate the RADIUS server certificate. What must be configured on the NPS servers and in the client (GPO) supplicant settings to make validation succeed without user prompts?
Read the worked answer
On the NPS/RADIUS servers:
- Request a server certificate from the enterprise CA using the RAS and IAS Server template (or a custom template with Server Authentication EKU), with the server's FQDN in the subject/SAN.
- Bind the certificate in NPS (Network Policy Server > properties > certificate) and ensure the private key is present.
On the clients via GPO (Wireless Network (IEEE 802.11) Policy):
- Authentication: PEAP, with inner method MSCHAPv2.
- Under PEAP properties, Validate server certificate enabled, and select the trusted root CA (the offline root) as the trusted authority.
- Specify the server name(s) the client should expect (the NPS server FQDNs), so the client rejects any other server presenting a valid cert.
- Do not prompt users to authorize new servers.
Validation: connect a test laptop and confirm the event log shows successful EAP authentication; use netsh wlan show profiles and the NPS accounting log to confirm the certificate chain was accepted.
3. The 300 non-domain mobile devices must also authenticate. How should certificate enrollment and trust be handled for them, and what are the main risks?
Read the worked answer
Non-domain devices cannot use AD auto-enrollment, so they need an out-of-band enrollment path:
- Manual/key-based enrollment: IT requests certificates on behalf of users via the CA Web Enrollment page or a certificate request, then installs the certificate and the root CA certificate on each device so it trusts the chain.
- SCEP/NDES can be added later for scalable enrollment if the mobile platform supports it, but that adds infrastructure.
Risks:
- Trust distribution: without the root CA installed, devices will fail server validation; this must be part of the provisioning checklist.
- Private key protection: manually issued certs may be exported or shared; enforce device passcodes and short validity.
- Revocation: if a device is lost, its certificate must be revoked and the CRL must be reachable by the NPS servers; test CRL publishing.
- Scale: manual enrollment for 300 devices is operational overhead; consider a managed MDM or SCEP path as a follow-on.
Document the provisioning steps and verify a sample device authenticates and that a revoked certificate is rejected.