Skip to main content

Setting Up a Microsoft CA for EAP-TLS Authentication

Setting Up a Microsoft CA for EAP-TLS Authentication

Tutorial | Windows Server 2022 | Audience: Junior IT Admins

Table of Contents

  1. Introduction
  2. Prerequisites
  3. Part 1 — Installing Active Directory Certificate Services (AD CS)
  4. Part 2 — Configuring the CA and Certificate Templates
  5. Part 3 — Deploying Device Certificates to Windows Devices
  6. Part 4 — Deploying Device Certificates to Apple Devices
  7. Part 5 — Deploying Device Certificates to Chromebooks
  8. Troubleshooting
  9. Next Steps

Introduction

By the end of this tutorial, you will have a working Microsoft Certificate Authority (CA) running on Windows Server 2022 that automatically issues device certificates to your Windows, Apple, and Chromebook devices. Those certificates will be used to authenticate devices to your Wi-Fi network using EAP-TLS.

Key concepts (plain English)

Before diving in, it helps to understand a few terms you will see throughout this tutorial:

  • Certificate Authority (CA): Think of this as your organization's ID card printer. It issues digital certificates that prove a device is trusted. Because you run the CA, you decide what gets a certificate — and your RADIUS server will only let in devices that have one.

  • EAP-TLS: A method for authenticating to a Wi-Fi network using a certificate instead of a password. It is significantly more secure than password-based methods because there is no shared secret that can be stolen or guessed.

  • Device-based certificate: The certificate is tied to the machine itself, not to a specific user account. This means any user who logs into that device can connect to the network, and devices can authenticate even before a user logs in.

  • SCEP (Simple Certificate Enrollment Protocol): A protocol that allows devices to request and receive certificates automatically over the network. Apple devices and Chromebooks use SCEP to obtain certificates, since they cannot use Windows Group Policy.

  • NDES (Network Device Enrollment Service): A Windows role service that provides the SCEP endpoint. It acts as a go-between — devices send their certificate requests to NDES, and NDES forwards them to your CA.

Architecture overview

+-------------------------------+       issues certs        +---------------------+
|  Windows Server 2022          |  -----------------------> |  Windows Devices    |
|                               |  (Group Policy / AD)      |                     |
|  Roles installed:             |  -----------------------> |  Apple Devices      |
|  - Certification Authority    |  (SCEP via NDES)          |  (via iMazing + MDM)|
|  - NDES                       |                           |                     |
|  - Online Responder           |  <-- Google Cloud Cert    |  Chromebooks        |
|  - Web Enrollment             |      Connector (SCEP)     |  (via GCC)          |
+-------------------------------+                           +---------------------+
              |                                                       |
              |                                              presents cert
              |                                                       |
              v                                                       v
+-------------------+          validates             +---------------------+
|  PacketFence      |  <-----------------------------| Wi-Fi Access Point  |
|  (RADIUS Server)  |                                | (802.1X)            |
+-------------------+                                +---------------------+

When a device connects to your Wi-Fi network, it presents its certificate to the access point, which forwards it to PacketFence (your RADIUS server). PacketFence checks that the certificate was issued by your CA and, if so, grants the device access.

Prerequisites

Before you begin, make sure the following are in place.

Infrastructure

Requirement Details
Windows Server 2022 A domain-joined server dedicated to the CA role. Do not install the CA on a Domain Controller.
Active Directory Domain Services (AD DS) Your domain must already be set up and running.
PacketFence Installed and reachable on your network. Configuration of PacketFence is outside the scope of this tutorial.
Google Workspace (for Chromebooks) Admin Console access with Chromebooks enrolled in your domain.
MDM solution (for Apple devices) Such as Jamf, Mosyle, or Kandji. iMazing Profile Editor will be used to build the profile.

Software to download

  • iMazing Profile Editor — Free download from imazing.com/profile-editor
  • Google Cloud Certificate Connector — Downloaded from the Google Admin Console during Part 5

Accounts and permissions

  • A domain account that is a member of Enterprise Admins for the CA installation
  • A dedicated service account for NDES (e.g., svc-ndes) — a standard domain user account with no special permissions to start; the wizard will configure it
  • Google Admin super-admin access for the Chromebook section

A note on the NDES service account

NDES requires its own dedicated domain service account. Create this account in Active Directory before starting Part 1. Set the password to never expire and do not grant it any special permissions yet — the NDES configuration wizard will assign the permissions it needs.

