Configuring a user-provided certificate enrollment setting
Following are the instructions for configuring this type of certification.
One user-provided certificate enrollment setting for each purpose
Configure a user-provided certificate enrollment setting for every purpose for which users can upload a certificate (PKCS 12 file) in the user portal. For example, consider a case in which users have three different purposes for providing certificates: S/MIME signing, S/MIME encryption, and authenticating to a backend server. In this case, you create three user-provided certificate enrollment settings.
You provide a display name for each user-provided certificate enrollment setting. The display name you choose is important because the device user sees it in two places:
- In the user portal when deciding what certificate to upload
- In the user portal, the display name is called “configuration”. The user’s selection associates the uploaded certificate with a user-provided certificate enrollment setting. The user can upload the same certificate, or different certificates, for each display name.
- In Ivanti Mobile@Work for iOS, when Ivanti Mobile@Work for iOS prompts the user for the private key password.
- Ivanti Mobile@Work prompts for the password if a password was not required when the user uploaded the certificate to the user portal. Ivanti Mobile@Work uses the display name to inform the user about which certificate to provide the password for. For details, see The private key password.
Important notes
- The PKCS 12 file must contain the certificate and one private key. Ivanti EPMM does not support PKCS 12 files with more than one private key.
- A web services V2 API is also available for uploading user-provided certificates to Ivanti EPMM and associating the certificates with a user-provided certificate enrollment setting.
- See the Ivanti EPMM V2 API Guide.
- The V1 API that uploaded user certificates to Ivanti EPMM is no longer available. If you used the V1 API to upload user certificates, Ivanti EPMM will continue to use the certificates until either:
- The user uploads a replacement in the user portal
- You use the V2 API to upload a replacement
Note that the V1 API associated the user certificate with a certificate type: All, WIFI, VPN, SMIMESIGNING, SMIMEENCRYPTION, EMAIL or EXCHANGE. Although Ivanti EPMM still supports using these certificates and their associated type, the user portal does not display these certificates in the user portal.
Ivanti EPMM stores the certificate and private key
When the user uploads a user-provided certificate in the user portal, the user uploads a PKCS 12 file. Ivanti EPMM stores the file, which includes the certificate and its private key. Ivanti EPMM does not remove the PKCS 12 file after delivering it to the user’s device. Therefore, if the user registers another device, the PKCS 12 file is available to deliver to the additional device.
The private key password
In each user-provided certificate enrollment setting, you specify whether the user is required to provide a password for the certificate’s private key. When a password is required, users must provide a password when using the user portal to upload a certificate associated with this certificate enrollment setting.
Important: Always require a password unless both of the following are true: The devices that will use the user-provided certificate are iOS devices running Ivanti Mobile@Work 9.0 or supported newer versions AND The apps that will use the certificate are AppConnect apps.
When you do not require a private key password when the user uploads a certificate, Ivanti Mobile@Work for iOS and an AppConnect for iOS app that uses the certificate behave as follows:
- When the AppConnect app launches, control switches to Ivanti Mobile@Work for iOS.
- Ivanti Mobile@Work prompts the device user for the private key password.
- The device user enters the password.
If the device user exits Ivanti Mobile@Work without providing the password, when the AppConnect app next launches, Ivanti Mobile@Work unauthorizes the app, with the reason that the app is missing credentials.
- Control returns to the AppConnect app.
Whether you require a password depends on your security requirements. If a password is required, Ivanti EPMM stores the password along with the PKCS 12 file containing the certificate and private key. However, if your security environment requires limiting the password’s storage to the device that uses the certificate, then do not require a password.
When the private key of a user-provided certificate is deleted
The private key of a PKCS 12 file, and password if provided, can be deleted from the Ivanti EPMM file system. Whether you want the private key and password deleted from Ivanti EPMM depends on your security requirements.
The following mechanisms are available to delete the private key and password:
- A user can delete the private key and password using the user portal.
- A web services API can delete the private key and password.
- You can specify in the Admin Portal that Ivanti EPMM deletes private keys and passwords older than some number of days.
IMPORTANT: When the private key and associated password is deleted, Ivanti EPMM retains the public certificate and maintains an entry in its certificate table so it can track where the certificate is used, when it expires and display information about it in the UI. Without the private key and associated password, Ivanti EPMM is unable to use the identity certificate with any new certificate enrollments, AppConnect configuration and devices. Once the private key and associated password is deleted, the user-provided certificate must be uploaded again before it can be used.
Because the certificate without the private key is still available on Ivanti EPMM, you can view information about the certificate, such as its expiration date. This information can help you manage devices still using the certificate.
Related topics
- Ivanti EPMM V2 API Guide
Specifying the settings for a user-provided certificate enrollment setting
Procedure
- Go to Policies & Configs > Configurations and select Add New > Certificate Enrollment > User-Provided.
- Use the following guidelines to specify the settings:
- Name: Enter brief text that identifies this setting.
- Description: Enter additional text that clarifies the purpose of this setting.
- Display Name: Enter the name that will appear on the user portal where device users upload their certificates. This name also appears in Ivanti Mobile@Work if the app prompts the device user for a certificate’s private key password.
- Require Password: This option requires the user to provide a password for the certificate’s private key when uploading a certificate associated with this certificate enrollment setting. Additional formats for the existing $CERT_ALIAS:<config_name>$ app substitution variable used in Android Enterprise app restrictions. Administrators can now optionally append :b64 or :b64password to send either the uploaded user certificate in Base64 format or the certificate password to Google. If neither option is specified, the existing certificate alias behavior remains unchanged. Supported formats
- $CERT_ALIAS:<config_name>$
- $CERT_ALIAS:<config_name>:b64$
- $CERT_ALIAS:<config_name>:b64password$
The :b64 and :b64password options are optional. You can use only one option in a CERT_ALIAS variable. The format $CERT_ALIAS:<config_name>:b64:b64password$ is not supported. (1820370)
- Important: Always require a password except as described in The private key password.
- Delete Private Keys After Days: Select the number of days after a user-provided certificate is uploaded to Ivanti EPMM after which Ivanti EPMM deletes the private key and, if provided, its password, from Ivanti EPMM.
The default is None, which means Ivanti EPMM does not delete the private key and its password.
- Select Save.