3 Migrating Your Application to MAF 2.3.0

This chapter provides information about migrating applications created using earlier releases of MAF to MAF 2.3.0.

This chapter includes the following sections:

3.1 Migrating an Application to MAF 2.3.0

Customers who migrate their MAF applications to MAF 2.3.0 need to be aware of the following changes in this release that may affect their migrated application:

  • MAF 2.3.0 uses newer versions of Cordova (4.x). If your migrated MAF application uses a third-party Cordova plugin, verify that it is compatible with the Android and iOS versions of Cordova that MAF 2.3.0 uses. For more information, see Section 3.2, "Migrating Cordova Plugins from Earlier Releases to MAF 2.3.0."

  • The RestServiceAdapter interface has a new package location (oracle.maf.api.dc.ws.rest). The functionality that this interface specifies remains unchanged. For more information about creating a REST web service adapter, see the "Creating a Rest Service Adapter to Access Web Services" section in Developing Mobile Applications with Oracle Mobile Application Framework (OEPE Edition).

  • This release removes support for the following features that were deprecated in earlier releases:

    • Mobile-Social authentication server type. Customers are recommended to use another authentication type, such as OAuth, that MAF supports.

    • SOAP web services. Customers are recommended to use REST web services with JSON objects. For more information, see the "Using Web Services in a MAF Application" section in Developing Mobile Applications with Oracle Mobile Application Framework (OEPE Edition).

MAF enables App Transport Security (ATS) by default for applications that you migrate to this release. For more information, see Section 3.3, "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 Section 3.5, "Migrating MAF Applications that Use Customer URL Schemes to Invoke Other Applications."

The MAF 2.1.0 release introduced significant changes that are also described in this chapter. Use the information in this chapter if you migrate an application created in a pre-MAF 2.1.0 release to MAF 2.3.0. If you migrate an application to MAF 2.3.0 that was created in MAF 2.1.0 or previously migrated to MAF 2.1.0, MAF will have made already made the changes required by migration to JDK 8, management of Cordova plugins, and a new cacerts file.

For MAF applications that you migrate to MAF 2.3.0 (irrespective of the release from which you migrate), we recommend that you set the preemptive property to true on the following security policies:

  • http_basic_auth_over_ssl_client_policy

  • wss_http_token_client_policy

  • wss_http_token_over_ssl_client_policy

Setting the preemptive property to true on these policies inserts a basic authentication header into the first request to a secured REST web service.

Also, if your MAF application uses Web SSO authentication, you must configure the oracle/http_cookie_client_policy security policy for all REST/HTTP web service connections used by the application. Without this change, your end users may see errors when accessing services in the application.

For more information, see the "Specifying REST Service Connections" section in Developing Mobile Applications with Oracle Mobile Application Framework (OEPE Edition).

MAF 2.1.0 used newer versions of Apache Cordova and Java. It also changed the way that OEPE registered plugins in your MAF application. For SSL, it delivers a cacerts file that contains new CA root certificates.

Read the subsequent sections in this chapter that describe how these changes impact the migration of your MAF application to MAF 2.1.0 or later.

Finally, MAF 2.1.0 delivered an updated SQLite database and JDBC driver. Review, and migrate as necessary, any code in your migrated MAF application that connects to the SQLite database. For more information about how to connect to the SQLite database, see the "Using the Local SQLite Database" section in Developing Mobile Applications with Oracle Mobile Application Framework (OEPE Edition).

3.2 Migrating Cordova Plugins from Earlier Releases to MAF 2.3.0

MAF 2.3.0 uses new versions of Cordova (4.x). To complete the migration and make sure that your migrated MAF application can use the plugins it used previously, verify that MAF supports the version of the plugin. The External Plug-Ins section displays the versions that your release of MAF uses, as illustrated in Figure 3-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.

Figure 3-1 Cordova Platform Versions Supported by MAF

Surrounding text describes Figure 3-1 .

Using the OEPE migration wizard, shown in Figure 3-2, you can migrate from earlier versions of MAF. For example, if you have a MAF 2.0.0 application you can choose to migrate it to a later version of MAF, such as MAF 2.1 0.

Figure 3-2 Migration Wizard

This image is described in the surrounding text

3.2.1 How to Migrate an Application

OEPE has a migration wizard that makes it easy to migrate your application. You can choose to migrate to any available version using the wizard.

To migrate an application:

  1. Open the application in OEPE.

  2. Right click the assembly project and choose Configure > Migrate MAF Application. The migration wizard opens.

  3. Select the MAF version you want to migrate to and click Next.

  4. The Configure Deployments page of the wizard shows that the initial deployment is disabled. Click Add to add a new deployment target. Click Finish.

3.2.1.1 What Happens When you Migrate an Application

MAF applications developed using earlier releases of MAF registered plugins in the MAF Application Editor. This release of MAF registers plugins in the same editor, but due to changes to Apache Cordova the functionality is different.