A note on server sizing: The CA and NDES roles are not resource-intensive. 2 vCPUs and 4 GB RAM is sufficient for most environments. What matters most is that the server is reliable and well-backed-up. If you lose your CA without a backup, you will need to re-issue every certificate in your environment.

Part 1 — Installing Active Directory Certificate Services (AD CS)

In this part, you will install the CA role and all supporting role services in one pass: the Certification Authority itself, NDES (which provides the SCEP endpoint for Apple and Chromebook devices), Online Responder (which handles certificate revocation checking), and Web Enrollment (which PacketFence requires to communicate with your CA).

Step 1.1 — Add the AD CS role and all required role services

  1. Log in to your Windows Server 2022 machine with your Enterprise Admins account.
  2. Open Server Manager from the taskbar.
  3. Click Manage in the top-right corner, then select Add Roles and Features.
  4. Click Next until you reach the Server Roles page.
  5. Check the box next to Active Directory Certificate Services.
  6. A pop-up will ask you to add required features — click Add Features.
  7. Click Next until you reach the AD CS Role Services page.
  8. Check all four of the following role services:
    • Certification Authority
    • Network Device Enrollment Service (NDES)
    • Online Responder
    • Certification Authority Web Enrollment
  9. For each role service you check, Server Manager may prompt you to add additional required features. Accept all of these by clicking Add Features each time.
  10. Click Next, then Install.
  11. Wait for the installation to complete. Do not close Server Manager.

Step 1.2 — Configure the Certification Authority

Once the installation finishes, a yellow warning flag will appear in Server Manager.

  1. Click the flag, then click Configure Active Directory Certificate Services on the destination server.
  2. On the Credentials page, confirm the account shown is your Enterprise Admins account. Click Next.
  3. On the Role Services page, you will see all four role services listed. Start by checking Certification Authority only — you will configure the other role services in subsequent steps within the same wizard. Click Next.

Choosing the CA type — this is important:

On the Setup Type page you will see two options:

  • Enterprise CA — Integrated with Active Directory. This is what you want. It enables automatic certificate enrollment via Group Policy and allows the use of certificate templates.
  • Standalone CA — Not integrated with AD. Requires manual enrollment. Do not choose this.

Select Enterprise CA and click Next.

  1. On the CA Type page, select Root CA. This is the first and only CA in your environment — it is the trust anchor for all certificates. Click Next.
  2. On the Private Key page, select Create a new private key. Click Next.
  3. On the Cryptography page:
    • Set the key length to 4096 bits
    • Leave the hash algorithm as SHA256
    • Click Next
  4. On the CA Name page, give your CA a clear, descriptive name, for example Contoso-Root-CA. Click Next.
  5. On the Validity Period page, set the validity to 10 years. Click Next.
  6. Leave the database locations at their defaults. Click Next, then Configure.

Step 1.3 — Configure NDES

Continue in the same configuration wizard, now selecting Network Device Enrollment Service.

  1. On the Service Account for NDES page, enter the credentials for the svc-ndes service account you created in Prerequisites. Click Next.
  2. On the CA for NDES page, select CA name and choose your newly created CA from the list. Click Next.
  3. On the RA Information page, fill in the Registration Authority details. These appear in certificate requests that NDES submits on behalf of devices. Use your organization's details:
    • RA Name: Contoso NDES RA
    • Fill in Country, State/Province, and Organization as appropriate
  4. On the Cryptography for NDES page, leave both key lengths at 2048 and the hash algorithm as SHA-256. Click Next.
  5. Click Configure to complete the NDES configuration.

Step 1.4 — Configure Online Responder

The Online Responder handles OCSP (Online Certificate Status Protocol) requests, allowing clients and PacketFence to quickly check whether a certificate has been revoked.

  1. In the wizard, select Online Responder.
  2. Accept the defaults on all pages and click Configure.

Step 1.5 — Configure Certification Authority Web Enrollment

Web Enrollment provides an HTTPS interface that PacketFence uses to request certificates.

  1. In the wizard, select Certification Authority Web Enrollment.
  2. Accept the defaults and click Configure.
  3. Click Close to exit the wizard when all role services are configured.

Step 1.6 — Verify all services are running

  1. Open the Certification Authority console (search for it in the Start Menu). Your CA should appear with a green icon.
  2. Open Internet Information Services (IIS) Manager. You should see two virtual directories: CertSrv (Web Enrollment) and CertSrv/mscep (NDES).
  3. From a browser on the server, browse to http://localhost/certsrv/mscep_admin/. You should see a page displaying an enrollment challenge password. This confirms NDES is running correctly.

