Help end users connect to Wi-Fi with certificates from certificate authority (NDES, DigiCert, etc.)

[noahtalerman]

• prospect-blondelet: Gong snippet: https://us-65885.app.gong.io/call?id=834076390531746995&highlights=%5B%7B%22type%22%3A%22SHARE%22%2C%22from%22%3A1695%2C%22to%22%3A1847%7D%5D
  • @allenhouchins: One additional requirement for prospect-blondelet is ensuring automatic certificate renewal. See this Slack thread: https://fleetdm.slack.com/archives/C07AK6CUDFC/p1738262762662739
• customer-pingali: Gong snippets:
  • https://us-65885.app.gong.io/call?id=8675773983528359530&highlights=%5B%7B%22type%22%3A%22SHARE%22%2C%22from%22%3A1290%2C%22to%22%3A1539%7D%5D
  • pingali pulling up their current MDM solution to show us how this is configured (entire 30 min call but skip around to see different parts): https://us-65885.app.gong.io/call?id=5687455957318183995
• customer-cisneros: Gong snippet: TODO
• customer-montague: Gong snippet: TODO
• customer-pingali: Gong snippet: TODO
• customer-reedtimmer: Gong snippet: TODO
• customer-rocher: Gong snippet: TODO
• customer-ufa: Gong snippet: TODO
• @noahtalerman: Customers will want to deploy certificates to both the system (device) Keychain and the user Keychain. I think might be able to do this by setting System or User for the PayloadScope key in the configuration profile.
• @allenhouchins: The NDES work is looking great. We should consider moving the SCEP configuration to the root level under Integrations, not within Mobile Device Management, and also renaming it something like “Certificate Authorities”. SCEP is just one of many protocols for connecting to CAs (SCEP/ACME/API) and customers may need to connect to multiple CAs that serve different purposes for their end user devices.
• @mikermcneil: To grant access for employee computers to connect to the corporate network over Wifi or Ethernet (or sometimes VPN or like an engineer sshing into the AWS production environment) in common enterprise setups, IT admins need to be able to deliver a certificate to the device. Normally on macOS, admins do this with a config profile. In the profile (the OS setting) I deploy to my Macs, there is always a URL of the certificate authority (ex. Digicert, Smallstep, AD CS, NDES, etc.) In its simplest form, the device could talk directly to this CA URL to get whatever scraps it needs to build a certificate locally and store in the keychain. (The only problem is no one wants it to work that way.) People don't want to have devices talk directly to the CA. (why? because if your CA gets compromised, you're hosed. Customers ideally want only the Fleet server to be able to communicate with the CA, not every laptop at a random Starbucks.) In those cases, the IT admin instead gives Fleet the secrets and the CA URL needed to talk directly to the CA, and then, deploys a profile (.mobileconfig) --ideally managed by the integration and abstracted, like how we handle the "Disk encryption" in the UI, not something you're building yourself by hand. Then that .mobileconfig file with the data from the CA gets sent down to the device so that it can assemble the certifcate and stick it in the keychain. IT expects the certificate to be fully managed by the integration -- to be renewed automatically on the device before it expires (what if the device is off for over a year-- what edge cases will come up? How does this commonly look on windows?)
  • @noahtalerman: In addition to Windows, how will this work w/ a declaration (DDM) profile?
