5 Migrating Your Application to MAF 2.6.0
This chapter includes the following sections:
-
Migrating Cordova Plugins from Earlier Releases to MAF 2.6.0
-
Configuring Application Features with AMX Content to Use WKWebView on iOS
-
Migrating MAF Applications that Use Customer URL Schemes to Invoke Other Applications
-
Retaining Legacy Behavior When Navigating a MAF Application Using Android’s Back Button
Migrating an Application to MAF 2.6.0
Customers who migrate to this release of MAF need to be aware of changes introduced in this release and earlier releases of MAF that may affect the applications you migrate.
This release of MAF requires Xcode 10.x to build and deploy your MAF applications to the iOS platform. Upgrade your installation of Xcode, as described in Using Xcode 10.x with MAF 2.6.0.
Also, beginning with Xcode 10.2 Apple has changed how Swift based applications are built. Command-line applications will no longer include the Swift runtime libraries. MAF uses a Swift based command line-application for iOS deployment. The macOS Mojave versions 14.4 and onward include the required Swift runtime libraries. Earlier versions of Mojave and all versions of High Sierra (13.x) require the manual download and installation of the Swift runtime libraries. These libraries are available in the Swift 5 Runtime Support for Command Line Tools
install package from https://developer.apple.com/download/more/.
For push notifications in MAF applications, MAF now uses Firebase Cloud Messaging (FCM) to replace Google Cloud Messaging (GCM), which has been deprecated by Google. To migrate to FCM, follow the instructions provided by Google at https://developers.google.com/cloud-messaging/android/android-migrate-fcm. After completing the migration, or creating a new FCM app, download the generated google-services.json
file to the root directory of your MAF application (parallel to the ViewController
and ApplicationController
directories), as demonstrated by the following example.
MAFappRootDirectory
MAFapp.jws
ApplicationController
ViewController
google-services.json
....
This completes the migration of your MAF application to use FCM. No API changes or other changes are necessary to upgrade your MAF application. For more information about using push notifications, see Enabling and Using Notifications in Developing Mobile Applications with Oracle Mobile Application Framework.
For information about new features introduced in this release, see What's New in This Guide for MAF Release 2.6.0 in Developing Mobile Applications with Oracle Mobile Application Framework.
Release | Description |
---|---|
MAF 2.5.1 |
|
MAF 2.5.0 |
|
MAF 2.4.2 | Used Visual Studio 2017, in addition to Visual Studio 2015, to set up the development environment that you use to deploy MAF applications to the Universal Windows Platform. Ensure that you have both versions 10.0.10586.0 and 10.0.14393 of the Windows 10 SDK installed in whichever version of Visual Studio you use. See Setting Up Development Tools for the Universal Windows Platform. |
MAF 2.4.1 |
Required Xcode 8.3.x to build and deploy MAF applications to the iOS platform and you must select an export method (Ad Hoc, App Store, Development, or Enterprise) from the Method dropdown list in the iOS platform page of the Preferences dialog, as described in Setting the Device Signing and Export Options of Developing Mobile Applications with Oracle Mobile Application Framework. Note also that you can maintain two separate installations of Xcode, as described in Using Xcode 10.x with MAF 2.6.0, if you want to maintain two separate development environments for different versions of MAF. |
MAF 2.4.0 |
|
MAF 2.3.3 and later |
Required Xcode 8 to develop and deploy MAF applications to the iOS platform. It also supports deployment of applications to devices running on the iOS 10 platform. See Using Xcode 10.x with MAF 2.6.0. |
MAF 2.3.2 and later |
|
MAF 2.3.1 and later |
Included the client data model feature that provides offline read and write support for REST services. If you previously used the A-Team Mobile Persistence Accelerator (AMPA) extension to develop an application with these capabilities, you can migrate it to this release of MAF, as described in Migrating an Application Developed Using AMPA to MAF 2.6.0. |
MAF 2.3.0 and later |
|
MAF 2.2.1 |
Enabled App Transport Security (ATS) by default for applications that you migrate to this release. See Security Changes in Release 2.2.1 and Later of MAF. If your migrated application uses URL schemes to invoke other applications, configure the migrated application as described in Migrating MAF Applications that Use Customer URL Schemes to Invoke Other Applications. |
MAF 2.1.0 |
|
Using Xcode 10.x with MAF 2.6.0
MAF 2.6.0 requires Xcode 10.x to develop and deploy MAF applications to the iOS platform.
Migrating Cordova Plugins from Earlier Releases to MAF 2.6.0
MAF 2.5.1 and later use new versions of Cordova. See the Cordova Engine Version section in the overview editor for the maf-application.xml
file for the version that each targeted platform uses.
To complete the migration and make sure that your migrated MAF application can continue to use any non-core plugins it used previously, verify that this release of MAF supports the version of the plugin(s) that your MAF application uses. The Cordova Engine Versions displays the versions that your release of MAF uses, as illustrated in Figure 5-1. Obtain a newer version of the plugin if the plugin was created using an earlier release of Cordova than that used by the current release of MAF. Set the relative path to the plugin so that the maf-plugins.xml
file of the MAF application correctly references the plugin. See Registering Additional Plugins in Your MAF Application in Developing Mobile Applications with Oracle Mobile Application Framework. If the maf-plugins.xml
file does not correctly reference a plugin using a relative path, the overview editor for the maf-application.xml
file's Path* field which requires a value is empty and the maf-plugins.xml
displays a validation failure, as shown in Figure 5-1.
MAF applications developed using earlier releases of MAF (prior to MAF 2.1.0) registered plugins in the maf-application
file. Release MAF 2.1.0 and later registers plugins in the maf-plugins.xml
file. JDeveloper makes the following changes to an application from an earlier release that uses plugins when you migrate the application:
-
Comments out entries in the
maf-application.xml
file that referenced plugins. For example, JDeveloper comments out entries such as the following:<!--<adfmf:cordovaPlugins> <adfmf:plugin fullyQualifiedName="BarcodeScanner" implementationClass="com.phonegap.plugins. barcodescanner.BarcodeScanner" platform="Android" name="BarcodeScanner"> ..... </adfmf:cordovaPlugins>-->
-
Registers the plugin in the
maf-plugins.xml
file, as shown in the following example:<cordova-plugins> ... <cordova-plugin id="c3" pluginId="org.apache.cordova.barcodeScanner"> <platform id="p3" name="ios" enabled="true"/> <platform id="p4" name="android" enabled="false"/> </cordova-plugin> </cordova-plugins>
Figure 5-1 MAF Application that Does Not Specify Path to Plugin
Description of "Figure 5-1 MAF Application that Does Not Specify Path to Plugin"
Evaluating EL Expressions in the Java VM Layer
Prior to MAF 2.5.0, MAF handled AMX file, EL and AMX node creation in the Web View layer of the MAF application. With MAF 2.5.0 and later, MAF performs these tasks in the Java VM layer of new MAF applications that you create.
MAF applications that you migrate to this release also perform these tasks in the Java VM Layer. Note the following as you review MAF applications that you migrate to this release:
-
A number of MAF JS APIs have been deprecated. For information about the up-to-date JS APIs that MAF supports, see JSDoc Reference for Oracle Mobile Application Framework.
-
MAF applications that include custom components must now include a
/META-INF/amx-tag-libraries.xml
file with the metadata for the XML namespace you use to identify the custom components you support and their attributes. See Creating Custom UI Components in Developing Mobile Applications with Oracle Mobile Application Framework. -
As EL creation and evaluation has moved to the Java VM layer, EL expressions should not be evaluated in JavaScript and must not be used from component type handlers.
You can configure new and migrated MAF applications to use the legacy behavior where MAF evaluated EL expressions in the Web View Layer, as described in the following section.
How to Move EL Evaluation to the Web View Layer
You move EL evaluation to the Web View layer by setting the value of the <amxTagHandling>
property in the maf-config.xml
file to legacy
.
To move EL evaluation to the Web View layer:
-
In the Applications window, expand the Application Resources panel.
-
In the Application Resources panel, expand Descriptors and then ADF META-INF.
-
Double-click the
maf-config.xml
file and in the source editor that appears, add the following entry:<adfmf-config xmlns="http://xmlns.oracle.com/adf/mf/config"> ... <!-- Use the Java VM layer to handle AMX tags and node hierarchies --> <amxTagHandling>legacy</amxTagHandling> </adfmf-config>
Other valid values that you can add to the
maf-config.xml
file to handle EL evaluation includewebview
orlegacy
. These force the use of the Web View layer to handle AMX tags and node hierarchies. A value ofdefault
or no entry for theamxTagHandling
property means the Web View layer handles AMX tags and node hierarchies.Remove the
<amxTagHandling>legacy</amxTagHandling>
entry or set it to<amxTagHandling>default</amxTagHandling>
if you want the MAF application to use the default behavior of evaluating EL expressions in the Java VM layer.
Configuring Application Features with AMX Content to Use WKWebView on iOS
New MAF applications that you create using the MAF 2.3.2 release and later of MAF use WKWebView by default to render AMX content type when you deploy the MAF application to an iOS device. You can opt to use this web view in MAF applications that you migrate to this release of MAF.
The newer WKWebView offers improved performance compared to UIWebView.
The following example illustrates how you configure an application feature with AMX content in a migrated MAF application to use the newer WKWebView. To revert to using UIWebView, set the value
attribute to legacy
. You configure these properties in the maf-features.xml
file for each application feature with AMX content that you want to use WKWebView.
<adfmf:feature id="WKWebViewExample" name="WKWebViewExample">
<adfmf:constraints>
<adfmf:constraint property="device.os" operator="contains" value="iOS" id="c6"/>
</adfmf:constraints>
<adfmf:content id="WKWebViewExample.1">
<adfmf:amx file="WKWebViewExample/home.amx"/>
</adfmf:content>
<adfmf:properties id="wkp1">
<adfmf:property id="wkp1-1" name="iOSWebView" value="modern" />
<!-- To revert to using UIWebView, set to legacy -->
<!-- name="iOSWebView" value="legacy" -->
</adfmf:properties>
</adfmf:feature>
Application features that use local HTML or remote URL content types continue to use the UIWebView as this web view supports the /~maf.device~/
virtual path to access JavaScript APIs.
When the iOSWebView
property is missing or is set to default
then WKWebView is used for AMX content and UIWebView is used for local HTML and remote URL content types. You can specifically opt-in to using WKWebView for the local HTML and remote URL content types by setting the value to modern
if you do not need the /~maf.device~/
virtual path.
WKWebView is used on iOS 9+ only. UIWebView will always be used on iOS 8.
Security Changes in Release 2.4.0 and Later of MAF
Starting with MAF 2.4.0, MAF defaults the HTTPS protocol to TLSv1.2
on MAF applications that you deploy to the Android platform.
On supported platforms, you can override this behavior by specifying an alternative value as a Java command-line argument in the maf.properties
file, as shown by the following example that configures the Java VM layer of your application to use TLSv1.1
.
// Configure Java VM layer of the MAF app to use TLSv1.1 java.commandline.argument=-Dhttps.protocols=TLSv1.1 // Configure the HTTPS cipher suite(s) that an application uses by // providing a comma-separated list as a value java.commandline.argument=-Dhttps.cipherSuites=TLS_RSA_WITH_AES_256_CBC_SHA
Android’s authentication mechanism honors the properties in the maf.properties
file if the Android version supports the legacy protocols. Devices running Android 7+, for example, do not support TLSv1
and disable RC4-based cipher suites.
On the iOS and Universal Windows Platform, specifying these properties in the maf.properties
file does not change the authentication mechanism of the application. This is managed by the platform itself. However, application code, such as REST calls, may be affected by these properties.
We recommend that you retain the default MAF behavior in your application. Otherwise you may introduce security risks to your application. Overriding the default behavior is described here to assist you if you need to test your application with servers that use older versions of SSL or deprecated cipher suites.
Security Changes in Release 2.2.1 and Later of MAF
Migrating an application from MAF 2.2.0 or earlier to MAF 2.3.0 and later requires you to make some configuration changes to your migrated application so that it adheres to the latest security standards supported by this release of MAF.
Starting with MAF 2.2.1, use of HTTPS with TLS 1.2 for all connections to the server from MAF applications on iOS is required. Any MAF application that uses non-HTTPS connections and an SSL version lower than TLS1.2 will fail to run on iOS. MAF enforces this behavior to meet the Apple iOS requirement to use App Transport Security (ATS) that requires use of HTTPS with TLS 1.2. You can disable use of ATS, as described below.
MAF applications also adhere to the default behavior enforced by the JVM of Java 8 to use the latest SSL version and cipher suites. While we encourage you to upgrade your servers to use these later versions, you can configure your MAF application to work around SSL errors you may encounter by using servers with older SSL versions, as described below.
Disabling App Transport Security for MAF Applications on iOS Devices
MAF applications that you migrate to this release of MAF enable ATS by default. You can disable ATS in your MAF application as follows:
-
In JDeveloper, choose Application > Application Properties > Deployment.
-
In the Deployment page, double-click the iOS deployment profile.
-
Select iOS Options.
-
Select Disable Application Transport Security and click OK.
Note:
We recommend that you do not disable ATS. Apple plans to enforce use of ATS from January 01, 2017. MAF applications that disable ATS will not be approved for publication by the Apple App Store.
SSL Configuration Changes
Customers who use SSL versions lower than TLS 1.2, deprecated cipher suites or deprecated encryption algorithms will see SSL errors like "invalid cipher suite
", "close notify
", "TLS error
", and so on. Java 8 enforces use of the latest SSL version and cipher suites. It disables use of insecure SSL versions by default. We encourage you to update your servers to use the later SSL version. If this is not possible, you can use the following configuration to work around the SSL errors just described:
-
Update
maf.properties
file with the version of SSL that you want to use. For example, add the following entry to themaf.properties
file to use TLS 1:java.commandline.argument=-Dhttps.protocols=TLSv1
-
Update
maf.properties
file with the full list of cipher suites required by the application. For the list of cipher suites that Java supports, see the Cipher Suites section on this page.For example, to enable
SSL_RSA_WITH_RC4_128_MD5
, add the following:java.commandline.argument=-D SSL_RSA_WITH_RC4_128_MD5
-
Update the
java.security
file to enable deprecated algorithms. Existing MAF applications will not have this file so create a new empty MAF application and copy thejava.security
file created in the new MAF application’s/resources/security
to the same directory in the existing application.For example, the RC4 algorithm is disabled by default per the following entry in the
java.security
file:jdk.tls.disabledAlgorithms=SSLv3, RC4, DH keySize < 768
If you use a cipher suite that requires the RC4 algorithm, such as
SSL_RSA_WITH_RC4_128_MD5
, an error is thrown at runtime while establishing the SSL connection. To work around this, change thejava.security
entry as follows to enable the RC4 algorithm:jdk.tls.disabledAlgorithms=SSLv3, DH keySize < 768
Migrating an Application Developed Using AMPA to MAF 2.6.0
Describes how to migrate an application developed using the A-Team Mobile Persistence Accelerator (AMPA) extension and an earlier release of MAF to this release of MAF.
MAF 2.3.1 and later incorporates AMPA, a persistence and data synchronization framework, as part of the client data model feature in MAF. Application developers can develop new MAF applications using the design-time and runtime features of the MAF client data model to generate the data model of their application, decide what data objects to persist on end user’s devices, plus generate a complete user interface from data controls created from the service objects in the generated client data model. See Creating the Client Data Model in a MAF Application in Developing Mobile Applications with Oracle Mobile Application Framework.
You can migrate applications developed using the AMPA extension and earlier releases of MAF to this release of MAF by performing the following tasks:
-
Change the namespace in the
persistence-mapping.xml
file -
Modify the lifecycle listener in the
maf-application.xml
file -
Change the package names of AMPA classes to use the MAF client data model package names
Change the Namespace in the persistence-mapping.xml File
Change the namespace in the persistence-mapping.xml
file to use the MAF client data model value, as shown in the following example:
<mobileObjectPersistence xmlns="http://xmlns.oracle.com/adf/mf/amx/cdm/persistenceMapping" ...
The persistence-mapping.xml
file is in the following directory of the ApplicationController project in your migrated application:
/ApplicationController/src/META-INF
Modify the Lifecycle Listener in the maf-application.xml File
Change the value of the listener-class
attribute in the maf-application.xml
file from oracle.ateam.sample.mobile.lifecycle.InitDBLifeCycleListener
to the MAF client data model value, as shown in the following example:
<adfmf:application xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:adfmf="http://xmlns.oracle.com/adf/mf" ... listener-class="oracle.maf.impl.cdm.lifecycle.InitDBLifeCycleListener">
The maf-application.xml
file is in the following directory of your migrated application:
./.adf/META-INF/maf-application.xml
Change AMPA Package Name to MAF Client Data Model Package Names
Revise the package names of Java classes in your migrated application to the package names used by MAF client data model. The mapping between AMPA packages and the MAF client data model packages is as follows:
oracle.ateam.sample.mobile -----> oracle.maf.impl.cdm oracle.ateam.sample.mobile.v2.security -----> oracle.maf.impl.cdm.security oracle.ateam.sample.mobile.v2.persistence -----> oracle.maf.impl.cdm.persistence
If, for example, the AMPA application that you migrate to this release of MAF contains a Java class that imports oracle.ateam.sample.mobile.mcs.analytics.AnalyticsEvent
, modify the Java class in your migrated application to import oracle.maf.impl.cdm.mcs.analytics.AnalyticsEvent
.
Note:
Classes in theoracle.maf.impl.cdm
package are internal classes of the MAF client data model and subject to change. MAF may refactor some of these classes in later releases but, for now, we recommend that you do not extend these classes.
All the classes in the oracle.maf.api.cdm...
packages are publicly available classes that you can extend. If, for example, the AMPA application that you migrate to this release of MAF contains a Java class that imports oracle.ateam.sample.mobile.mcs.storage.StorageObject
, modify it so that it imports oracle.maf.api.cdm.mcs.storage.StorageObject
.
The following list identifies the publicly available classes in the oracle.maf.api.cdm
package:
controller.bean.ConnectivityBean exception.RestCallException mcs.storage.StorageObject mcs.storage.StorageObjectService persistence.cache.EntityCache persistence.db.BindParamInfo persistence.manager.DBPersistenceManager persistence.manager.MCSPersistenceManager persistence.manager.RestJSONPersistenceManager persistence.manager.RestXMLPersistenceManager persistence.metadata.AttributeMapping persistence.metadata.AttributeMappingDirect persistence.metadata.AttributeMappingOneToMany persistence.metadata.AttributeMappingOneToOne persistence.metadata.ClassMappingDescriptor persistence.model.Entity persistence.service.DataSynchAction persistence.service.DataSynchService persistence.service.ValueHolderInterface persistence.util.EntityUtils
See the Java reference documentation for the AMPA framework to identify the package name in AMPA for the list of publicly available classes above and revise to use the package name in the MAF client data model. For information about publicly available classes in MAF, see Java API Reference for Oracle Mobile Application Framework.
Also refer to the above reference documentation for other changes implemented in the MAF client data model since it incorporated AMPA. For example, if you extended DBPersistenceManager
in an application developed using AMPA and the extended class referenced constants, such as SQL_SELECT_KEYWORD
, you need to supply your own constants in the extended class as the MAF client data model’s implementation of DBPersistenceManager
no longer provides these constants.
Make the above changes for all Java classes in your migrated application and in pageDefinition.xml
files that reference Java managed beans using the AMPA package names.
Apart from the above changes, make sure that the application you migrate uses supported classes and methods. For example, AMPA deprecated oracle.ateam.sample.mobile.util.MCSManager
in a recent release. Any application migrated to this release of MAF which uses the AMPA-deprecated MCSManager
should be revised to use oracle.maf.api.cdm.persistence.manager.MCSPersistenceManager
.
Migrating MAF Applications that Use Customer URL Schemes to Invoke Other Applications
If the application you migrate to MAF 2.2.2 or later uses a custom URL scheme to invoke another application, add the scheme(s) to the Allowed Scheme list in the Security page of the maf-application.xml
file’s overview editor.
This change addresses the iOS 9 requirement that applications declare any URL schemes they use to invoke other applications. Click the Add icon in the Allow Schemes section of the Security page to add the custom URL scheme.
Figure 5-2 Registering a Custom URL Scheme that a MAF Applications Use to Invoke Another Application
Description of "Figure 5-2 Registering a Custom URL Scheme that a MAF Applications Use to Invoke Another Application"
Migrating to JDK 8 in MAF 2.6.0
MAF applications that you create in MAF 2.1.0 and later use JDK 8. If you migrate a MAF application that compiled with an earlier version of Java, note that MAF 2.1.0 and later requires JDK 8 and compiles applications using the Java SE Embedded 8 compact2 profile.
When you open an application that you migrated from a pre-MAF 2.1.0 release for the first time, JDeveloper makes the following changes:
-
Renames the configuration file that specifies the startup parameters of the JVM from
cvm.properties
tomaf.properties
. For information about themaf.properties
file, see How to Enable Debugging of Java Code and JavaScript in Developing Mobile Applications with Oracle Mobile Application Framework. -
Replaces instances (if any) of the following import statement in the Java source files of the application:
com.sun.util.logging
With:
java.util.logging
-
Replaces the following entries in the
logging.properties
file of the application.handlers=com.sun.util.logging.ConsoleHandler .formatter=com.sun.util.logging.SimpleFormatter
With:
.handlers=java.util.logging.ConsoleHandler .formatter=java.util.logging.SimpleFormatter
For information about the
logging.properties
file, see How to Configure Logging Using the Properties File in Developing Mobile Applications with Oracle Mobile Application Framework.
Retaining Legacy Behavior When Navigating a MAF Application Using Android’s Back Button
MAF 2.2.0 introduced a change in the way that MAF applications created using that release respond to usage of the Android system’s Back button. A MAF application that you created in a previous release and migrate to MAF 2.2.0 or later uses the new behavior.
The figure shows a navigation flow on a MAF application where an end user has navigated between three application features (Customer, Sales, and Billing) to the Billing Page 3 page of the Billing application feature.
Figure 5-3 Navigation Flow Between Application Features and Pages in a MAF Application
Description of "Figure 5-3 Navigation Flow Between Application Features and Pages in a MAF Application"
Prior to Release MAF 2.2.0, the default MAF application behavior in response to an end user tapping Android’s system Back button on:
-
Billing Page 3 was to navigate to the Sales application feature
-
Sales application feature was to navigate to the Customers application feature
-
Customer application feature was to close the MAF application
In MAF 2.2.0 and later, the default MAF application behavior in response to an end user tapping Android’s system Back button on:
-
Billing Page 3 is to navigate to Billing Page 2
-
Billing Page 2 is to navigate to Billing Page 1
-
Billing Page 1 is to hibernate the MAF application
You can customize how your MAF application responds to an end user´s tap of the Android system´s Back button, as described in Navigating a MAF Application Using Android’s Back Button of Developing Mobile Applications with Oracle Mobile Application Framework.
You can also configure your MAF application to exhibit the pre-MAF 2.2.0 application behavior (navigate between application features) by setting a property in the maf-config.xml
, as described in How to Retain Pre-MAF 2.2.0 Application Behavior in Response to Usage of Android´s Back Button.
How to Retain Pre-MAF 2.2.0 Application Behavior in Response to Usage of Android´s Back Button
You configure the legacyBack
element in the maf-config.xml
file to make your MAF application exhibit pre-MAF 2.2.0 behavior when an end user taps Android´s Back button.
Example 5-1 legacyBack element to Retain Pre-MAF 2.2.0 Application Behavior for Usage of Android Back Button
<?xml version="1.0" encoding="UTF-8" ?> <adfmf-config xmlns="http://xmlns.oracle.com/adf/mf/config"> ... <legacyBack>true</legacyBack> </adfmf-config>
Migrating to New cacerts File for SSL in MAF 2.6.0
MAF 2.1.0 delivered a new cacerts
file for use in MAF applications. Make sure that the cacerts
file packaged in the application that you publish for end users to install contains the same CA root certificates as the HTTPS server that end users connect to when they use your MAF application.
You may need to import new certificates to the cacerts
file of your MAF application if the HTTPS server contains certificates not present in the cacerts
file of your MAF application. Similarly, system administrators for the HTTPS servers that your MAF application connects to may need to import new certificates if your MAF application uses a certificate not present on the HTTPS server.
Use the keytool
utility of JDK 8 to view and manage the certificates in the cacerts
file of your MAF application . The following example demonstrates how you might use the keytool
utility of JDK 8 to display the list of certificates in a cacerts
file:
JDK8install
/bin/keytool -list -v -keystore
dirPathToCacertsFile
/cacerts –storepass storepass | grep "Issuer:"
For information about using the keytool
utility of JDK 8 to manage certificates, see http://docs.oracle.com/javase/8/docs/technotes/tools/#security
. For example, to use the keytool
utility on Windows, see http://docs.oracle.com/javase/8/docs/technotes/tools/windows/keytool.html
. For UNIX-based operating systems, see http://docs.oracle.com/javase/8/docs/technotes/tools/unix/keytool.html
.
For information about the cacerts
file and using SSL to secure your MAF application, see Supporting SSL in Developing Mobile Applications with Oracle Mobile Application Framework.
Example 5-2 lists the issuers of CA root certificates included in the MAF 2.1.0 cacerts
file. Use the keytool
utility of JDK 8, as previously described, to manage the certificates in this file to meet the requirements of the environment where your MAF application will be used.
Example 5-2 CA Root Certificate Issuers in MAF 2.1.0 cacerts File
Issuer: CN=DigiCert Assured ID Root CA, OU=www.digicert.com, O=DigiCert Inc, C=US Issuer: CN=TC TrustCenter Class 2 CA II, OU=TC TrustCenter Class 2 CA, O=TC TrustCenter GmbH, C=DE Issuer: EMAILADDRESS=premium-server@thawte.com, CN=Thawte Premium Server CA, OU=Certification Services Division, O=Thawte Consulting cc, L=Cape Town, ST=Western Cape, C=ZA Issuer: CN=SwissSign Platinum CA - G2, O=SwissSign AG, C=CH Issuer: CN=SwissSign Silver CA - G2, O=SwissSign AG, C=CH Issuer: EMAILADDRESS=server-certs@thawte.com, CN=Thawte Server CA, OU=Certification Services Division, O=Thawte Consulting cc, L=Cape Town, ST=Western Cape, C=ZA Issuer: CN=Equifax Secure eBusiness CA-1, O=Equifax Secure Inc., C=US Issuer: CN=SecureTrust CA, O=SecureTrust Corporation, C=US Issuer: CN=UTN-USERFirst-Client Authentication and Email, OU=http://www.usertrust.com, O=The USERTRUST Network, L=Salt Lake City, ST=UT, C=US Issuer: EMAILADDRESS=personal-freemail@thawte.com, CN=Thawte Personal Freemail CA, OU=Certification Services Division, O=Thawte Consulting, L=Cape Town, ST=Western Cape, C=ZA Issuer: CN=AffirmTrust Networking, O=AffirmTrust, C=US Issuer: CN=Entrust Root Certification Authority, OU="(c) 2006 Entrust, Inc.", OU=www.entrust.net/CPS is incorporated by reference, O="Entrust, Inc.", C=US Issuer: CN=UTN-USERFirst-Hardware, OU=http://www.usertrust.com, O=The USERTRUST Network, L=Salt Lake City, ST=UT, C=US Issuer: CN=Certum CA, O=Unizeto Sp. z o.o., C=PL Issuer: CN=AddTrust Class 1 CA Root, OU=AddTrust TTP Network, O=AddTrust AB, C=SE Issuer: CN=Entrust Root Certification Authority - G2, OU="(c) 2009 Entrust, Inc. - for authorized use only", OU=See www.entrust.net/legal-terms, O="Entrust, Inc.", C=US Issuer: OU=Equifax Secure Certificate Authority, O=Equifax, C=US Issuer: CN=QuoVadis Root CA 3, O=QuoVadis Limited, C=BM Issuer: CN=QuoVadis Root CA 2, O=QuoVadis Limited, C=BM Issuer: CN=DigiCert High Assurance EV Root CA, OU=www.digicert.com, O=DigiCert Inc, C=US Issuer: EMAILADDRESS=info@valicert.com, CN=http://www.valicert.com/, OU=ValiCert Class 1 Policy Validation Authority, O="ValiCert, Inc.", L=ValiCert Validation Network Issuer: CN=Equifax Secure Global eBusiness CA-1, O=Equifax Secure Inc., C=US Issuer: CN=GeoTrust Universal CA, O=GeoTrust Inc., C=US Issuer: OU=Class 3 Public Primary Certification Authority, O="VeriSign, Inc.", C=US Issuer: CN=thawte Primary Root CA - G3, OU="(c) 2008 thawte, Inc. - For authorized use only", OU=Certification Services Division, O="thawte, Inc.", C=US Issuer: CN=thawte Primary Root CA - G2, OU="(c) 2007 thawte, Inc. - For authorized use only", O="thawte, Inc.", C=US Issuer: CN=Deutsche Telekom Root CA 2, OU=T-TeleSec Trust Center, O=Deutsche Telekom AG, C=DE Issuer: CN=Buypass Class 3 Root CA, O=Buypass AS-983163327, C=NO Issuer: CN=UTN-USERFirst-Object, OU=http://www.usertrust.com, O=The USERTRUST Network, L=Salt Lake City, ST=UT, C=US Issuer: CN=GeoTrust Primary Certification Authority, O=GeoTrust Inc., C=US Issuer: CN=Buypass Class 2 Root CA, O=Buypass AS-983163327, C=NO Issuer: CN=Baltimore CyberTrust Code Signing Root, OU=CyberTrust, O=Baltimore, C=IE Issuer: OU=Class 1 Public Primary Certification Authority, O="VeriSign, Inc.", C=US Issuer: CN=Baltimore CyberTrust Root, OU=CyberTrust, O=Baltimore, C=IE Issuer: OU=Starfield Class 2 Certification Authority, O="Starfield Technologies, Inc.", C=US Issuer: CN=Chambers of Commerce Root, OU=http://www.chambersign.org, O=AC Camerfirma SA CIF A82743287, C=EU Issuer: CN=T-TeleSec GlobalRoot Class 3, OU=T-Systems Trust Center, O=T-Systems Enterprise Services GmbH, C=DE Issuer: CN=VeriSign Class 3 Public Primary Certification Authority - G5, OU="(c) 2006 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US Issuer: CN=T-TeleSec GlobalRoot Class 2, OU=T-Systems Trust Center, O=T-Systems Enterprise Services GmbH, C=DE Issuer: CN=TC TrustCenter Universal CA I, OU=TC TrustCenter Universal CA, O=TC TrustCenter GmbH, C=DE Issuer: CN=VeriSign Class 3 Public Primary Certification Authority - G4, OU="(c) 2007 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US Issuer: CN=VeriSign Class 3 Public Primary Certification Authority - G3, OU="(c) 1999 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US Issuer: CN=XRamp Global Certification Authority, O=XRamp Security Services Inc, OU=www.xrampsecurity.com, C=US Issuer: CN=Class 3P Primary CA, O=Certplus, C=FR Issuer: CN=Certum Trusted Network CA, OU=Certum Certification Authority, O=Unizeto Technologies S.A., C=PL Issuer: OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For authorized use only", OU=Class 3 Public Primary Certification Authority - G2, O="VeriSign, Inc.", C=US Issuer: CN=GlobalSign, O=GlobalSign, OU=GlobalSign Root CA - R3 Issuer: CN=UTN - DATACorp SGC, OU=http://www.usertrust.com, O=The USERTRUST Network, L=Salt Lake City, ST=UT, C=US Issuer: OU=Security Communication RootCA2, O="SECOM Trust Systems CO.,LTD.", C=JP Issuer: CN=GTE CyberTrust Global Root, OU="GTE CyberTrust Solutions, Inc.", O=GTE Corporation, C=US Issuer: OU=Security Communication RootCA1, O=SECOM Trust.net, C=JP Issuer: CN=AffirmTrust Commercial, O=AffirmTrust, C=US Issuer: CN=TC TrustCenter Class 4 CA II, OU=TC TrustCenter Class 4 CA, O=TC TrustCenter GmbH, C=DE Issuer: CN=VeriSign Universal Root Certification Authority, OU="(c) 2008 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US Issuer: CN=GlobalSign, O=GlobalSign, OU=GlobalSign Root CA - R2 Issuer: CN=Class 2 Primary CA, O=Certplus, C=FR Issuer: CN=DigiCert Global Root CA, OU=www.digicert.com, O=DigiCert Inc, C=US Issuer: CN=GlobalSign Root CA, OU=Root CA, O=GlobalSign nv-sa, C=BE Issuer: CN=thawte Primary Root CA, OU="(c) 2006 thawte, Inc. - For authorized use only", OU=Certification Services Division, O="thawte, Inc.", C=US Issuer: CN=Starfield Root Certificate Authority - G2, O="Starfield Technologies, Inc.", L=Scottsdale, ST=Arizona, C=US Issuer: CN=GeoTrust Global CA, O=GeoTrust Inc., C=US Issuer: CN=Sonera Class2 CA, O=Sonera, C=FI Issuer: CN=Thawte Timestamping CA, OU=Thawte Certification, O=Thawte, L=Durbanville, ST=Western Cape, C=ZA Issuer: CN=Sonera Class1 CA, O=Sonera, C=FI Issuer: CN=QuoVadis Root Certification Authority, OU=Root Certification Authority, O=QuoVadis Limited, C=BM Issuer: CN=AffirmTrust Premium ECC, O=AffirmTrust, C=US Issuer: CN=Starfield Services Root Certificate Authority - G2, O="Starfield Technologies, Inc.", L=Scottsdale, ST=Arizona, C=US Issuer: EMAILADDRESS=info@valicert.com, CN=http://www.valicert.com/, OU=ValiCert Class 2 Policy Validation Authority, O="ValiCert, Inc.", L=ValiCert Validation Network Issuer: CN=AAA Certificate Services, O=Comodo CA Limited, L=Salford, ST=Greater Manchester, C=GB Issuer: CN=America Online Root Certification Authority 2, O=America Online Inc., C=US Issuer: CN=AddTrust Qualified CA Root, OU=AddTrust TTP Network, O=AddTrust AB, C=SE Issuer: CN=KEYNECTIS ROOT CA, OU=ROOT, O=KEYNECTIS, C=FR Issuer: CN=America Online Root Certification Authority 1, O=America Online Inc., C=US Issuer: CN=VeriSign Class 2 Public Primary Certification Authority - G3, OU="(c) 1999 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US Issuer: CN=AddTrust External CA Root, OU=AddTrust External TTP Network, O=AddTrust AB, C=SE Issuer: OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For authorized use only", OU=Class 2 Public Primary Certification Authority - G2, O="VeriSign, Inc.", C=US Issuer: CN=GeoTrust Primary Certification Authority - G3, OU=(c) 2008 GeoTrust Inc. - For authorized use only, O=GeoTrust Inc., C=US Issuer: CN=GeoTrust Primary Certification Authority - G2, OU=(c) 2007 GeoTrust Inc. - For authorized use only, O=GeoTrust Inc., C=US Issuer: CN=SwissSign Gold CA - G2, O=SwissSign AG, C=CH Issuer: CN=Entrust.net Certification Authority (2048), OU=(c) 1999 Entrust.net Limited, OU=www.entrust.net/CPS_2048 incorp. by ref. (limits liab.), O=Entrust.net Issuer: OU=ePKI Root Certification Authority, O="Chunghwa Telecom Co., Ltd.", C=TW Issuer: CN=Global Chambersign Root - 2008, O=AC Camerfirma S.A., SERIALNUMBER=A82743287, L=Madrid (see current address at www.camerfirma.com/address), C=EU Issuer: CN=Chambers of Commerce Root - 2008, O=AC Camerfirma S.A., SERIALNUMBER=A82743287, L=Madrid (see current address at www.camerfirma.com/address), C=EU Issuer: OU=Go Daddy Class 2 Certification Authority, O="The Go Daddy Group, Inc.", C=US Issuer: CN=AffirmTrust Premium, O=AffirmTrust, C=US Issuer: CN=VeriSign Class 1 Public Primary Certification Authority - G3, OU="(c) 1999 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US Issuer: OU=Security Communication EV RootCA1, O="SECOM Trust Systems CO.,LTD.", C=JP Issuer: OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For authorized use only", OU=Class 1 Public Primary Certification Authority - G2, O="VeriSign, Inc.", C=US Issuer: CN=Go Daddy Root Certificate Authority - G2, O="GoDaddy.com, Inc.", L=Scottsdale, ST=Arizona, C=US