Examine the application once it has migrated and make any appropriate changes. For example, enable additional core plugins and register external plugins in the MAF Application Editor, and specify the plugins used by features in the MAF Features Editor. For more information, see "Using Plugins in MAF Applications" in Developing Mobile Applications with Oracle Mobile Application Framework (OEPE Edition).

To complete the migration and make sure that your migrated MAF application can use the plugins it used previously, verify that the:

  • Version of the plugin is supported by MAF.

  • Obtain a newer version of the plugin if the plugin was created using an earlier release of Cordova.

3.3 Security Changes in Release 2.2.1 and Later of MAF

Starting with MAF 2.3.0, 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 Apple iOS 9's 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 Java 8's JVM 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:

  1. In OEPE, click the debug button and select Debug Configurations.

  2. In the Target Configuration pane of the Main tab, click Options.

  3. In the Advanced iOS Options dialog that appears, select the Disable ATS checkbox, as shown in Figure 3-3, and click OK.

    Figure 3-3 Disable ATS Option for MAF Application on iOS Devices

    The surrounding text describes the image.

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:

  1. Update maf.properties file with the version of SSL that you want to use. For example, add the following entry to the maf.properties file to use TLS 1:

    java.commandline.argument=-Dhttps.protocols=TLSv1

  2. 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

  3. 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 the java.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 the java.security entry as follows to enable the RC4 algorithm:

    jdk.tls.disabledAlgorithms=SSLv3, DH keySize < 768

3.4 Maintaining Separate Xcode Installations for MAF 2.3.0 and MAF 2.2.0

MAF 2.3.0 requires Xcode 7.x. If you want to maintain one development environment only (for MAF 2.3.0), install or upgrade to Xcode 7.x, as described in Section 2.4.1, "How to Install Xcode and iOS SDK." Once you install or upgrade to Xcode 7.x, make sure to start it so that you accept the license agreements. Failure to do this may cause deployment errors when you attempt to deploy a MAF 2.3.0 application to iOS. With this installation, Xcode 7.x replaces Xcode 6.x. No other changes are required. OEPE uses the active Xcode installation.

If you want to maintain separate development environments for MAF 2.3.0 (using Xcode 7.x) and MAF 2.2.0 or earlier (using Xcode 6.x), you can install both Xcode 6.x and Xcode 7.x on the same machine. See the following procedure for information about how you can accomplish this task.

For a complete list of supported versions of development and runtime tools, see the Oracle Mobile Application Framework Certification Matrix by following the Certification Information link on the MAF documentation page at http://www.oracle.com/technetwork/developer-tools/maf/documentation/.

To maintain separate Xcode 7.x and Xcode 6.x installations:

  1. Rename the preexisting Xcode.app installation for Xcode 6.x (For example, Xcode6.app.)

  2. Install Xcode 7.x from the Apple App Store, as described in Section 2.4.1, "How to Install Xcode and iOS SDK." Make sure that you install, not update, Xcode from the Apple App Store.

  3. Once you install Xcode 7.x, make sure to start it so that you accept the license agreements.

    After installation, verify that you have the following Xcode installations in your Applications location:

    Xcode 7.x installation:
/Applications/Xcode.app 
 
Xcode 6.x installation:
/Applications/Xcode6.app

  4. Once the two versions of Xcode have been installed, you must manually control which Xcode installation is active at any given time. Use the xcode-select command in a terminal window to perform this procedure, as shown in the following examples:

    //To make Xcode 7.x active: 
sudo xcode-select -s /Applications/Xcode.app
 
//To make Xcode 6 active: 
sudo xcode-select -s /Applications/Xcode6.app
 
//To determine which instance of Xcode is currently active:
xcode-select --print-path

3.5 Migrating MAF Applications that Use Customer URL Schemes to Invoke Other Applications

If the application you migrate to MAF 2.3.0 uses a custom URL scheme to invoke another application, and you deploy the application to iOS 9 or higher, add the scheme(s) to the Allowed URL Schemes list in the Security page of the maf-application.xml file's editor.

This change addresses iOS 9's requirement that applications declare any URL schemes they use to invoke other applications. Click the Add icon in the Allow URL Schemes section of the Security page to add the custom URL scheme, as shown in Figure 3-4.

Figure 3-4 Registering a Custom URL Scheme that a MAF Application Uses to Invoke Another Application

The surrounding text describes the image.

3.6 Migrating to JDK 8 in MAF 2.3.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 in MAF 2.3.0 for the first time, OEPE makes the following changes:

  • Renames the configuration file that specifies the startup parameters of the JVM from cvm.properties to maf.properties. For more information about the maf.properties file, see "How to Enable Debugging of Java Code and JavaScript" in Developing Mobile Applications with Oracle Mobile Application Framework (OEPE Edition).

  • Replaces instances (if any) of the following import statement in the application's Java source files:

    com.sun.util.logging

    With:

    java.util.logging

  • Replaces the following entries in the application's logging.properties file

    .handlers=com.sun.util.logging.ConsoleHandler
