11 iOS Device Management

This chapter covers the following sections broadly:

Section 11.1, "iOS Device Management with MDM"

Section 11.2, "Server and Security Configuration for iOS Mobile Device Management"

11.1 iOS Device Management with MDM

Mobile Device Management (MDM) is a feature of modern mobile platforms such as iOS and Android that allows managing mobile devices remotely from the server. Unlike previous device management solutions, MDM is built-in to the mobile operating system (OS) and does not require special device management application (like dmagent) running on the mobile device.

In addition, it provides a much broader spectrum of features than can be achieved by client-side device management application.

The following sections describe basics and features of the MDM architecture:

11.1.1 Introduction to iOS MDM

See the following sections:

11.1.1.1 Mobile Server and MDM

As mentioned above, support for MDM is built-in to iOS operating system. iOS devices exchange messages with Mobile Server using special MDM protocol, which enables to retrieve device information, send commands to devices, configure devices with various rights and restrictions and manage mobile applications. Apple has supported MDM for a while, however many new features and changes to the protocol have been added. Currently, Mobile Server supports management of devices running iOS 7.

Mobile Server seamlessly integrates iOS devices into the existing mobile architecture. iOS devices are assigned to users and managed using Mobile Manager. iOS applications can be published using Packaging Wizard, and iOS applications running on iOS devices can synchronize data stored in local sqlite or Berkeley DB database with Oracle back-end Database, using existing synchronization architecture.

However, some device management commands supported for other platforms are not yet supported for iOS. This includes synchronization-related commands.

For a high-level overview of iOS MDM, see the following: https://www.apple.com/iphone/business/it/management.html

Note:

Not all features described in the document (https://www.apple.com/iphone/business/it/management.html) are currently supported by Mobile Server.

In particular, we do not yet support Device Enrollment Program (where devices can be enrolled in MDM at device activation time) or Volume Purchasing Program (allowing purchasing of applications from iTunes Application Store).

For more information on MDM protocol and additional resources see Appendix D, "Description - MDM Architecture".

11.1.1.2 MDM and Push Notifications

Apple Push Notification Service is a cloud-based service run by Apple which is used to deliver short messages to iOS devices. The main purpose is to deliver notifications to iOS applications, but it is also a crucial part of MDM protocol to notify iOS devices that new commands are available (see Appendix D, "Description - MDM Architecture"). Devices listen to push notifications by having SSL connections to APNS servers. The details of these connections, as well as APNS servers themselves are managed by Apple, providing a seamless interface to the user. For more information about APNS, see: https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/Chapters/ApplePushService.html

Mobile Server sends push notifications to iOS devices by connecting to APNS Gateway and delivering appropriate message which will be used by APNS servers to deliver notification to the device. Usually push notifications are targeted for and processed by a particular application on the device. The target application is identified by a special string called push notification topic.

However, for MDM, push notifications are processed by iOS operating system MDM component. The topic string for MDM must start with a special prefix. For more information, see, Section 11.2.3.7.1, "Push Notification Topic".

Current address of production APNS gateway is gateway.push.apple.com, port 2195.

Note:

Both Mobile Server and your managed iOS devices must make SSL connections to APNS gateway for MDM to function. If either your Mobile Server or your iOS devices are behind firewall, you may have problems with managing your iOS devices. To fix those, your network administrator must open up some ports in the firewall.

Refer to the Apple support note: http://support.apple.com/en-us/HT203609

To cite this note, the following ports must be open:

  • TCP port 5223 (used by devices to communicate to the APNs servers)

  • TCP port 2195 (used to send notifications to the APNs)

  • TCP port 2196 (used by the APNs feedback service)

  • TCP Port 443 (used as a fallback on Wi-fi only, when devices are unable to communicate to APNs on port 5223)

11.1.2 Profiles and Device Enrollment

To manage iOS device, you must enroll it in MDM. See Section 7.11.1, "iOS Device Enrollment" to see the enrollment steps from the user's perspective. During and after enrollment, you can customize settings on your devices by installing configuration profiles. In fact, the enrollment itself is done via installing a special configuration profile on the device. For more information on configuration profiles and what happens during enrollment process, see the sections below:

11.1.2.1 Configuration Profiles

Configuration Profile is an XML file used to distribute iOS configuration information.It uses property list format (for information on property list format, see https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/PropertyLists/Introduction/Introduction.html). It allows you to specify restrictions on device features, WiFi settings, VPN settings, LDAP directory server settings and many others. In addition, certificates and keys can also be transmitted via configuration profiles. For full description of configuration profile capabilities and format, see Configuration Profile Key Reference here: https://developer.apple.com/library/ios/featuredarticles/iphoneconfigurationprofileref/introduction/introduction.html

Note:

Configuration profile files have extension .mobileconfig.

There are several ways to deploy configuration profiles to the devices. For example, a profile can be emailed to the device as an attachment. Once you open the attachment on iOS device, iOS will know that this is a configuration profile and will install it. However, the easiest way to deploy configuration profile is via MDM. Mobile Server, acting as MDM server, can push configuration profiles automatically to managed iOS devices.

Configuration profiles consist of one or several payloads. Usually there is a one main profile payload that contains other setting-specific payloads - other payloads being embedded as an array inside PayloadContent element. Here is an example of the profile used to configure device passcode settings:

<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
 <plist version="1.0">
 <dict>
     <key>PayloadContent</key>
     <array>
       <dict>
           <key>PayloadDescription</key>
           <string>Configures Configuration Profile security</string>
           <key>PayloadDisplayName</key>
           <string>Profile Security</string>
           <key>PayloadIdentifier</key>
           <string>com.oracle.dms.devpass.ProfileSecurity</string>
           <key>PayloadIdentifier</key>
           <string>com.oracle.dms.devpass.ProfileSecurity</string>
           <key>PayloadOrganization</key>
           <string>Oracle</string>
           <key>PayloadType</key>
           <string>com.apple.profileRemovalPassword</string>
           <key>PayloadUUID</key>
           <string>D3150EF6-299B-4D63-B803-341B159348B2</string>
           <key>PayloadVersion</key>
           <integer>1</integer>
           <key>RemovalPassword</key>
           <string>oracle</string>
      </dict>
      <dict>
           <key>PayloadDescription</key>
           <string>Configures security-related items.</string>
           <key>PayloadDisplayName</key>
           <string>Passcode</string>
           <key>PayloadIdentifier</key>
           <string>com.oracle.dms.devpass.passcodepolicy</string>
           <key>PayloadOrganization</key>
           <string>Oracle</string>
           <key>PayloadType</key>
           <string>com.apple.mobiledevice.passwordpolicy</string>
           <key>PayloadUUID</key>
           <string>6B7812F6-C86C-4AAF-BE5E-CB7A587D38D7</string>
           <key>PayloadVersion</key>
           <integer>1</integer>
           <key>allowSimple</key>
           <true/>
           <key>forcePIN</key>
           <true/>
           <key>maxFailedAttempts</key>
           <integer>10</integer>
           <key>maxInactivity</key>
           <integer>5</integer>
           <key>maxPINAgeInDays</key>
           <integer>730</integer>
           <key>minLength</key>
           <integer>5</integer>
           <key>pinHistory</key>
           <integer>10</integer>
  </dict>
</array>
<key>PayloadDescription</key>
<string>Device passcode policy.
</string>
<key>PayloadDisplayName</key>
    <string>Device passcode profile</string>
    <key>PayloadIdentifier</key>
    <string>com.oracle.dms.devpass</string>
    <key>PayloadOrganization</key>
    <string>Oracle</string>
    <key>PayloadRemovalDisallowed</key>
    <true/>
    <key>PayloadType</key>
    <string>Configuration</string>
    <key>PayloadUUID</key>
    <string>D34F4145-4FE8-4A4B-A45C-5857D54EAB2D</string>
    <key>PayloadVersion</key>
    <integer>1</integer>
 </dict>
</plist>

Note:

The same profile can configure several (and could be un-related) settings via embedded payloads. The following tools automate creation of configuration profiles so that you do not have to write XML manually:

You can create your own configuration profiles to customize the settings on your managed iOS devices. You can then upload these profiles to the Mobile Server via Mobile Manager interface. For more information, see Section 7.11.4, "iOS Profile Management on Mobile Manager".

Note:

All uploaded profiles will be deployed to all iOS devices when they enroll in MDM.

Configuration profiles can be either signed or unsigned. Signed profiles avoid having warning displayed on iOS device when the profile is installed. You do not need to sign configuration profiles that you upload to the Mobile Server (in any case iPhone Configuration Utility by default uses self-signed certificate which will not be trusted by the device). Mobile Server will sign the profiles automatically when they are uploaded.

MDM Certificate Authority (CA) is used for signing of the profiles. For more information on MDM CA, see Section 11.2.1, "Creating and Configuring Certificate Authority".

Another type of profile is provisioning profile. Provisioning profiles tell iOS device whether a given application can run and also what privileges that application may have. Provisioning profile files usually have extension .mobileprovision. Provisioning profiles can also be uploaded to the Mobile Server (see Section 7.11.4, "iOS Profile Management on Mobile Manager") and will be deployed to all iOS devices that enroll in MDM. See Section 11.1.4, "Managing iOS Applications" for more details.

11.1.2.2 Device Enrollment Process

During enrollment process:

  • Device receives Certificate Authority certificate that allows it to trust Mobile Server.

  • Mobile Server uniquely identifies the device and stores this identification in repository.

  • Device receives special configuration profile allowing it to receive and execute commands from Mobile Server.

  • Mobile Server receives initial detailed information about the device that would be displayed in Mobile Manager (see Section 7.11.2, "View iOS Device Information"). You can refresh this information by using corresponding MDM commands (see Section 11.1.3.2, "Commands").

  • All uploaded configuration and provisioning profiles will be installed on the device.

  • All published applications for chosen platform (iOS Berkeley DB or iOS SQLite) to which the user has access will be installed on the device.

See Appendix D, "Device Enrollment Process," for more information on device enrollment process used by Mobile Server.

11.1.3 iOS MDM Commands

MDM protocol contains a rich set of commands (described in MDM Protocol Reference, see Chapter D, "Additional Resources"), not all of which are currently supported by Mobile Server. Here we will mention the commands that are currently supported. Section 7.11.3.3, "View Command History," describes Mobile Manager interface for sending the commands to iOS devices.

The commands, by nature, are asynchronous. It may take some time between when the command is sent to the device and the status and the results are received back (though usually it happens very fast). When the status and results are received by Mobile Server, they will be stored in the repository and can be retrieved for display in Mobile Manager. You may have to wait and refresh "Device Info", "Software Info" and "Command History" tabs if you do not see the results right away.

You can find the current state of the command by looking at the command status. The following sections discuss commands and command status information:

11.1.3.1 Command Status

You can find the status of each command on the Command History page in Mobile Manager. See Section 7.11.3.3, "View Command History" for more information on Command History page. Here we list command status values:

  • Command Queued - Command has been queued in the Mobile Server repository command queue but has not been sent to the device yet.

  • Push Notification Sent - Mobile Server has sent push notification to wake up the device and prompt it to poll the server for commands.

  • Command Sent - Command has been sent to the device.

  • Command Succeeded - Device successfully executed the command. Mobile Server has received the command status and results, if any, and stored them in the repository.

  • Command Failed - Device has failed to execute the command and sent the error information back to the Mobile Server. Additional error information may be displayed.

  • Device Not Ready - Sometimes device is unable to execute a command at a certain time, but the command can be executed at a future time. In this case, device sends a special NotNow status to the Mobile Server. Once device is ready to execute the command, it will poll the server again. This only applies to certain commands. Some commands can always be executed and are immune to the NotNow status. You can find more information on NotNow status in MDM Protocol Reference, see Appendix D, "Additional Resources". When describing the commands we will indicate which commands can always be executed.

  • Command Execution Started - Not all commands are pure MDM commands (that is described by command cycle in Appendix D, "MDM Command Cycle"). There are commands that may send more than one MDM command to the device and also perform server-side logic in between. For example, "Update Application" command will first send "Retrieve Software Information" to get the current application version installed on the device. It will then compare retrieved version with current published version of the application on the server, and only if a later version is published, will send "Install Application" command to the device to install the new application version.

    We call these commands "Composite Commands". Composite commands start with "Command Execution Started" status. The only other valid status values for composite commands are "Command Succeeded", "Up To Date", and "Command Failed".

    Note:

    The Command History page in Mobile Manager will display both composite commands and constituent MDM commands that they invoked.

  • Up To Date - This status is only valid for "Update Application" command and tells that application installed on the device is of latest version published, so no installation action was taken.

  • MDM Protocol Error - Device has received malformed command. Contact Oracle Support for assistance. Additional error information may be displayed.

  • Failed to Prepare Command - Mobile Server failed to prepare command payload. This usually indicates problem with Mobile Server repository. Contact Oracle Support for assistance. Additional error information may be displayed.

  • Failed to Process Result - Mobile Server failed to process result payload from the device. This usually indicates problem with Mobile Server repository. Contact Oracle Support for assistance. Additional error information may be displayed.

11.1.3.2 Commands

The following commands are supported for iOS devices (see Section 7.11.3, "iOS MDM Command Management" on how to send commands using Mobile Manager interface):

  • Install Configuration Profile for iOS Device - You can choose one of the profiles you uploaded (see Section 7.11.4, "iOS Profile Management on Mobile Manager").

    Note:

    All uploaded profiles will be installed on the device at enrollment time. You only need to use this command to install additional profiles uploaded after device has enrolled in MDM.

  • Remove Configuration Profile for iOS Device - Removes configuration profile from the device (you can choose from the list of the profiles you uploaded).

  • Install Provisioning Profile for iOS Device - You can choose one of the provisioning profiles you uploaded (see Section 7.11.4, "iOS Profile Management on Mobile Manager").

    Note:

    All uploaded provisioning profiles will be installed on the device at enrollment time. You only need to use this command to install additional provisioning profiles uploaded after device has enrolled in MDM.

  • Remove Provisioning Profile for iOS Device - Removes provisioning profile from the device (you can choose from the list of the provisioning profiles you uploaded).

  • Device Information - Once Mobile Server receives device information, it will be displayed on the "Device Info" page (see Section 7.11.2, "View iOS Device Information"). As mentioned above, you may have to refresh "Device Info" page if the updated information does not appear immediately.

    Note:

    The device information will be collected from the device when it enrolls. You only need to use this command to get up-to-date information that may have changed (for example, battery level or free disk space).

  • Retrieve iOS Security Information - This information is complimentary to the device information and will be displayed on the "Security" panel of "Device Info" page (see Section 7.11.2, "View iOS Device Information"). MDM protocol uses different command to retrieve this information (as opposed to "Retrieve Device Information"). The same considerations above apply to this command as to "Retrieve Device Information".

  • Lock iOS Device - Locks device. Optionally, a message can be provided to be displayed on device screen when it is locked (it will only be displayed if device is protected by passcode). Otherwise default message will be displayed.

    This command is helpful when the device gets lost. The message may indicate a contact information where to return the device.

  • Clear Passcode for iOS Device - Clears passcode from the device.

    Note:

    If a configuration profile with passcode requirement is installed on the device, the device will require a new passcode to be entered within 60 minutes.

  • Erase iOS Device - Reset device to factory settings. All information on the device will be lost. This command is used when the device is lost or stolen. The device will need to re-enroll into MDM.

  • Retrieve Software Information - Retrieve installed application information from the device, such as version, size, etc. You can either choose which application to retrieve for, or choose to retrieve for all applications.

    Note:

    Only information for managed applications will be retrieved, that is only applications that were installed from Mobile Server via MDM (as opposed to applications installed by device's user from elsewhere). The information retrieved will be displayed on "Software Info" page in Mobile Manager (see Section 7.11.2, "View iOS Device Information"). As for "Device Info" page, you may have to refresh this page if the updated information does not appear immediately.

  • Retrieve iOS Application Status - Retrieve application status for one or all applications. This information will also be displayed on "Software Info" page in Mobile Manager, in "Status" column. This command is used to get up-to-date installation status of the application (since some applications may take a while to install) and find if any problems have occurred during installation. Here is the excerpt from MDM Protocol Reference (see, Chapter D, "Additional Resources") describing possible status values (we omitted values that are not relevant to enterprise-distributed applications):

    • Installing - The application is being installed.

    • Managed - The application is installed and managed.

    • ManagedButUninstalled - The application is managed, but has been removed by the user. When the application is installed again (even by the user), it will be managed once again.

    • Updating - The application is being updated.

    • Unknown - The application state is unknown.

    The following statuses are transient, and are reported only once:

    • UserInstalledApp - The user has installed the application before managed application installation could take place.

    • UserRejected - The user rejected the offer to install the application.

    • UpdateRejected - The user rejected the offer to update the application.

    • Failed - The application installation has failed.

  • Install Application - Installs one of the published applications on the device.

    Note:

    If this command is issued for an application already installed on the device, it will be treated as an update. Application data should not be lost in this case.

  • Remove iOS Application - Uninstalls application from the device. All application data on the device will be removed.

  • Update iOS Application - This is a composite command. It will check what version of application is installed on the device and will compare it with the version published on Mobile Server.

    If higher version is published (or if application is not installed on the device), "Install Application" command will be issued to update the application. Otherwise, the status of this command will be set to "Up To Date".

  • Update All iOS Applications - Same as "Update Application" command, but does for all managed applications assigned to the device's user.

  • Un-enroll iOS Device from MDM - Terminates device's enrollment so that the device becomes unmanaged. This is done via removing configuration profile with MDM payload that was installed on the device during enrollment (see Section 11.1.2.2, "Device Enrollment Process").

    Removing this profile will automatically remove all the configuration and provisioning profiles and all the applications installed by Mobile Server. All the information in the Mobile Server repository pertaining to this device will be removed.

11.1.4 Managing iOS Applications

This section describes concepts and issues related to managing iOS applications with Mobile Server.

11.1.4.1 Provisioning Profiles

To run on iOS devices, every application must be digitally signed. There are two kinds of signing certificates - for development and for production. Both can be obtained from Apple Developer's portal. Xcode creates certificate signing request and submits it to the portal. Once approved, the developer will have a signing identity to sign the application. The signing certificate itself is signed by Apple Certificate Authority, so it will be trusted by the device.

However, even when signed, Apple wants to restrict which devices can run the application. Otherwise, an application can avoid going through Apple AppStore approval process that verifies that the application is safe for anybody to use. That is where provisioning profiles come in.

Provisioning profile is an XML file in plist format (see Section 11.1.2.1, "Configuration Profiles"). This files have extension .mobileprovision. There are different provisioning profiles for development and production.

Development provisioning profiles are used for application development and testing. They ensure that the application can run only if it is built and signed by certain developers or team registered on the portal and only on certain devices which also have to be registered on the portal. Development provisioning profile contains:

  • Application Identifier

    This can contain wildcards so that it can match multiple application bundle ids. For example, if the application identifier is com.oracle.*, it will cover all applications for which the bundle id starts with com.oracle.

  • List of developer certificates who are allowed to build and sign the application. Usually it includes all developers in the team.

  • List of UDIDs of devices on which application is allowed to run.

  • Other information like creation and expiration dates, and others.

An application will only run on the device if the provisioning profile is installed on the device and if all of the following is true:

  • Application bundle id matches the profile's application identifier.

  • Application is signed by one of the certificates listed in the profile.

  • The device's UDID is listed in the profile.

You do not create provisioning profiles manually, instead they are created on the developer's portal (see Section 11.1.4.2, "Preparing and Publishing iOS Application") from where you can download them. Each profile is signed by Apple. You can open .mobileprovision file in text editor (the binary data you would see around the text is the signature container in CMS format, see http://tools.ietf.org/html/rfc5652) to find more information.

Distribution provisioning profiles are used either for submission of the application to the AppStore or for the enterprise app distribution. We will not cover the former here since the later is what you need to publish and manage your application from the Mobile Server (see Section 11.1.4.2, "Preparing and Publishing iOS Application").

Apple allows you to distribute your application to a limited audience in your Enterprise. Because of this, distribution provisioning profiles do not specify list of devices (you will see ProvisionsAllDevices key in the profile if you open it in text editor), which means that the application can run on all devices on which the provisioning profile is installed. In addition, the list of certificates in the profile usually contain only one certificate, the one with which the application was signed.

Note:

You must be a team administrator in Enterprise Developer's Program to create distribution provisioning profiles (see Section 11.1.4.2, "Preparing and Publishing iOS Application").

11.1.4.2 Preparing and Publishing iOS Application

Applications managed by MDM use Apple's Enterprise Distribution model. In this model, applications do not need to be submitted to Apple AppStore, but instead are distributed in-house to your employees and customers. This approach does not require Apple AppStore approval process and the applications are distributed to limited audience only instead of general public.

You must have Apple Enterprise Developer Account to create and distribute Enterprise Applications. You can apply for Enterprise Program here: https://developer.apple.com/programs/ios/enterprise/

For information to get started with Enterprise Program, see https://developer.apple.com/programs/ios/enterprise/gettingstarted/

To distribute iOS Application for enterprise you must obtain distribution certificate (signing identity) as well as distribution provisioning profile, as opposed to developer certificate and developers provisioning profile. To get more information on this, you can use the following resources:

Note:

You must be a (or contact) team administrator to create distribution certificates and provisioning profiles.

The following steps help to build and distribute your enterprise application and publish it to the Mobile Server (based on sample "TransportDemo" application):

  • Open your application project in Xcode (on your Mac machine). Ensure that you set your build scheme to built for iOS device and choose Release Configuration (you can do so from the menu Product -> Scheme -> Edit Scheme) (although you can use Debug Configuration as well if need arises). See Figure 11-1.

    Figure 11-1 Setting Release Build Configuration in Xcode


  • Select your project in project navigator. Select your application target on the left and select "Build Settings" tab (in your application target build settings). Ensure to choose distribution code signing identity for Release build. See Figure 11-2.

    Figure 11-2 Setting Code Signing Identity in Xcode


  • Build your application (Cmd-B or from the Product menu).

  • Go to menu Product -> Archive, after successful build. Click on "Distribute" See Figure 11-3.

    Figure 11-3 Archiving your Application


  • Choose "Save for Enterprise or Ad Hoc Deployment" and click "Next". See Figure 11-4.

    Figure 11-4 Distributing your Application


  • Ensure your distribution provisioning profile is selected and click "Export". See Figure 11-5. You will see a dialog box as in Figure 11-6.

    Figure 11-5 Choosing Provisioning Profile for Distribution


  • Export your application as .ipa archive file. Choose the destination directory. Check the check-box "Save for Enterprise Distribution". You will be prompted to enter some information. See Figure 11-6.

    Figure 11-6 Exporting your Application


    Application URL is the URL where your application will be hosted on Mobile Server. The URL should be in the following format:

    https://mobile_server_host:mobile_server_port/mobile/app_virtual_path/app_name.ipa

    where:

    • mobile_server_host and mobile_server_port are the Mobile Server host and port respectively.

      Note:

      The HTTPS protocol is required, so you would need to provide your HTTPS port.

    • app_virtual_path is the virtual path for your application. It is the same virtual path that you specify when you publish your application using Packaging Wizard.

    • app_name.ipa is the name of the application archive that you are going to save.

      Note:

      If not correctly specified at this time, you can make adjustments to the application URL in the resulting .plist manifest file.

    • Title is the name of your application.

      Note:

      To correctly publish your application to the Mobile Server, the name of your application must be the last part of your application bundle id. For example, if your application bundle id is com.oracle.TransportDemo, your application name must be TransportDemo.

  • You can enter additional information in the fields below "Title", though it is optional.

  • Click "Save". You will have 2 files with extension .ipa and .plist (for example, TransportDemo.ipa and TransportDemo.plist). The first file is the application archive. The second file is the application manifest.

  • Use Packaging Wizard as described in Chapter 5 "Using the Packaging Wizard"of the Mobile Server Developer's Guide to publish the application to Mobile Server.

    Note:

    • For iOS applications, you do not enter application name in Packaging Wizard. Instead you will need to choose your .plist manifest file from which the Packaging Wizard will retrieve the application bundle id and derive the application name accordingly as the last part of the bundle id (see Section 5.1.2 "Specifying New Application Definition Details" of the Mobile Server Developer's Guide).

    • The Virtual Path you specify in Packaging Wizard must be the same as the app_virtual_path you specified in the Application URL above.

    • You must upload two files as part of your application (see Section 5.1.3 "Listing Application Files" of the Mobile Server Developer's Guide): .ipa archive and .plist application manifest.

    • Once application is published, you will find your application files under directory MOBILE_HOME\Mobile\Server\admin\repository\app_virtual_path, where app_virtual_path is the virtual path you specified above. You can open .plist manifest file in text editor and make adjustments to the application URL if needed.

    • Once published, use Mobile Manager to grant application access to users and groups (see Section 3.6.1, "Granting Application Access to Users and Groups").

11.1.4.3 Application Security Considerations

Access to application archives hosted on your Mobile Server is not restricted by authentication. Anyone who can access your Mobile Server can download application .ipa archive by using the application URL you specified for Enterprise distribution (see Section 11.1.4.2, "Preparing and Publishing iOS Application"). The reason for this is that iOS application installation process does not currently use client certificate authentication.

This means that you must not store unencrypted sensitive information within your application bundle. Any sensitive information must only be available to an authenticated user. One way to do this would be to provide a login screen for the user at the application startup.

11.2 Server and Security Configuration for iOS Mobile Device Management

Managing iOS devices with Mobile Server using MDM protocol requires additional configuration. For better understanding of the requirements and the configuration steps, see Section 11.1, "iOS Device Management with MDM".

The following are additional security features of iOS MDM:

  • All the communication between the Mobile Server and iOS devices has to be done over SSL (HTTPS) protocol. Also, self-signed SSL certificates cannot be used for MDM.

  • MDM uses client certificate authentication to authenticate iOS devices when they connect to the Mobile Server. Each device needs to be identified by its Identity Certificate. In addition, Over The Air (OTA) device enrollment requires to issue additional temporary certificates. This requires creating and configuring Certificate Authority.

  • MDM uses Apple Push Notification Service (APNS) to notify devices that new commands are available. APNS requires Mobile Server to have a valid Push Notification Certificate so that it can authenticate itself to the Apple's APNS Service.

The following sections describe the necessary configuration steps to setup MDM with Mobile Server:

11.2.1 Creating and Configuring Certificate Authority

Mobile Server needs to use Certificate Authority for the following reasons:

  • iOS devices enroll in MDM using Over the Air (OTA) profile delivery and configuration. For information on OTA process, see: https://developer.apple.com/library/ios/documentation/networkinginternet/conceptual/iphoneotaconfiguration/Introduction/Introduction.html

    During the enrollment process a configuration profile with MDM payload is delivered to the device.

    Note:

    This process requires a certificate to be issued for the device. Mobile Server uses similar process as described in the "Over-the-Air Profile Delivery Concepts". See here: https://developer.apple.com/library/ios/documentation/networkinginternet/conceptual/iphoneotaconfiguration/OTASecurity/OTASecurity.html#//apple_ref/doc/uid/TP40009505-CH3-SW1

    The only difference is that currently SCEP protocol is not used to issue device certificates.

    Instead, Mobile Server creates and signs device certificates which are then sent to the device over secure connection.

  • MDM uses client certificate authentication to verify device identities of iOS devices connecting to Mobile Server. MDM protocol requires to issue an Identity Certificate (certificate bundled together with its private key) for each device.

    The Identity Certificate must be unique for each device. During SSL handshake, the device presents its Identity Certificate to the application server. In addition, once the device is authenticated over SSL, Mobile Server reads the certificate and verifies its identity (in fact, Identity Certificates are issued with the Subject Common Name being the device's UDID).

  • If you use Mobile Server only to manage iOS devices, you can sign your server's SSL certificate with the CA you created instead of buying SSL certificate from trusted Certificate Authority. The CA that you have will be deployed to each iOS device during enrollment process, which means that the managed iOS devices will trust your server's SSL certificate. For more information, see Section 11.2.2, "SSL Configuration for MDM".

    You do not need to worry about managing iOS device's MDM certificates as Mobile Server takes care of it. The only requirement is that you create or obtain a CA and import it to the location where Mobile Server can find it. This can be done via one of the following:

    • Create your own private CA. This will probably be the most common approach. For more information, see Section 11.2.1.1, "Creating Private CA".

    • If you already possess an Enterprise-level Certificate Authority, you can also use it for MDM (an example would be Windows Active Directory CA).

The following sections describe the necessary steps:

11.2.1.1 Creating Private CA

The private certificate authority is a self-signed certificate that is used to sign other certificates. The easiest way to create it is with using openssl command line tool. If you are on Linux or Mac, openssl must be available. For Windows, you can download openssl from here:

http://slproweb.com/products/Win32OpenSSL.html

You can find more information on openssl from: https://www.openssl.org

To create your private CA, do the following:

  1. Create private key file:

    openssl genrsa -out myCA.key 2048

    This generates 2048 bit private key.

  2. Create the CA self-signed certificate:

    openssl req -x509 -new -key myCA.key -out myCA.cer -days 1000

    Note:

    openssl will ask you for some information. Enter as required.

    Here is an example:

    >openssl req -x509 -new -key myCA.key -out myCA.cer -days 1000
Loading 'screen' into random state - done
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [US]:US
State or Province Name (full name) [Some-State]:California
Locality Name (eg, city) []:Redwood Shores
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Oracle
Organizational Unit Name (eg, section) []:Database Mobile Server
Common Name (e.g. server FQDN or YOUR name) []:My Custom CA
Email Address []:

    Alternatively, you can skip this by specifying only Subject Common Name:

    openssl req -x509 -new -key myCA.key -out myCA.cer -days 1000 -subj /CN="My Custom CA"

    This will create self-signed CA certificate valid for 1000 days.

  3. Package the certificate and the private key together into PKCS12 format (.p12 extension):

    openssl pkcs12 -export -out myCA.p12 -in myCA.cer -inkey myCA.key

    Note:

    This asks you for the export password, choose non-empty password.

11.2.1.2 Importing the CA into Mobile Server MDM Keystore

For iOS MDM, Mobile Server uses Java Keystore (.jks extension). It is located in the following directory:

MOBILE_HOME\Mobile\Server\admin\repository\devmgr\apple\mdm\cert

where MOBILE_HOME is your Mobile Server installation directory. The keystore file name is keystore.jks

The keystore may contain 2 types of entries:

  • Trusted Certificate Entry - just certificate with its public key

  • Private Key Entry - certificate (with its public key) together with the corresponding private key

The keystore is protected by password. In addition, each Private Key Entry is also protected by its own password.

Note:

For Mobile Server MDM Keystore, the password is the same as your Mobile Server Repository password (the database password for your Mobile Server Repository schema). In addition, the same Mobile Server Repository password is used for every Private Key Entry in the MDM Keystore.

You can use Java keytool utility to access and modify Java keystore. For more information on keytool, see http://docs.oracle.com/javase/6/docs/technotes/tools/solaris/keytool.html Keytool should be available wherever JDK is installed.

Note:

You must import the CA as a Private Key Entry to the MDM Keystore because its private key will be used to sign MDM certificates.

Following the previous example:

cd %MOBILE_HOME%\Mobile\Server\admin\repository\devmgr\apple\mdm\cert

keytool -importkeystore -srckeystore myCA.p12 -srcstoretype pkcs12 -destkeystore keystore.jks -srcalias 1 -destalias oracle.dms.mdm.ca

Keytool asks you for source keystore and destination keystore passwords. For source keystore, enter the password that you chose when creating myCA.p12 (openssl pkcs12...). For destination keystore, remember to use Mobile Server Repository password.

Note:

The source alias is specified as 1. When .p12 file is created, most likely alias name 1 is chosen for the private key entry. If you get an error from the previous command, you can always list the contents of .p12 file:

keytool -v -list -keystore myCA.p12

and find the source alias name.

Note:

You will also see that the destination alias is specified as "oracle.dms.mdm.ca". It is important that you enter destination alias exactly as specified above. Mobile Server uses this alias name to find the CA entry.

11.2.1.3 Importing the CA into the Application Server Trust Store

When iOS device connects to Mobile Server, it will first be authenticated by your Application Server's SSL layer. Application Server will do that by examining the device's Identity Certificate which is issued by the CA described above. For application server to trust the device's identity certificate, you need to import the CA into the application server's trust store. The procedure differs depending on which application server you are using. See the sections below:

11.2.1.3.1 Glassfish

For Glassfish, the trust store is located in your domain subdirectory:

GLASSFISH_HOME\domains\DMS_Domain\config

where GLASSFISH_HOME is the installation directory of the Glassfish Server and DMS_Domain is the domain under which you are running Mobile Server. In this directory you will see 2 Java keystore files:

  • keystore.jks

  • cacerts.jks

You must import your CA certificate into the trust store cacerts.jks:

keytool -import -keystore cacerts.jks -alias myCA -file myCA.cer

Note:

We only need to import the CA as trusted certificate, not the private key entry, so we can use the certificate file myCA.cer that we generated previously. Also, the alias name does not matter here so you can choose any alias (that is not already used in cacerts.jks).

You are prompted for the keystore password (the default password for Glassfish keystores is "changeit") and also asked whether to trust the certificate, answer "yes" to this.

11.2.1.3.2 WebLogic

For WebLogic, you can configure the location of your keystore (also called Identity Keystore) and your trust store (also called Trust Keystore). For information on SSL and security configuration, see

http://docs.oracle.com/cd/E13222_01/wls/docs81/secmanage/ssl.html

In short, the process is as below:

  • Choose the directory location and file names for your keystore and your trust store. You can choose the same file to use for both of them. For our example, we assume mykeystore.jks and mytruststore.jks.

  • Import your CA certificate in your trust store (same as for Glassfish):

    keytool -import -keystore mytruststore.jks -alias myCA -file myCA.cer

    Note:

    This command creates the trust store (mytruststore.jks) if it does not exist. Enter password and choose to trust the certificate when prompted.

  • Login to the WebLogic Administration Console. It should be at URL: http://myhost:my_admin_port/console

  • Navigate to "Servers" (under "Environment" node), choose your server. You will be looking at "Configuration" tab. Ensure "SSL Listen Port" checkbox is selected.

  • Click on "Keystores" tab. If you have just installed the server, your setting will be "Demo Identity and Demo Trust". Click "Change" button and from the drop-down list on the next screen choose "Custom Identity" and "Custom Trust". Click "Save".

  • Enter path to the keystore file, keystore password, and keystore type (for each Identity Keystore and Trust Keystore), which for our example must be "JKS". Click "Save".

  • Switch to "SSL" tab. Ensure that "Identity and Trust Locations" are set to "Keystores" (if it is not, change and save it).

11.2.1.4 Important Considerations

See the sections below:

11.2.1.4.1 Changing Repository Password

Changing repository password is described in Section 9.2.1, "Modifying Repository Password". After you change the repository password, you must also change the password of the MDM keystore (see Section 11.2.1.2, "Importing the CA into Mobile Server MDM Keystore"), because the password of the MDM keystore must match your repository password. You can do it with this command:

cd %MOBILE_HOME%\Mobile\Server\admin\repository\devmgr\apple\mdm\cert

keytool -storepasswd -keystore keystore.jks

You are prompted for old and new repository passwords.

Ensure to restart the server (you can do the command above between steps 4 and 5 in Section 9.2.1, "Modifying Repository Password").

11.2.1.4.2 Dealing with Certificate Expiration

Mobile Server issues device certificates for the same duration as the duration of your CA. When your CA certificate expires, you must create new CA according to the procedures outlined above and re-import it into MDM keystore and your Application Server truststore. This can be done the same way as described above, except that before importing the new entry into keystore, you must delete the old entry that has the same alias:

keytool -delete -alias alias_name -keystore keystore_name

where, alias_name and keystore_name are the names of the alias and the keystore file.

We do not have a way to automatically provision new certificates to all managed devices, so when CA certificate expires, all managed devices will have to re-provision new CA certificate from Mobile Server setup page and re-enroll into MDM. It is recommended to use a long duration for your CA certificate.

If you are concerned about security, you can always increase the bit length of your private key (see openssl genrsa command in Section 11.2.1.1, "Creating Private CA"). The device certificates will be issued with the same bit length (this will have a tradeoff for RSA performance). It is advisable to use 4096 bit keys for certificates with long duration.

11.2.2 SSL Configuration for MDM

For MDM to function, run Mobile Server in SSL mode. For information on SSL setup process, see Section 9.4, "Configuring for Secure Socket Layer (SSL) Communication". However, the self-signed server SSL certificate with which most application servers come by default will not work for MDM because iOS MDM process will not trust self-signed SSL certificate. There are two options:

11.2.2.1 Creating SSL Certificate Signed by Private CA

You can use SSL certificate signed by your private (or enterprise-level) Certificate Authority if any of the following applies:

  • You plan to use Mobile Server only to manage iOS devices.

  • You plan to use Mobile server to manage other devices as well, but you do not need SSL functionality for other platforms. In this case, other devices can access Mobile Server through regular HTTP.

  • You plan to use SSL for other devices, but can provision the CA certificate to those devices.

  • You plan to use SSL for other devices, but also set DISABLE_SSL_CHECK parameter to TRUE (see Section 9.4.1, "Creating an SSL Certificate")

If none of the above applies, you must obtain your SSL certificate from the trusted certificate authority.

To create SSL certificate signed by your CA, you can use "openssl" (see Section 11.2.1, "Creating and Configuring Certificate Authority"):

openssl genrsa -out svrcert.key 2048

openssl req -new -out svrcert.csr -key svrcert.key

Loading 'screen' into random state - done
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [US]:US
State or Province Name (full name) [Some-State]:California
Locality Name (eg, city) []:Redwood Shores
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Oracle
Organizational Unit Name (eg, section) []:DMS
Common Name (e.g. server FQDN or YOUR name) []:pc1.oracle.com
Email Address []:
 
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

openssl x509 -req -in svrcert.csr -out svrcert.cer -CAkey myCA.key -CA myCA.cer -days 1000 -CAcreateserial -CAserial serial

openssl pkcs12 -export -out svrcert.p12 -in svrcert.cer -inkey svrcert.key

  • The "openssl req" command creates a certificate service request (CSR) to be signed by your CA. It asks you for some information. You can enter most as you think required, except the following:

    Note:

    The Common Name of the certificate must match your server's host name (which can be fully qualified domain name) or IP address. This is required for SSL to work. You should use the same hostname (or ip address) that iOS devices will use to enroll in MDM.

  • The "openssl x509" command creates a certificate based on the CSR you created signed by your CA. It uses files myCA.key and myCA.cer created previously (see Section 11.2.1.1, "Creating Private CA"). The options -CAcreateserial and -CAserial facilitate creating serial numbers for the certificates in case you need to create multiple certificates with successive serial numbers.

  • The "openssl pkcs12" command packages your certificate and private key into PKCS12 bundle so that it can be easily imported into Java keystore.

11.2.2.2 Importing SSL Certificate into Application Server's Keystore

Once you have your SSL certificate signed either by trusted CA or your private CA, you must import it into your Application Server's keystore. It must be imported as Private Key Entry (containing both certificate and the private key). The procedure differs depending on which application server you are using. See the sections below:

Note:

For more information on how application servers are configured for MDM, see Appendix D, "Application Server Configuration for MDM."
11.2.2.2.1 Glassfish

For Glassfish, the keystore is located in your domain subdirectory:

GLASSFISH_HOME\domains\DMS_Domain\config

(see Section 11.2.1.3.1, "Glassfish") and is named keystore.jks. The easiest way is to import it at the same alias as the default self-signed certificate created by Glassfish, thus replacing default entry.

For this you must delete the default entry first. The alias name of the default entry should be "s1as".

You can also login to the Glassfish Administration Console, go to SSL settings and check the certificate alias name. It will also give you an option to change it if you wish to do so. Continuing from the example above, you can issue the following commands:

cd GLASSFISH_HOME\domains\DMS_Domain\config

keytool -delete -alias s1as -keystore keystore.jks

keytool -importkeystore -srckeystore svrcert.p12 -srcstoretype pkcs12 -destkeystore keystore.jks -srcalias 1 -destalias s1as -trustcacerts

The last option (-trustcacerts) is used to look for certificate chain in file cacerts.jks since this is where you imported your CA certificate previously (see Section 11.2.1.3.1, "Glassfish"). This allows the keytool to trust your certificate so that it can be successfully imported.

You are prompted for destination and source passwords. For source password, use the one you entered during "openssl pkcs12" command. For destination password, use the Glassfish keystore password, which by default is "changeit".

Once the configuration is done, restart Mobile Server and check that you can connect to it via SSL. Before that, you can import your CA certificate into the browser. If you do that, or if your SSL certificate was obtained from trusted CA, you must be able to connect without seeing "untrusted" warning from the browser.

11.2.2.2.2 WebLogic

For WebLogic Server, you can configure the location of your keystore (also called Identity Keystore) and your trust store (also called Trust Keystore). For information on importing your CA into the Trust Keystore, see Section 11.2.1.3.2, "WebLogic". Follow the steps below:

  • Choose the directory location and file names for your keystore and your trust store (see Section 11.2.1.3.2, "WebLogic"). For our example, we assume mykeystore.jks and mytruststore.jks.

  • Import your SSL certificate/private key into your keystore in the same way as it is done for Glassfish (see Section 11.2.2.2.1, "Glassfish"):

    keytool -importkeystore -srckeystore svrcert.p12 -srcstoretype pkcs12 -destkeystore mykeystore.jks -srcalias 1 -destalias mysslalias -trustcacerts

    This command creates the keystore (mykeystore.jks) if it does not exist. At this point you can choose your destination alias name (mysslalias in the example).

  • Login to the WebLogic Administration Console. It must be at URL: http://myhost:my_admin_port/console

  • Navigate to "Servers" (under "Environment" node), choose your server. You will be looking at "Configuration" tab. Ensure "SSL Listen Port" checkbox is selected.

  • Click on "Keystores" tab. If you just installed the server, your setting will be "Demo Identity and Demo Trust". Click "Change" button and from the drop-down list on the next screen choose "Custom Identity and Custom Trust". Click "Save".

  • Enter path to the keystore file, keystore password, and keystore type (for each Identity Keystore and Trust Keystore), which for us must be "JKS". Click "Save".

  • Switch to "SSL" tab. Ensure that "Identity and Trust Locations" are set to "Keystores" (if it is not, change and save it).

  • Enter the alias under which you imported your SSL private key (mysslalias in the example above), on the same page, in the "Identity" panel (under "Identity and Trust Locations"). Also enter private key passphrase which must be your identity keystore (mykeystore.jks) password. Click "Save".

    Once the configuration is done, restart Mobile Server and check that you can connect to it via SSL. Before that, you can import your CA certificate into the browser. If you do that, or if your SSL certificate was obtained from trusted CA, you must be able to connect without seeing "untrusted" warning from the browser.

11.2.3 Obtaining and Importing APNS Certificate

MDM protocol uses Apple Push Notification Service to notify the managed devices when new commands are available for them. For more information on APNS, see: https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/Chapters/ApplePushService.html

For information on how Apple Push Notifications are used in MDM, see, Section 11.1, "iOS Device Management with MDM".

Mobile Server must have APNS certificate so that APNS service can authenticate it. Unlike APNS certificates for iOS applications, APNS certificate for MDM is not tied to a particular application id, and a slightly different procedure is used to obtain it.

Apple recognizes the following two roles:

  • MDM Vendor

  • MDM Customer

MDM Vendor is a company providing MDM solution (for example, Oracle). MDM Customer is a company that buys MDM solution to manage iOS devices. The following steps outlines the procedure to obtain APNS certificate:

  • Vendor obtains MDM CSR Signing Certificate.

  • Customer creates a private key and Certificate Signing Request (CSR) for the APNS certificate and submits it to the Vendor.

  • Vendor signs the CSR submitted with their MDM CSR Signing Certificate and returns signed CSR to the Customer.

  • Customer submits the signed CSR to Apple Push Certificate Portal and the portal issues APNS certificate which the customer can download.

  • Customer imports APNS certificate and its private key into MDM keystore.

For more information, see the sections below:

Note:

A Customer having an iOS Developer Enterprise Account can easily become a MDM Vendor by doing one of the following:

Since most customers must have Enterprise account anyway to develop and distribute Enterprise applications, they can also assume the Vendor role. This is most expedient option since this allows you to obtain APNS certificate without any external dependencies.

Thus, in this guide we will describe the steps for both Vendors and Customers.

If you do not wish to assume the Vendor role, contact Oracle Support for the Vendor-specific steps.

11.2.3.1 Obtain MDM CSR Signing Certificate

Follow the steps below:

  • Go to developer portal at https://developer.apple.com/, click on "Member Center" (top right) and sign in with your Apple ID.

  • Click on "Certificates, Identities & Profiles".

  • Navigate to "Certificates" and click "+" (top right of the table on the right).

  • Select "MDM CSR" (it will be under "Production"), on the page that appears and click "Continue" button.

  • Generate CSR first to get the Vendor certificate. In the following screen you will see instructions on how to generate CSR using Mac's Keychain utility. However, you can also generate CSR using openssl (see Section 11.2.2.1, "Creating SSL Certificate Signed by Private CA"):

    • openssl genrsa -out vendor.key 2048

    • openssl req -new -out vendor.csr -key vendor.key

    Ensure that you enter your name (CN) and your email address when prompted by openssl. If instead you choose using Keychain utility, you need to export your private key from it as PKCS12 bundle (ext .p12 or .pfx).

    On the portal, click "Continue" button.

  • Select your generated CSR file (on the next screen) to upload.

  • Download your MDM CSR Signing Certificate (that is generated) from the next screen.

  • See the row with your newly generated certificate (back at the "Certificates" table on the portal under "Production" ). You can re-download it from the portal later if you wish. The "Type" column should indicate "MDM CSR".

11.2.3.2 Create APNS CSR

To generate APNS private key and CSR you can use openssl, see Section 11.2.2.1, "Creating SSL Certificate Signed by Private CA":

  • openssl genrsa -out push.key 2048

  • openssl req -new -out push.csr -key push.key

You are asked for some information by "openssl req" command. Enter the information for your organization (enter at least your name (subject CN) and email address). Alternatively, you can generate private key and CSR by Apple Keychain Utility on Mac.

Save the CSR instead of discarding it because it can be reused when your APNS certificate needs to be renewed.

11.2.3.3 Sign CSR with MDM CSR Signing Certificate

If you do not want/cannot assume the Vendor role, submit the CSR you created to Oracle Support. Otherwise, follow the steps below. Although there is no official Apple tool for MDM CSR signing, Mobile Server provides an MDM CSR signing utility. The utility is located in file applemdm.jar. You can find applemdm.jar in your Mobile Server subdirectory:

MOBILE_HOME\mobile\server\admin\repository\mobile\lib.

To use the MDM CSR signing utility you must get the following:

  • Vendor's CSR Signing Certificate.

    It can be either in PEM format (text, base-64 encoding) with extension .pem or in binary DER format, with extensions .cer or .der. Refer to Section 11.2.3.1, "Obtain MDM CSR Signing Certificate"on how to obtain it.

  • Vendor's CSR Signing private key.

    The private key has to be in PKCS12 format in a file with extension .p12 or .pfx. If you exported the private key from the Mac Keychain utility, it must already be in PKCS12 format. On the other hand, if you used openssl to generate your vendor's private key and CSR as in Section 11.2.3.1, "Obtain MDM CSR Signing Certificate,", you can convert the key file generated by openssl to PKCS12 format:

    openssl pkcs12 -export -nocerts -inkey vendor.key -out vendor.p12

    -nocerts option tells openssl to generate vendor.p12 containing only private key and no certificates. You will be prompted for the password to protect .p12 file.

  • Customer's CSR

    See Section 11.2.3.2, "Create APNS CSR."

  • Apple Root Certificate

    Download it here: http://www.apple.com/appleca/AppleIncRootCertificate.cer

    The file name should be AppleIncRootCertificate.cer.

  • Apple WWDR Intermediate Certificate

    Download it here: http://developer.apple.com/certificationauthority/AppleWWDRCA.cer

    The file name should be AppleWWDRCA.cer.

    Run MDM CSR Signing utility as follows:

    java -cp applemdm.jar oracle.opensync.apple.tools.MDMCSRSign push.csr vendor.p12 vendor_pk_password vendor.pem AppleWWDRCA.cer AppleIncRootCertificate.cer > push.signedcsr

    where:

    • push.csr - Customer's APNS CSR

    • vendor.p12 (or vendor.pfx) - Vendor's CSR Signing private key as PKCS12 bundle.

    • vendor_pk_password - Password protecting vendor.p12 (or vendor.pfx).

    • vendor.pem (or vendor.cer) - Vendor's CSR Signing Certificate that was downloaded in section 11.2.3.1.

    • The last 2 parameters are Apple's WWDR intermediate and Apple's root certificates.

      Note:

      If their names match the names given above (AppleWWDRCA.cer and AppleIncRootCertificate.cer), these last 2 parameters can be omitted.

    • push.signedcsr - The result of running the utility, Customer's APNS signed CSR (the utility writes the result to standard output, thus the re-direction).

    Save the signed CSR instead of discarding it because it can be reused when your APNS certificate needs to be renewed.

11.2.3.4 Submit CSR and Obtain APNS Certificate

Follow the steps below:

  1. Go to Apple Push Certificate Portal.

  2. Sign in with your Apple ID.

  3. Click on "Create a Certificate" button.

  4. Read and accept terms and conditions.

  5. Select the signed CSR to upload (for example, push.signedcsr)

  6. Download APNS certificate (newly generated) from the following screen.

11.2.3.5 Import APNS Certificate and Private Key into Mobile Server MDM Keystore

The last step is to import APNS certificate into Mobile Server MDM keystore. See Section 11.2.1.2, "Importing the CA into Mobile Server MDM Keystore" for details on the MDM keystore.

You must combine your APNS private key and APNS certificate into PKCS12 bundle.

Note:

Mobile Server MDM keystore password is the same as your Mobile Server repository password.

Here are the commands:

cd %MOBILE_HOME%\Mobile\Server\admin\repository\devmgr\apple\mdm\cert

openssl pkcs12 -export -out push.p12 -in push.pem -inkey push.key

keytool -importkeystore -srckeystore push.p12 -srcstoretype pkcs12 -destkeystore keystore.jks -srcalias 1 -destalias oracle.dms.mdm.apns

where:

  • push.pem - APNS certificate you downloaded from the portal (see Section 11.2.3.4, "Submit CSR and Obtain APNS Certificate")

  • push.key - APNS private key (see Section 11.2.3.2, "Create APNS CSR")

  • push.p12 - bundle combining APNS certificate with APNS private key

  • oracle.dms.mdm.apns - destination alias in MDM keystore.

    Note:

    It is important that you enter destination alias exactly as specified above. Mobile Server uses this alias name to find the APNS Certificate entry.

After this is completed, restart your Mobile Server.

11.2.3.6 Renewing MDM Certificates

Both Vendor's CSR Signing Certificate and Customer's APNS Certificate have limited duration (currently 1 year), so they will need to be renewed. Follow the steps below for renewal:

11.2.3.7 Important Considerations

See the following section:

11.2.3.7.1 Push Notification Topic

Similar to push notifications sent by iOS Apps, MDM protocol must specify push notification topic. The push notification topic for MDM must start with prefix com.apple.mgmt. The topic is located in the APNS certificate's Subject UID field. You can check this with openssl:

openssl x509 -noout -text -in push.pem

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            20:b6:b9:9e:0b:6f:c2:09
    Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=US, O=Apple Inc., OU=Apple Certification Authority, CN=Apple A
pplication Integration Certification Authority
        Validity
            Not Before: Aug 16 07:33:54 2014 GMT
            Not After : Aug 16 07:33:54 2015 GMT
        Subject: UID=com.apple.mgmt.xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
0, CN=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx, C=US
        Subject Public Key Info:
..................................................................................

It is useful to check if you get any push notification related errors while running MDM in Mobile Server.