I built such a system in our internal iPad app.

Forget about settings, profiles, etc. All certificates installed in this way are not available to third-party applications, but only to system applications, possibly because they are installed in the Apple chain.

I learned these three methods for uploading a certificate and used the latter:

• Investing in an application, as you have seen, is not practical.
• Send a file from another application (such as email)
• Use the download link (which I did)

FOREWORD

• I think you created your simil-PKI with a CA, an automatic / manual way to issue / revoke certificates, etc. So the problem is delivery to devices.
• For all solutions, I suggest storing the private key and certificate in PKCS # 12 format with a strong password.
• Use MDM for device management, and if your app is internal and will be used with branded devices, control them to add settings (for example, Meraki is free, but does not handle ManagedAppConfiguration).

SOLUTIONS

Solution 1)

Impractical because it is very difficult (impossible) to create different versions of the application with specific certificates. Not to mention, it will be nearly impossible to handle the distribution of a specific version on every user device.

Solution 2)

• Save the .p12 file
• change the file extension to a custom one.
• register this extension to open it with your application, so the "Open in ..." section will list your application "Open in" for a specific document type

The safest way is that the user can choose a password to encrypt the .p12 file, so when p12 is open, the user has to enter their password, but this will cause other work to get it working. A less secure but working method is to use a single strong password built into the app and use that for all .p12 files

Solution 3)

Likewise 2), but you are loading the file directly from a specific URI of your web application, this allows for some automatic configuration, because the application can identify itself.

Basically, these are the following steps:

• the app connects to a specific URL of our app via HTTPS.
• verifies the validity of the server certificate (trusted origin).
• send something for authentication.
  In our case, I use the device name that I configured during device provisioning and can change it remotely using MDM.
• download the config package with the certificate in it
  I am using a JSON payload to send an encoded PKCS # 12 database file and other data to configure the application.

If your MDM supports ManagedAppConfiguration, you can modify these operations slightly to create more flexible behavior: With ManagedAppConfiguration, you can send a specific string inside each NSUserDefaults application remotely, so you can use different or temporary URLs / tokens to load the configuration bundle and completely use device name for authentication.

WWDC 2014 # 704 - Build Enterprise & Education Apps ~
13:00 Apple Developer App - ManagedConfig Sample App

ADDED PARANOIA

• write everything down! Anything that part of the application does (failed / invalid requests, non-existent device name requests, etc.)

• The config url is only activated / deactivated when we need to configure new devices.
  You can do it in different ways, my webapp checks for the existence of a specific file, so I can do something like touch APP_CERTIFICATES_CONFIG_ENABLED
  
  to activate the autoconfiguration service and disable all file deletion.
  Just to make sure no certificate passes without my supervision.