If any service shows as stopped, right-click it and select Start, or restart the relevant Windows service from services.msc.

Part 2 — Configuring the CA and Certificate Templates

Each device platform uses a different enrollment method, which means each needs a certificate template configured differently. In this part you will create three separate templates — one for Windows devices, one for Apple devices, and one for Chromebooks.

Template Enrollment method Subject name source
EAP-TLS Windows Device Group Policy autoenrollment Built from Active Directory (machine hostname)
EAP-TLS Apple Device SCEP via NDES Supplied in the request by the device (serial number)
EAP-TLS Chrome Device SCEP via Google Cloud Certificate Connector Supplied in the request by Google (device serial number)

The key difference between the Windows template and the SCEP templates is in the Subject Name tab. The Windows template can look up the machine name from Active Directory. SCEP-based templates cannot do this — the device tells the CA who it is at the time of the request, so the template must be configured to accept that information rather than look it up.

The Apple and Chrome templates are also kept separate from each other because they use different subject name variable syntax, and keeping them separate makes troubleshooting and auditing much cleaner.

Step 2.1 — Open the Certificate Templates console

In the Certification Authority console, right-click Certificate Templates and select Manage. This opens the Certificate Templates console in a separate window.

Template A — Windows Device Certificate

This template uses Active Directory autoenrollment and is scoped to the computer account.

  1. In the Certificate Templates console, find the Computer template.
  2. Right-click it and select Duplicate Template.

General tab:

  • Template display name: EAP-TLS Windows Device
  • Validity period: 1 year
  • Renewal period: 6 weeks
  • Check Publish certificate in Active Directory

Subject Name tab:

  • Select Build from this Active Directory information
  • Subject name format: Common name
  • Under "Include this information in alternate subject name", check DNS name

Extensions tab:

  • Click Application Policies > Edit
  • Confirm Client Authentication is present
  • Click OK

Security tab:

  • Find Domain Computers
  • Check Allow for both Enroll and Autoenroll

Click OK to save.

Template B — Apple Device Certificate

This template is used by Apple devices enrolling via SCEP. The subject name is supplied by the device at enrollment time, not looked up from AD.

  1. In the Certificate Templates console, find the Computer template again.
  2. Right-click it and select Duplicate Template.

General tab:

  • Template display name: EAP-TLS Apple Device
  • Validity period: 1 year
  • Renewal period: 6 weeks
  • Leave Publish certificate in Active Directory unchecked — SCEP-enrolled devices are not AD objects

Subject Name tab:

  • Select Supply in the request
  • You will see a warning that the CA manager will need to approve each request. This is expected behaviour — for SCEP, NDES handles the approval automatically using the challenge password, so this does not result in manual approval queues.

Extensions tab:

  • Click Application Policies > Edit
  • Confirm Client Authentication is present
  • Click OK

Security tab:

  • Remove Domain Computers from the list (Apple devices are not domain members)
  • Find or add the svc-ndes service account
  • Grant svc-ndes: Read and Enroll (check Allow for both)

Click OK to save.

Template C — Chrome Device Certificate

This template is nearly identical to the Apple template but is kept separate to use Google-specific subject name conventions and to keep issuance auditing clean.

  1. In the Certificate Templates console, find the Computer template again.
  2. Right-click it and select Duplicate Template.

General tab:

  • Template display name: EAP-TLS Chrome Device
  • Validity period: 1 year
  • Renewal period: 6 weeks
  • Leave Publish certificate in Active Directory unchecked

Subject Name tab:

  • Select Supply in the request
  • Same reasoning as the Apple template — the Google Cloud Certificate Connector will supply the subject name based on the Chromebook's device serial number.

Extensions tab:

  • Click Application Policies > Edit
  • Confirm Client Authentication is present
  • Click OK

Security tab:

  • Remove Domain Computers from the list
  • Find or add the svc-ndes service account
  • Grant svc-ndes: Read and Enroll

Click OK to save.

Step 2.2 — Enable all three templates on your CA

