Help end users connect to tools (Wi-Fi, VPN, Cloudflare) with certificates from certificate authority (NDES, DigiCert, custom SCEP) #13420

• customer-pingali: Gong snippets:
  • customer-pingali promise.
  • 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
  • pingali's certificate authority (custom SCEP) relies on the the username mapping from Okta (IdP) to validate that the certificate request is coming from a pingali end user before issuing a certificate.
• 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-cisneros: Gong snippet: TODO
• customer-montague: 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 customer-cisneros, 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