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

noahtalerman commented 1 year ago

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
customer-pingali: Gong snippets:
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

21955
22539
22709

noahtalerman commented 1 year ago

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 commented 8 months ago

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.

dherder commented 3 months ago

@noahtalerman We need to clarify the methodology of certificate generation / CA integration. Which one of the following methods / protocols does this issue address?

dherder commented 3 months ago

Certificate_Authority_Integrations.pdf

dherder commented 3 months ago

@noahtalerman prospect-blondlet requires more specifically a Digicert PKI integration to accommodate this use case: https://docs.vmware.com/en/VMware-Workspace-ONE-UEM/2209/Certificate_Authority_Integrations/GUID-DigiCert_PKI_Management_Portal_Platform.html

noahtalerman commented 3 months ago

Thanks @dherder!

clarify the methodology of certificate generation / CA integration. Which one of the following methods / protocols does this issue address?

Right now we're not sure. That's part of the ongoing research in the current design sprint.

To arrive at the decision, it would be helpful to know which customers expect to use which methods. Like in Dave's comment here: https://github.com/fleetdm/fleet/issues/13420#issuecomment-2313338249

For folks that see this comment, please feel free to drop more anonymous (customer codename) info which customers/users expect which method in comments here!

noahtalerman commented 2 months ago

Fleet needs some secret/certificate to communicate w/ AD CS.
- Jamf uses certificates generated by Jamf's separate AD CS connector app: https://learn.jamf.com/en-US/bundle/technical-paper-integrating-ad-cs-current/page/Integrating_with_Active_Directory_Certificate_Services.html
- Omnissa uses a username and password of an AD CS admin account: https://docs.omnissa.com/bundle/workspace-one-access-deployment-with-UEM/page/ConfigureActiveDirectoryCertificateAuthorityinWorkspaceONEUEM.html
When Fleet goes to AD CS to ask for a certificate, AD CS needs to know what the certificate should look like
- things like subject name, cryptography, etc.
- this is where Jamf lets the IT admin point to a template they created in Jamf's separate AD CS connector app
Fleet needs to deliver the certificate via profile

noahtalerman commented 2 months ago

Latest requirements:

NDES is the certificate authority (CA): https://learn.microsoft.com/en-us/windows-server/identity/ad-cs/network-device-enrollment-service-overview
Wi-Fi/Ethernet profile w/ a certificate payload
SCEP cert
Unique per device. Variables in profile determine name and other unique items
Renewal
Revoke: When end user stops using computer

nonpunctual commented 1 month ago

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

noahtalerman commented 1 month ago

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:

21955
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

Step 1
Step 2
Step 3

Testing notes

Confirmation

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

lukeheath commented 1 week ago

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.

fleetdm / fleet