.formatter=com.sun.util.logging.SimpleFormatter

    With:

    .handlers=java.util.logging.ConsoleHandler
.formatter=java.util.logging.SimpleFormatter

    For more information about the logging.properties file, see "How to Configure Logging Using the Properties File" in Developing Mobile Applications with Oracle Mobile Application Framework (OEPE Edition).

3.7 Configuring your Migrated MAF Application to Use the Full Screen on iOS Devices

MAF applications that you create using the MAF 2.3.0 release and later use the full screen by default on devices running iOS 7 or later.

This means that the iOS device's status bar appears on top of the content rendered by the MAF application. Content from the MAF application appears overlaid by the status icons of the status bar, as shown in Figure 3-5. This happens because the iOS device's status bar's background is transparent. In Figure 3-5, a MAF application's yellow panel header component appears overlaid by the status bar's information about network, time, and battery.

The status bar that renders in an iOS device supports two styles: light and dark. MAF provides APIs to get and set the status bar style on the iOS device so that it renders appropriately when the MAF application renders in the background. Apply the light style to the status bar when the status bar renders on a MAF application with a dark background. Apply the dark style to the status bar when the status bar renders on a light background.

MAF provides the following JavaScript methods to get and set the style of your MAF application on an iOS device:

adf.mf.api.getStatusBarStyle = function(callback)
adf.mf.api.setStatusBarStyle = function(style, callback)

For more information about these methods, see JSDoc Reference for Oracle Mobile Application Framework.

MAF also provides the following Java methods in oracle.adfmf.framework.api.AdfmfContainerUtilities that you can use to set the status bar style from a managed bean or lifecycle listener in your MAF application.

getStatusBarStyle()
setStatusBarStyle(AdfmfContainerUtilities.STATUS_BAR_STYLE color)

For more information about these methods, see Java API Reference for Oracle Mobile Application Framework.

The MAF application ignores these methods on non-iOS devices. For more information about using Java and JavaScript APIs in your MAF application, see the "Local HTML and Application Container APIs" appendix in Developing Mobile Applications with Oracle Mobile Application Framework (OEPE Edition).

Figure 3-5 MAF Application Using the Full Screen on an iOS Device

The surrounding text describes the image.

MAF applications migrated to MAF 2.3.0 do not exhibit the just-described behavior. Instead, the iOS device's status bar appears above the MAF application. You can configure a MAF application that you migrate to MAF 2.3.0 to use the full screen on devices running iOS 7 or later.

3.7.1 How to Configure your Migrated MAF Application to Use an iOS Device's Full Screen

You configure a MAF application that you migrate to MAF 2.3.0 to use the full screen on a device running iOS 7 or later by setting the <fullscreenLayout> element in the maf-config.xml file.

To configure a migrated MAF application to use the full screen on an iOS device, make sure that the maf-config.xml file for your application is configured as follows:

<adfmf-config xmlns="http://xmlns.oracle.com/adf/mf/config">
....
<fullscreenLayout>fullscreen</fullscreenLayout>
</adfmf-config>

3.8 Retaining Legacy Behavior When Navigating a MAF Application Using Android's Back Button

MAF 2.2.1 introduces a change in the way that MAF applications created using this 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.3.0 or later uses the new behavior.

Figure 3-6 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 3-6 Navigation Flow Between Application Features and Pages in a MAF Application

The surrounding text describes the image.

Prior to Release MAF 2.2.1, 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 hibernate the MAF application

In MAF 2.2.1 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 Developing Mobile Applications with Oracle Mobile Application Framework (OEPE Edition).

3.8.1 How to Retain Pre-MAF 2.2.1 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.1 behavior when an end user taps Android's Back button.

To retain pre-MAF 2.2.1 application behavior in response to usage of Android's Back button, make sure that the maf-config.xml file for your application is configured as follows:

<adfmf-config xmlns="http://xmlns.oracle.com/adf/mf/config">
....
   <legacyBack>true</legacyBack> 
</adfmf-config>

3.9 Migrating to a New cacerts File for SSL in MAF 2.3.0

Make sure that the cacerts file packaged in the MAF application that you publish for your 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 your MAF application's cacerts file if the HTTPS server contains certificates not present in your MAF application's cacerts file. 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 JDK 8's keytool utility to view and manage the certificates in your MAF application's cacerts file. The following example demonstrates how you might use JDK 8's keytool utility to display the list of certificates in a cacerts file:

JDK8install/bin/keytool -list -v -keystore dirPathToCacertsFile/cacerts –storepass changeit | grep "Issuer:"

For more information about using the JDK 8's keytool utility 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 more 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 (OEPE Edition).

Use JDK 8's keytool utility, as previously described, to manage the certificates in MAF 2.1.0's cacerts file to meet the requirements of the environment where your MAF application will be used. The cacerts file lists the issuers of CA root certificates:

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