Creating templates in the Certificate Templates console does not automatically make them available for issuance. You must add them to your CA.

  1. Return to the Certification Authority console.
  2. Right-click Certificate Templates and select New > Certificate Template to Issue.
  3. Select EAP-TLS Windows Device and click OK.
  4. Repeat steps 2–3 for EAP-TLS Apple Device.
  5. Repeat steps 2–3 for EAP-TLS Chrome Device.

All three templates should now be listed under Certificate Templates in your CA.

Step 2.3 — Configure Windows computer auto-enrollment via Group Policy

Now you will tell all domain-joined Windows computers to automatically request a certificate using the Windows template.

  1. Open Group Policy Management (run gpmc.msc).
  2. Right-click Default Domain Policy and select Edit.

Note: For production environments it is best practice to create a dedicated GPO rather than editing the Default Domain Policy. For the purposes of this tutorial, the Default Domain Policy is acceptable.

  1. Navigate to: Computer Configuration > Policies > Windows Settings > Security Settings > Public Key Policies
  2. Double-click Certificate Services Client – Auto-Enrollment.
  3. Set the Configuration Model to Enabled.
  4. Check both:
    • Renew expired certificates, update pending certificates, and remove revoked certificates
    • Update certificates that use certificate templates
  5. Click OK and close the Group Policy editor.

Part 3 — Deploying Device Certificates to Windows Devices

With Group Policy configured, Windows domain computers will automatically enroll for the EAP-TLS Windows Device certificate. This part walks you through confirming it works.

Step 3.1 — Trigger enrollment on a test device

On a domain-joined Windows device, open Command Prompt or PowerShell as Administrator and run:

gpupdate /force

This forces the computer to refresh Group Policy immediately. Certificate auto-enrollment is triggered as part of this process. Wait about 30 seconds, then run:

certutil -pulse

This manually triggers the auto-enrollment process if gpupdate alone did not initiate it.

Step 3.2 — Verify the certificate in the computer store

  1. Press Windows + R, type mmc, and press Enter.
  2. Click File > Add/Remove Snap-in.
  3. Select Certificates and click Add.
  4. Choose Computer account, then Local computer. Click Finish, then OK.
  5. In the MMC console, expand Certificates (Local Computer) > Personal > Certificates.
  6. You should see a certificate with:
    • Issued By: your CA name (e.g., Contoso-Root-CA)
    • Template: EAP-TLS Windows Device
    • Intended Purposes: Client Authentication

Important: Make sure you are looking in the Computer store, not the User store. EAP-TLS device authentication requires the certificate to be in the computer's Personal store.

Step 3.3 — Confirm issuance in the CA console

On your CA server, open the Certification Authority console and expand Issued Certificates. You should see the certificate for your test device listed here, with the template column showing EAP-TLS Windows Device.

Part 4 — Deploying Device Certificates to Apple Devices (iOS & macOS)

Apple devices do not join a Windows domain, so they cannot use Group Policy auto-enrollment. Instead, you will create a configuration profile using iMazing Profile Editor that instructs the device to request a certificate from your CA via SCEP/NDES.

Step 4.1 — Export the CA root certificate

Apple devices need to trust your CA before they will accept certificates it has issued. You must include the CA's root certificate in the configuration profile.

  1. On your CA server, open the Certification Authority console.
  2. Right-click your CA and select Properties.
  3. On the General tab, click View Certificate.
  4. Click the Details tab, then Copy to File.
  5. In the Export Wizard:
    • Select Base-64 encoded X.509 (.CER)
    • Save the file as Contoso-Root-CA.cer
  6. Click Finish.

Step 4.2 — Obtain an NDES enrollment challenge password

NDES uses a one-time challenge password to authorize each certificate request. You need to supply this password in the SCEP configuration profile.

  1. From a browser on your CA server, browse to: http://localhost/certsrv/mscep_admin/
  2. The page will display a challenge password. Copy this password — it is valid for a limited time (default 60 minutes) and is single-use.

Note: In a production environment with many Apple devices, your MDM solution typically retrieves challenge passwords automatically via the NDES challenge URL. Consult your MDM documentation for details. For testing a single device manually, the approach above works fine.

