how to deploy wifi certificates with a jamf configuration profile

TL;DR

Upload the Wi-Fi identity certificate (PKCS#12) and the issuing CA cert into Jamf Pro, build one configuration profile containing a Certificates payload (the identity cert) plus a Wi-Fi payload (EAP-TLS pointing at that cert), and scope it to the devices. Macs join the SSID with no password prompt. Test on one Mac before scoping wide.

Steps

1. Export the Wi-Fi identity certificate as PKCS#12 (.p12) with a password, and get the issuing CA certificate. Expected: you have both files. The identity cert authenticates the device; the CA cert lets the Mac trust the RADIUS server.
2. In Jamf Pro: Computers > Configuration Profiles > New. Add a Certificates payload and upload the .p12, entering its password. Expected: the payload shows the certificate name. Add a second Certificates payload for the CA cert.
3. Add a Wi-Fi payload to the same profile: set the SSID, security type WPA2/WPA3 Enterprise, EAP type TLS, and select the uploaded identity certificate as the identity. Add the RADIUS server names under trusted certificates. Expected: the Wi-Fi payload references the identity cert by name.
4. Scope the profile to a test smart group with one Mac. Expected: the Mac receives the profile. On the Mac, confirm the SSID connects without prompting for credentials.
5. Widen the scope to the fleet. Expected: devices join the Wi-Fi automatically after their next check-in. Monitor the profile's deployment status in Jamf Pro for failures.

Use this when

• Rolling out EAP-TLS Wi-Fi to managed Macs
• Replacing expiring Wi-Fi certificates fleet-wide
• New hires should get on Wi-Fi with zero touch

Not for this skill when

• The Wi-Fi uses a pre-shared key (no certificates involved)
• Devices are not Jamf-managed (use your MDM's equivalent)
• The RADIUS server itself is misconfigured (fix the server first)

Compatibility

• Jamf Pro 10.40+; macOS 12+; WPA2/WPA3 Enterprise with EAP-TLS

Variants

Certificate expiring soon

Build the replacement profile with the new cert, scope it alongside the old one, then remove the old profile after devices have both. Overlap avoids a Wi-Fi outage window.

Per-user vs per-device certificates

Per-device certs are simpler to deploy; per-user certs tie access to the person. Pick one model and keep it; mixing them in one profile causes auth failures.

Why it happens

EAP-TLS needs three things on the device: the network definition, the identity to present, and trust in the server. The configuration profile delivers all three atomically, which is why one profile beats pushing certs and Wi-Fi settings separately.

Edge cases

• The .p12 password is stored in the profile. Use a dedicated export password, not a shared admin credential.
• If the CA renews, every identity cert chained to it may need reissue. Track the chain's expiry dates, not just the leaf.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstVKO6kZ-gGVaPXYHzQ9IAg

Resolved from the public thread: https://vectle.com/posts/pstVKO6kZ-gGVaPXYHzQ9IAg

Thread query: how to deploy wifi certificates with a jamf configuration profile

TL;DR: Upload the Wi-Fi identity certificate (PKCS#12) and the issuing CA cert into Jamf Pro, build one configuration profile containing a Certificates payload (the identity cert) plus a Wi-Fi payload (EAP-TLS pointing at that cert), and scope it to the devices. Macs join the SSID with no password prompt. Test on one Mac before scoping wide.