• @allenhouchins Jamf supported Digicert, Venafi, and ADCS. Digicert is perceived as the high-end of PKI, and Venafi the low end of PKI. Jamf also supported ADCS (typically for on-prem customers), which involved installing custom software on the actual directory service itself to broker through the firewall or DMZ connection. Sometimes perceived a a very antiquated approach, because these days people are more likely to do app-based VPN routing ± zero trust access. What about edge cases? With any .mobileconfig file related to a certificate, there could be a risk of it not being idempotent, like you try to deploy the same profile again and the second time it kicks the user off the network, even though the profile is exactly identical. It's not just issuing certs, it's renewing and revoking them too. If you revoke a cert in Digicert (which btw is likely to be owned by another team, security, since IT [CPE] won't have access to Digicert), then that revocation should flow down to the middleman (i.e. Fleet), which should somehow reflect that in Fleet (e.g. "This certificate has been removed in Digicert"). In order to listen for that foreign-initiated revocation, Fleet may need to talk to the Digicert API every minute to check the status and react accordingly. Is it ever important for a CPE to revoke a cert from the Fleet side? Well maybe, lower on the list, but if you need to do it, you're troubleshooting one particular host probably (We'll come back to that below.) When I think about the lifecycle of a certificate like this there's 3 stages: there's the issuance, the renewal, and revocation. Typically a cert's lifetime is a year. Are there ever multiple certificates across different segments of the fleet? Ideally you wouldn't, but I've seen situations where there were multiple. E.g. a certificate for network device identity coming from Cisco, a certificate from the IdP. Are certs a thing where you're like "a cert is a cert is a cert", or is the IT admin thinking more about the use case? It's more like "cert is a cert is a cert". Do you name the certs? Yeah, that's where you'd name them and indicate their purpose, in the event you have more than one. What about scoping the certicates? Is the worst thing that's gonna happen if you put too many certs on a host that that host will have access to more things than it should? Yes. So when I go into Fleet to add a PKI, it could be more like I'm adding a managed certificate, not necessarily just linking a Digicert integration. Like, it's ok to have a form where you choose "Certificate authority (CA): Digicert", you paste in the secret to be able to talk to their API (if they require that-- maybe they don't -- it looks like it's all CSR-based), and then you give it a good name to explain what it's for. Then Fleet generates the CSR (certificate signing request) and uploads that to Digicert, which responds with this thing called an "RA cert" (a .p7b file), which behind the scenes Fleet then uses that RA cert to somehow generate the cert. (IDEALLY this process is over the digicert api somehow but you might not have been given the API credential by cybersecurity so you might have to actually download the CSR generated by Fleet, give it to cybersecurity manually, who uses their portal access to Digicert to upload it to the UI, and then they manually hand you back an RA cert, aka a .p7b file, which you then manually upload to Fleet via the UI). So we probably need to support the manual way, because even the API supports it, there could be organizational boundaries preventing IT from actually being able to use any fancy automated magic here. The good news? That manual flow would pretty much work for ANY certificate authority. But then there's more steps that Fleet needs to take (other products require IT admins to do it themselves): which is basically a managed .mobileconfig file where (typically-- yikes but lets assume always for the moment) a DIFFERENT self-signedish-rootish certificate kind of thing (likely a .pem) generated (by Fleet server from the .p7b) is included in the profile (it's not different for every host). From an IT admin perspective, do you want that to be manual? No, it would be sweet if that last .mobileconfig delivery stuff was fully automatic and all I had to do was upload the .p7b. (Disclaimer: You only have to set up that other profile and paste in the other cert one time, so it's a relatively light lift. But still) Renewal: Nothing really wrong with issuing certs early, unless maybe there's costs that could be associated with early cert renewal. So, ongoing, for each PKI-issued certificate I can maybe see on this new little page, ≈10-30 days before each one expires (the date of which it would be cool to see in the list view), Fleet re-issues the .pem to all the relevant hosts and now there's a new expiration date. Apple's best practice is that a cert should never be longer than 398 days. Where is the expiry for the PKI-issued certificates set? I think it's in Digicert (likely associated either with Digicert's global settings or a particular csr/p7b) Back to troubleshooting a cert you want to manually revoke on a particular device: Would you just delete the profile from that device? Well if I wanted to nuke it and never have it come back online, I would remove the profile. (How often does that happen? Usually infrequent, and maybe you could work around it by moving the host to a different device group). Testing/QAing this? Well you could like set up an openvpn server on your home network or AWS, make a special HTML page (any old website) and put it behind (configure) cert-based access, and then try out issuing yourself that cert from Fleet.

• @noahtalerman: Other MDM solutions report a list of certificates deployed and their status: revoked, inactive, expired

• @nonpunctual Just want to point out that all organizations that I have seen with 802.1x do not start with anyone creating a wi-fi profile. This is possible, but, with enterprise wi-fi the device is negotiating a RADIUS server with 802.1x authorization & authentication. In all the Jamf instances I have seen what this is means is that the AD CS or SCEP proxy template is used to create a cert that is placed in the keychain so when the device tries to talk to the RADIUS server to get on the wi-fi, the cert is in place to authenticate & authorize the device. @noahtalerman

Please see: https://support.apple.com/guide/deployment/connect-to-8021x-networks-depabc994b84/web

---

User stories

• Deploy SCEP certificates from Network Device Enrollment Service (NDES) #21955
• Renew NDES SCEP certificates #24468
• Deploy certificates from DigiCert #22709
• Add end user's username as a variable in configuration profiles #24946
• Deploy SCEP certificates from custom certificate authority #25822

[noahtalerman]

Fleet sends an MDM command to send a public key to the host via the device channel

When the IT admin adds a profile that requires a certificate, Fleet gets a cert from the CA and sends it to the host via the device channel. Cert gets installed on device Keychain

First pass at the workflow for this^ in Fleet:

• IT admin creates a Wi-Fi or Ethernet profile in iMazing with Wi-Fi or Ethernet payload and a com.apple.security.root payload with the public key
• IT admin saves this profile, opens it in their text editor, and adds a com.apple.security.pkcs1 payload with empty data, and System for the PayloadScope
• Fleet goes and gets the cert from the CA and installs the profile w/ Wi-Fi or Ethernet settings, public key, and cert on device's Keychain

[noahtalerman]

Hey @Patagonia121, heads up, we didn't have the space to take this on in the current design sprint (4.48).

It's a relatively large level of effort.

Like #13418, let's move quickly and meet with @alexmitchelliii to discuss the plan for addressing this customer request.

[nonpunctual]

for reference: https://github.com/jamf/ol/blob/master/adcsc/Test/Testing%20AD%20CS%20Connector%20with%20curl.sh

[noahtalerman]

Moved an earlier version of the issue description here for safekeeping:

UPDATE: This story is about making Fleet work w/ any certificate authorities (CAs) (ex. Digicert, Smallstep, AD CS, NDES, etc.). Stories for integrating Fleet w/ specific CAs are here:

• Deploy SCEP certificates from Network Device Enrollment Service (NDES) #21955
• DigiCert MPKI integration for macOS hosts #21936

(noahtalerman 2024-09-10)

---

Goal

User story
As an IT admin,
I want to install custom certificates as part of the Wi-Fi and Ethernet profiles
so that I can use this cert to grant the end user access to my organization’s network.

• ✅ "Custom certificate authority" (Fleet Premium)
• ✅ "Custom WiFi and Ethernet certificates" (Fleet Premium)

User journey

• IT admin creates a custom Wi-Fi or Ethernet profile in iMazing with Wi-Fi or Ethernet payload and a com.apple.security.root payload with the public key
• IT admin saves this profile, opens it in their text editor, and adds a com.apple.security.pkcs1 payload with empty data, and System for the PayloadScope
• Fleet goes and gets the cert from the CA and installs the profile w/ Wi-Fi or Ethernet settings, public key, and cert on end user's device Keychain

Changes

• IT admin can add a custom Wi-Fi or VPN profile that points the device to Fleet to get a certificate from the certificate authority (CA).
• Fleet sends an MDM command to send a public key to the host via the device channel
  • Note that the requester uses the com.apple.security.pkcs1 MDM payload to install the key
• When the IT admin adds a profile that requires a certificate, Fleet gets a cert from the CA and sends it to the host via the device channel. Cert gets installed on device Keychain

Product

• UI changes: TODO
• CLI usage changes: TODO
• Permissions changes: TODO
• Outdated documentation changes: TODO
• Changes to paid features or tiers TODO

Engineering

• REST API changes: TODO
• Database schema migrations: TODO
• Documentation changes complete

Product quality

• QA complete
• ...

ℹ️  Please read this issue carefully and understand it. Pay special attention to UI wireframes, especially "dev notes".

Context

• Requestor(s): _________________________

QA

Risk assessment

• Requires load testing: TODO
• Risk level: Low / High TODO
• Risk description: TODO

Manual testing steps

1. Step 1
2. Step 2
3. Step 3

Testing notes

Confirmation

1. Engineer (@____): Added comment to user story confirming succesful completion of QA.
2. QA (@____): Added comment to user story confirming succesful completion of QA.

[lukeheath]

I processed the wall of text a bit:

Key Suggestions and Observations

Structural Changes

• Move SCEP Configuration: Suggest moving SCEP configuration to the root level under Integrations and renaming it to something like “Certificate Authorities”.
• Reason: SCEP is just one protocol (alongside ACME, API, etc.) for connecting to CAs. Customers often need to connect to multiple CAs for different purposes.

IT Admin Requirements for Certificate Management

1.	Certificate Deployment Process
•	IT admins use config profiles to deliver certificates to devices for corporate network access (WiFi, Ethernet, VPN, SSH, etc.).
•	Certificate Authorities Examples: Digicert, Smallstep, AD CS, NDES.
•	Key Admin Expectations:
•	Devices should not communicate directly with the CA for security reasons (e.g., to protect against CA compromise).
•	The Fleet server should manage all communication with the CA.
2.	Integration Management
•	Admins configure Fleet to communicate with the CA using provided secrets and the CA URL.
•	Fleet generates .mobileconfig files with CA data, which are sent to devices for local certificate creation and keychain storage.
3.	Lifecycle of Certificates
•	Stages: Issuance → Renewal → Revocation.
•	Typical Certificate Lifetime: ~1 year.
•	Renewal should be automated, with Fleet re-issuing certificates ~30 days before expiry.
•	Expiry policies must align with best practices (e.g., Apple’s max 398 days).
4.	Scoping Certificates
•	Certificates are tied to specific use cases (e.g., network device identity).
•	Over-scoping could grant excessive access to a host.

Challenges and Edge Cases

1.	Manual Processes vs. Automation
•	Some organizations may not allow automated API usage for CAs due to cybersecurity constraints.
•	Fleet needs to support manual workflows:
•	Admins download CSRs (generated by Fleet) and manually upload to CA portals.
•	Resulting RA certificates (.p7b) are manually uploaded back into Fleet.
2.	Idempotency Risks
•	Re-deploying the same .mobileconfig can unintentionally disconnect devices from networks.
3.	Revocation Workflow
•	If a certificate is revoked in the CA (e.g., via Digicert API), Fleet should reflect this change in its UI.
•	Manual revocation on a single device may involve deleting the profile or moving the device to a different group.
4.	Cross-Segment Certificates
•	Situations may arise with multiple certificates (e.g., one for Cisco network identity, another from IdP).
•	Admins must clearly name and scope certificates.

Supported Features and Integrations

1.	CA Integrations
•	Examples: Digicert, Venafi, ADCS.
•	Digicert: High-end PKI.
•	Venafi: Low-end PKI.
•	ADCS: Typically for on-prem customers, involves custom software installation for directory services.
2.	Certificate Management in Fleet
•	Fleet should generate CSRs and upload them to CAs.
•	Renewal of certificates must be fully automated.
•	Managed .mobileconfig profiles should simplify deployment.

Future Considerations

1.	Testing and QA
•	Set up scenarios to test cert-based access (e.g., configure OpenVPN and restrict access to a website).
2.	Declaration (DDM) Profiles
•	Consider implications for managing certificates with DDM profiles, especially on Windows.
3.	API Polling for Revocation
•	Fleet might need to periodically check CA APIs (e.g., Digicert) to detect foreign-initiated revocations.
4.	Cost Implications
•	Early renewal may introduce unnecessary costs.

Final Notes

•	Naming and Clarity
•	Certificates should be named for their use case to avoid confusion when managing multiple CAs.
•	Visibility in Fleet
•	Admins should see certificate expiration dates in a list view to facilitate proactive management.

[noahtalerman]

Moving these other pingali Gong snippets here for safekeeping:

• https://us-65885.app.gong.io/call?id=1989192898666666867&highlights=%5B%7B%22type%22%3A%22SHARE%22%2C%22from%22%3A3293%2C%22to%22%3A3386%7D%5D
• https://us-65885.app.gong.io/call?id=1989192898666666867&highlights=%5B%7B%22type%22%3A%22SHARE%22%2C%22from%22%3A3693%2C%22to%22%3A3797%7D%5D
• https://us-65885.app.gong.io/call?id=1989192898666666867&highlights=%5B%7B%22type%22%3A%22SHARE%22%2C%22from%22%3A3834%2C%22to%22%3A3935%7D%5D
• https://us-65885.app.gong.io/call?id=1989192898666666867&highlights=%5B%7B%2
• https://us-65885.app.gong.io/call?id=8470217130347639214 @ 27:50 onward

These are less relevant to design/building the request than the Gong snippets in the issue description.