Step 4.3 — Build the configuration profile in iMazing Profile Editor

  1. Open iMazing Profile Editor on your workstation.

  2. Click New Profile.

  3. Fill in the General section:

    • Name: EAP-TLS Apple Device Certificate
    • Identifier: com.yourorg.eaptls.appledevice
    • Organization: Your organization name

  4. In the left panel, click + to add a payload. Select Certificates.

    • Click Add Certificate
    • Import your Contoso-Root-CA.cer file
    • This installs your CA as a trusted root on the Apple device

  5. Add another payload: SCEP. Configure it as follows:

    • URL: http://your-ca-server/certsrv/mscep/mscep.dll (Replace your-ca-server with your server's hostname or IP)
    • Name: EAP-TLS Apple Device
    • Subject: CN=%SerialNumber% (This is Apple's built-in variable for the device serial number)
    • Challenge: Paste the challenge password you copied in Step 4.2
    • Key Size: 2048
    • Key Usage: Check both Signing and Encryption
    • CA Fingerprint: Paste the SHA-256 fingerprint of your CA certificate (Open the .cer file in Windows Certificate viewer, go to Details tab > Thumbprint)

  6. Save the profile as eaptls-apple-device.mobileconfig.

Step 4.4 — Deploy the profile via MDM

The exact steps vary by MDM solution, but the general process is:

  1. Upload eaptls-apple-device.mobileconfig to your MDM as a new device configuration profile.
  2. Scope it to the device groups you want to target (e.g., all managed Macs, all managed iPhones).
  3. Push the profile. Devices will receive it at next MDM check-in.

Step 4.5 — Verify on an Apple device

On macOS:

  1. Open Keychain Access (Applications > Utilities).
  2. Select the System keychain.
  3. Look for a certificate with:
    • Issued by your CA
    • A Common Name matching the device serial number

On iOS/iPadOS:

  1. Go to Settings > General > VPN & Device Management.
  2. Tap your profile. The SCEP payload should show a certificate issued by your CA.

Part 5 — Deploying Device Certificates to Chromebooks

Chromebooks cannot use Group Policy or Apple MDM profiles. Google provides the Google Cloud Certificate Connector (GCCC) — a lightweight Windows service that bridges your Google Admin Console to your Microsoft CA. When a managed Chromebook needs a certificate, it requests one through Google Admin, which passes the request through the connector to your NDES endpoint, which forwards it to your CA.

Step 5.1 — Understand the flow

Chromebook --> Google Admin --> Cloud Certificate Connector --> NDES --> Microsoft CA
              (requests cert)   (forwards SCEP request)        (issues cert)

The connector runs on your CA server since NDES is already installed there.

Step 5.2 — Download the connector from Google Admin

  1. In the Google Admin Console (admin.google.com), navigate to: Devices > Networks > Certificates

  2. Click Add Certificate Connector.

  3. Google will prompt you to download two items:

    • The connector installer (.exe)
    • A service credentials JSON file

    Download both and copy them to your CA server.

Step 5.3 — Install the connector

  1. On your CA server, run the connector installer.
  2. Accept the default installation path.
  3. When prompted, provide the path to the service credentials JSON file you downloaded from Google Admin.
  4. Complete the installation. The connector installs as a Windows service named Google Cloud Certificate Connector.

Step 5.4 — Configure the connector

Open the connector's configuration file. By default it is located at:

C:\Program Files\Google\Cloud Certificate Connector\config.json

Edit the file to point the connector to your NDES endpoint:

{
  "scep_url": "http://localhost/certsrv/mscep/mscep.dll",
  "scep_challenge_url": "http://localhost/certsrv/mscep_admin/",
  "signing_key_length": 2048
}

Note: Since the connector is running on the same server as NDES, localhost is correct here. If you later move the connector to a different server, replace localhost with your CA server's hostname.

After saving, restart the connector service:

  1. Open Services (services.msc)
  2. Find Google Cloud Certificate Connector
  3. Right-click > Restart

Step 5.5 — Create the enrollment profile in Google Admin

  1. Return to Google Admin Console > Devices > Networks > Certificates.
  2. Click Add to create a new certificate enrollment profile.
  3. Fill in the details:
    • Name: EAP-TLS Chrome Device
    • Connector: Select the connector you registered in Step 5.2
    • Certificate type: Device
    • SCEP profile URL: http://your-ca-server/certsrv/mscep/mscep.dll
    • Subject name format: CN=${DEVICE_SERIAL} (This is Google's variable for the Chromebook's device serial number — note the different syntax from Apple's %SerialNumber%)
    • Certificate template: EAP-TLS Chrome Device (This must exactly match the template name you created in Part 2 — capitalization and spacing included)
  4. Under Organizational Units, select the OUs containing your managed Chromebooks.
  5. Click Save.

Google Admin will push the enrollment profile to managed Chromebooks at next policy refresh. You can also trigger an immediate sync from the device's detail page in Admin Console.

Step 5.6 — Verify on a Chromebook

  1. On a managed Chromebook, open a browser tab and go to: chrome://settings/certificates
  2. Click the Authorities tab and confirm your CA's root certificate is listed as trusted.
  3. Click the Your certificates tab — you should see a device certificate with:
    • Issued by your CA
    • A Common Name matching the Chromebook's serial number

You can also confirm issuance from the CA side by opening Issued Certificates in the Certification Authority console and looking for entries showing the EAP-TLS Chrome Device template.

Troubleshooting

Certificate not appearing in the Windows computer certificate store

  • Run gpupdate /force followed by certutil -pulse on the affected device.
  • Confirm the device is domain-joined by running dsregcmd /status and looking for DomainJoined: YES.
  • Check Certification Authority > Failed Requests on your CA. The reason column will indicate why the request was rejected.
  • Confirm that Domain Computers has both Enroll and Autoenroll permissions on the EAP-TLS Windows Device template.
  • Confirm the GPO is under Computer Configuration, not User Configuration. Run gpresult /r on the client and verify the GPO appears under Computer Settings > Applied GPOs.

Certificate not appearing on Apple devices

  • Confirm the MDM profile was successfully delivered — check the device status in your MDM console.
  • Verify the NDES SCEP URL is reachable from the device. Try browsing to it from Safari on the device — you should receive a response, not a connection timeout.
  • Check that the NDES challenge password has not expired. Challenge passwords are single-use and time-limited (default 60 minutes). Generate a fresh one from http://your-ca-server/certsrv/mscep_admin/ if needed.
  • Confirm the svc-ndes service account has Read and Enroll permissions on the EAP-TLS Apple Device template.
  • Check the Windows Event Log on your CA server: Event Viewer > Applications and Services Logs > Microsoft > Windows > NetworkDeviceEnrollmentService

Certificate not appearing on Chromebooks

  • In Google Admin Console, go to Devices > Chrome > Devices, find the affected device, and click Force Policy Sync.
  • Check the Google Cloud Certificate Connector's Windows Event Log: Event Viewer > Applications and Services Logs > Google > Cloud Certificate Connector.
  • Confirm the connector service is running (services.msc).
  • Verify NDES is running and that http://localhost/certsrv/mscep_admin/ returns a challenge password on the CA server.
  • Check that the Certificate template name in the Google Admin enrollment profile exactly matches the template name in your CA — capitalization and spacing must match.
  • Confirm the svc-ndes account has Read and Enroll on the EAP-TLS Chrome Device template.

EAP-TLS failing at authentication (device has a cert but cannot connect)

  • Confirm the client certificate has Client Authentication listed under Extended Key Usage. Check this in the certificate's Details tab on the device.
  • Confirm PacketFence trusts your CA. Your CA's root certificate must be imported into PacketFence's trusted CA store.
  • Check PacketFence's RADIUS logs for the specific rejection reason. Common causes include: certificate chain not trusted, certificate expired, or subject name format not matching what PacketFence expects.
  • Verify the device's clock is accurate. Certificate validation is time-sensitive — a significantly wrong clock will cause validation to fail.

NDES challenge password page is inaccessible

  • Confirm the svc-ndes service account is set as the application pool identity for the NDES app pool in IIS Manager.
  • Confirm IIS is running — open IIS Manager and check that the Default Web Site is started.
  • Confirm that svc-ndes has Read and Enroll permissions on the CA itself (not just the templates). In the Certification Authority console, right-click your CA > Properties > Security.

Next Steps

You now have a functioning Microsoft CA issuing device certificates to Windows, Apple, and Chromebook devices. The next step is to configure PacketFence to use your CA as the trust anchor for EAP-TLS authentication and to connect it to your Wi-Fi infrastructure via 802.1X.

Specifically, you will need to:

  1. Import your CA root certificate into PacketFence so it can validate device certificates during EAP-TLS handshakes.
  2. Issue a RADIUS server certificate from your CA for PacketFence itself, so that devices can also validate the RADIUS server's identity — mutual authentication is a core requirement of EAP-TLS.
  3. Configure your wireless access points to point to PacketFence as their 802.1X RADIUS server.

These steps are covered in the PacketFence documentation. The certificate infrastructure you have built in this tutorial is the foundation that all of those steps depend on.

Back to top