IOS Certificate Selection When Multiple Certificates Match
For supported software information, click here.
IOS is designed with a security boundary that specifically prevents third-party applications from accessing certificates they do not own. This means the SASE client cannot directly read or select from certificates that a mobile device management (MDM) solution such as JamfTM or Microsoft IntuneTM has pushed to the device. The following sections explain where MDM certificates are stored and why the SASE client cannot access them.
MDM Certificate Locations
When an MDM solution pushes a certificate, it goes to one of the following locations:
- System keychain—This keychain stores certificates for Wi-Fi, VPN, and device-wide settings. No third-party application can read or query this keychain. Only native iOS processes, such as Safari or Settings, can access it.
- Managed profile storage—Even if the certificate is technically in the user partition, the MDM profile owns it. Because the SASE client has a different Team ID and App ID than the MDM profile, the iOS sandbox treats them as separate, unrelated entities.
Why the SASE Client Cannot Always Access MDM Certificates
The iOS keychain uses access groups to control which applications can read which items. An application can only see items that match its own access group, such as com.versa.saseclientcatalyst.
Because the MDM solution creates and owns the pushed certificate, the certificate does not carry the SASE client's access group.
IOS does not provide a browse-all-certificates API, which prevents any application from accessing certificates it does not own. As a result, the SASE client cannot access any certificate that the MDM solution delivered.
Use an External Link to Import a Certificate
As the iOS security boundary prevents the SASE client from reading MDM-delivered certificates, you must deliver the certificate directly into the application's sandbox using an external link or direct download URL. You configure this in the MDM .plist file. To do this, you specify the certificate URL and password in the following keys:
- userCertURL
- userCertPassword
For example:
<dict>
<key>device_id</key>
<string>$UUID</string>
<key>fqdn</key>
<string><your-portal-fqdn></string>
<key>enterprise_name</key>
<string><your-enterprise-name></string>
<key>user_id</key>
<string><user@example.com></string>
<key>device_name</key>
<string>$DEVICENAME</string>
<key>managed_device</key>
<true/>
<key>default_browser</key>
<false/>
<key>is_versa_root_ca_required</key>
<true/>
<key>userCertURL</key>
<string>https://<your-cert-host>/<certificate-file>.pfx</string>
<key>userCertPassword</key>
<string><certificate-password></string>
</dict>
Replace the values for fqdn, enterprise_name, user_id, userCertURL, and userCertPassword with the values appropriate for your deployment.
Note:
- When you configure the .plist file with a userCertURL value, the SASE client imports the certificate automatically and does not display a certificate selection prompt.
- If you do not configure a userCertURL value, the SASE client prompts the user to select a certificate.
Renewing Certificates with the Jamf SDK
When the SASE client is configured with Jamf managed application configuration, the SASE client monitors the certificate stored in the application keychain and automatically requests a new certificate from Jamf Pro through the Jamf Certificate SDK when the certificate approaches expiration.
The Jamf Certificate SDK does not provide an in-place renewal API. Instead, when renewal is triggered, the SASE client requests a new certificate from Jamf Pro. When the new certificate is issued, the SASE client automatically replaces the certificate in the application keychain. It is not required to restart after a successful renewal.
Renewal is triggered when the certificate's remaining lifetime falls within one of the following thresholds:
- 30 days before expiration
- One-third of the total certificate validity period
Renewal requests start when the application becomes active (throttled to at most once per 24 hours) or during application launch. The SASE client retries failed requests up to five times at 5-second intervals. If all retries fail, the existing certificate in the keychain is preserved. The SASE client does not remove the existing certificate when renewal fails. If the certificate is still within the renewal window, you can continue using the existing certificate until Jamf Pro or the CA becomes reachable.
The following table describes the conditions under which the SASE client would request a new certificate from Jamf Pro.
| Event | Behavior |
|---|---|
| Managed application configuration change | Requests a new certificate only if the stored certificate is missing, expired, or due for renewal, or if the device is treated as a new MDM enterprise. If the existing certificate is healthy, the SASE client skips the request even if the configuration changed. |
| Application update (same installation, no removal) | Does not force a new request. An app update keeps the keychain, and a healthy certificate continues to be used. |
| Application removal and reinstallation with Jamf | Forces a new request. Uninstalling the application clears the application keychain, and the next launch of the application with the Jamf-managed configuration forces a new certificate request. |
| Certificate profile reassignment in Jamf Pro | Usually does not force a new request. Reassignment may update the managed application configuration, but the SASE client does not clear a local certificate that is still valid. If the stored certificate is healthy, it is not replaced automatically. |
| Certificate revocation | Does not force a new request. The SASE client does not detect revocation on the client side. A revoked certificate that has not yet expired continues to be used until it expires or is replaced through a reinstall. |
| Certificate expiration | Forces a new request. Near expiration (approximately 30 days or within one-third of total validity), the SASE client silently renews in the background while the old certificate remains usable. After expiration, the SASE client starts a foreground re-request at the next application launch or managed application configuration evaluation. |
| User logout or login in the application | Does not force a new request. Logout or login does not clear the MDM client identity or trigger a new Jamf request. |
| Device restart | Does not replace a healthy certificate. A device restart causes a cold application launch and managed application configuration evaluation, but a new certificate is requested only if the stored certificate is missing or due for renewal. |
Handling Multiple Certificates
The Jamf Certificate SDK issues one certificate per request. The SASE client stores this certificate as a single labeled item in the application keychain and uses it for device-certificate authentication. Other certificates in the device keychain, such as those from other applications or MDM profiles, are not part of this flow.
When multiple certificates are present on the device, the SASE client gives priority to the certificate stored from the Jamf SDK. If that certificate is not present, the system prompts the user to select from the available certificates.
If the stored Jamf SDK certificate does not match the issuer configured in the server's certificate-issuer or cert-auth-ca-chains settings, authentication fails. The SASE client does not fall back to other certificates in the keychain.
The SASE client does not select among multiple valid certificates by comparing attributes such as notBefore or notAfter. It uses the certificate currently stored in the keychain. After a successful Jamf renewal, it overwrites the stored certificate with the newly issued one.
The following table describes how the certificate attributes are used by the SASE client during device-certificate authentication.
| Attribute | Description |
|---|---|
| Issuer (DN) | Used for authentication. The issuer must match the server certificate-issuer or cert-auth-ca-chains configuration (field-by-field DN comparison). |
| Subject/CN | Not used for certificate selection. The subject CN is read to auto-fill the username field when empty. |
| SAN | Not used for certificate selection. |
| EKU | Not used in the current Jamf authentication path. |
| Serial number | Not used. |
| notAfter (validity) | Not used directly for authentication. Used for the renewal lifecycle and local trust check. |
Expired and Revoked Certificates
The SASE client treats a certificate as expired when the notAfter date has passed (or is within approximately 60 seconds of expiration). An expired certificate cannot be used for device-certificate authentication.
The following table describes the SASE client behavior based on certificate expiration state.
| State | Behavior |
|---|---|
| Certificate expired | The stored identity is treated as unusable for device-certificate authentication. |
| Near expiration (approximately 30 days) | The SASE client silently requests a new certificate in the background while the old certificate remains usable. |
| Next managed application configuration evaluation (typically at application launch) | The SASE client starts a foreground Jamf request for a new certificate. |
The SASE client does not detect certificate revocation on the client side. A revoked certificate that has not yet expired continues to be classified as healthy and is used until it expires or is replaced. There is no automatic process for clearing and re-requesting revoked certificates.
To replace an incorrect certificate, complete the following steps:
- Correct the certificate settings in Jamf Pro (PKI configuration, template, subject, or managed application configuration).
- Revoke the incorrect certificate on the CA or Jamf Pro side.
- Remove and reinstall the SASE client application. Uninstalling the application clears the application keychain, and the next launch with the Jamf managed application configuration forces the request for a new certificate.
- Open the SASE client and confirm that the new certificate is stored.
Changing the managed application configuration alone is not sufficient to replace a healthy but incorrect certificate already stored in the keychain. Removing and reinstalling the application is the most reliable method to force a new certificate request.
Supported Software Information
SASE Client Releases 7.6.7 and later support all content described in this article.