Skip Headers
Oracle® Application Server Certificate Authority Administrator's Guide
10g Release 2 (10.1.2)
B14080-02
  Go To Documentation Library
Home
Go To Product List
Solution Area
Go To Table Of Contents
Contents
Go To Index
Index

Previous
Previous
Next
Next
 

7 OracleAS Certificate Authority Administration: Advanced Topics

This chapter provides additional context and detail for Oracle Application Server Certificate Authority administrative features, for high-availability features, and for backup and recovery procedures in the following sections:

7.1 Wallet Operations for OracleAS Certificate Authority

Wallets are containers for certificates and trusted authorities' certificates. OracleAS Certificate Authority uses wallets for secure storage and access regarding these vital elements. When certificates, trusted authorities, or passwords change, the administrator must take action to enable their use in a consistent and secure manner. The following sections describe such actions:

7.1.1 Regenerating the CA Signing Wallet


Warning!:

This operation regenerates the CA signing certificate and replaces the existing CA certificate, invalidating all the certificates issued by the existing CA. For this reason, you must be extremely cautious before attempting the operation. Do not use it unless you are prepared to lose the existing CA certificate and all the certificates the CA issued.

Installation of OracleAS Certificate Authority as a root certificate authority (CA) also creates the CA signing certificate and the CA SSL wallet. The CA SMIME wallet is not generated automatically, but rather must be generated by the administrator. If the CA key is somehow compromised, this certificate and wallet can be regenerated using the administrative command line tool, ocactl, as described in the next section.

The new CA certificate and private key will be stored in the OracleAS Certificate Authority repository. The private key is encrypted by the same password that was requested and established during installation of the original CA. The former CA signing certificate entry and all other certificates issued by that former CA signing certificate will become invalid.

Other critical wallets, like CA SSL and CA SMIME, also need to be regenerated, and regenerating these does require a new password. After regeneration of the CA signing wallet, a CRL issued by the old CA will not be useful.

Example of the command to generate the CA signing wallet:

ocactl generatewallet -type CA

OracleAS Certificate Authority needs to be stopped to execute this command, which can take a few minutes to complete. To restart OCA, see the section titled "Starting and Stopping Oracle Application Server Certificate Authority" in Chapter 4, "Introduction to Administration and Certificate Management".

7.1.2 Regenerating the CA SSL and CA S/MIME Wallets

This section explains how to regenerate the CA SSL and CA S/MIME wallets, respectively.

7.1.2.1 The CA SSL Wallet

The CA SSL wallet is generated during installation and is used to enable the Oracle Application Server Certificate Authority engine to listen in HTTPS mode. In certain circumstances, you must regenerate the CA SSL and CA S/MIME wallets in order to establish secure communications with the OracleAS Certificate Authority server. These circumstances include a wallet becoming compromised or corrupted, or the CA Signing wallet being regenerated, or a new Sub CA certificate being installed.

Here is an example of the command to generate the CA SSL wallet:

ocactl generatewallet -type CASSL

OracleAS Certificate Authority, OracleAS Certificate Authority's OC4J, and OHS all need to be stopped to execute this command. After this command executes, restart OHS, OC4J, and OracleAS Certificate Authority, in that order.

This wallet is stored as ewallet.p12 (PKCS#12) under the directory $ORACLE_HOME/oca/wallet/ssl, encrypted by the password that was provided during its generation. This command also generates CA SSL wallet in OracleAS Single Sign-On format and stores it as cwallet.sso at $ORACLE_HOME/oca/wallet/ssl.

The advantage to using cwallet.sso is that HTTP Server can be brought up in SSL mode without requiring the Oracle HTTP Server administrator to supply the wallet password. This password is normally requested when HTTP Server starts up in SSL mode, using a PKCS#12 wallet.

The OracleAS Single Sign-On server-format wallet is obfuscated to discourage users from visually opening the file and extracting the keys. However, the operating system file permissions are relied upon to protect it, since it is created with owner-only permissions. The next startup of OracleAS Certificate Authority instance in OPMN will use this wallet for SSL server authentication. (After CA SSL/OracleAS Single Sign-On wallet generation, the OPMN stopall and startall commands are required.)

7.1.2.2 The CA S/MIME Wallet

The CA S/MIME wallet enables OracleAS Certificate Authority to sign alerts and notification messages. You must generate it before selecting "Send SMIME E-Mails" in the Notification subtab of Configuration Management in the OracleAS Certificate Authority Administration pages. Once generated, this wallet resides in the OracleAS Certificate Authority database repository.

If this S/MIME wallet is compromised or corrupted, or when the CA signing wallet is regenerated, you must regenerate the CA S/MIME wallet. This wallet is encrypted by the administrator's password, which is required to execute the command generating the wallet. You will also be asked for the administrator's Distinguished Name and email address.

Here is an example of the command to generate the CA S/MIME wallet:

ocactl generatewallet -type CASMIME

The following steps generate and use the CA S/MIME wallet:

  1. Go to Configuration Management -> Notification. Select the Send SMIME E-Mails option.

  2. Stop OracleAS Certificate Authority using the command

    $ORACLE_HOME/oca/bin/ocactl stop
    
    
  3. Generate the CA S/MIME wallet using the command

    ocactl generatewallet -type CASMIME
    
    
  4. Start OracleAS Certificate Authority using the command:

    $ORACLE_HOME/oca/bin/ocactl start
    
    

After regeneration of the CA S/MIME wallet, the old CA S/MIME wallet will not be of any use. The new CA S/MIME wallet is used to sign alert and notification messages.

7.1.3 Renewing Critical Wallets

When a certificate is going to expire, renewal will be required. CA Signing, CA SSL, and CA S/MIME wallets can be renewed using ocactl, the administrative command line tool. During the execution of the renewcert command, ocactl will prompt for the new validity period, taking the input as the number of days for which the certificate is to be renewed.

When the CA signing certificate is renewed, a new certificate with new validity period is created and stored in OracleAS Certificate Authority's metadata repository.

When the CA SSL wallet is renewed, the old wallet ewallet.p12 at $ORACLE_HOME/oca/wallet/ssl/ will be overwritten with the renewed wallet. Renewal of the CA SSL wallet also overwrites the cwallet.sso at $ORACLE_HOME/oca/wallet/ssl/.

When the CA S/MIME wallet is renewed, the new wallet overwrites the old CA SMIME wallet in the database repository.

Example to renew CA signing wallet:

ocactl renewcert -type CA

A renewed CA S/MIME wallet can be used simply by restarting OracleAS Certificate Authority. The renewed CA and CA SSL wallets take effect only after OHS, OracleAS Certificate Authority's OC4J, and OracleAS Certificate Authority are restarted, in that order, as described in the section titled "Starting and Stopping Oracle Application Server Certificate Authority" in Chapter 4, "Introduction to Administration and Certificate Management".

7.1.4 Changing Passwords

After installation, you can change any of the following passwords: CA, CA SSL, CA S/MIME, or DB, by stopping OracleAS Certificate Authority, issuing the ocactl setpasswd command, and then restarting OracleAS Certificate Authority.


See Also:

Appendix A, "Command-Line Administration" for detailed descriptions of using ocactl.


Note:

The OracleAS Certificate Authority schema password can be changed only by running this command: ocactl setpasswd -type DB. It should not be changed by going directly to the database, for example, by using sqlplus, because OracleAS Certificate Authority will stop working if that is done.

The changes resulting from executing these commands take effect after the next start of OracleAS Certificate Authority. Each use of ocactl requires the OracleAS Certificate Authority administrator password. Once this is authenticated, the command requests the new password for the role type specified in the command, which then replaces the one in the password store. The results are again encrypted using the latest OracleAS Certificate Authority administrator password.

Example to change OracleAS Certificate Authority repository password:

ocactl setpasswd -type DB

Note:

If the CA SSL wallet password is changed, you must restart OHS, OracleAS Certificate Authority's OC4J, and OracleAS Certificate Authority, in that order, except in the default install scenario wherein OracleAS Certificate Authority uses cwallet.sso: in that case, OHS need not be restarted.

7.2 Configuration Operations for OracleAS Certificate Authority

The OracleAS Certificate Authority administrator configures it to meet the needs of the site using it. Some of these operations are done through the web interface. Others require using command line tools such as ocactl, the OracleAS Certificate Authority administrative command line tool, and others that control components on which OracleAS Certificate Authority relies. These configuration operations and the actions the administrator must take are described in the following sections:

7.2.1 Configuring Oracle HTTP Server to Use a Third Party SSL Wallet

When OracleAS Certificate Authority is installed, it is automatically configured in SSL mode. Browsers will warn that this site is not trusted until you install the CA certificate. (You can either explicitly install the CA or edit the CA entry in the browser.) To avoid this warning, the OracleAS Certificate Authority administrator can get an SSL certificate for the OracleAS Certificate Authority server from a well-known CA like Verisign.

The convertwallet command is used to convert such an SSL Server wallet (ewallet.p12, in PKCS#12 format) into a wallet in the OracleAS Single Sign-On format, with file name cwallet.sso. The advantage to using cwallet.sso is that HTTP Server can be brought up in SSL mode without requiring you to supply the wallet password. This password is usually requested when HTTP Server starts up in SSL mode, using a PKCS#12 wallet. The OracleAS Single Sign-On server-format wallet is encrypted to discourage users from visually opening the file and extracting the keys. However, the operating system file permissions are relied upon to protect it, since it is created with owner-only permissions. Thus the convertwallet command enables the OracleAS Single Sign-On server to bring up the web server in SSL mode automatically, without asking a human for the wallet password.

To install a wallet from a well-known CA, do the following:

  1. Shut down OracleAS Certificate Authority, OCA's OC4J, and OHS.

  2. Back up wallets in $ORACLE_HOME/oca/wallet/ssl.

  3. Using Oracle Wallet Manager, create a complete SSL server wallet:

    1. Request an SSL certificate.

    2. Install the certificate of the third-party CA that issued the server certificate.

    3. Install your requested server certificate.

  4. Using OWM, import the current OracleAS Certificate Authority CA's certificate as a trust point into this wallet.


    See Also:

    Oracle Advanced Security Administrator's Guide

  5. Save the wallet at $ORACLE_HOME/oca/wallet/ssl.

    Now OCA-issued certificates can be trusted as client certificates against this wallet as the CA SSL server's certificate.

  6. Copy the wallet created from the third-party CA (in PKCS#12 format) to $ORACLE_HOME/oca/wallet/ssl/ewallet.p12.

  7. Run convertwallet -format SSO.

  8. Start OHS, OracleAS Certificate Authority's OC4J, and OracleAS Certificate Authority, in that order.

7.2.2 Revoking a Certificate Authority Certificate

Revoking a CA signing certificate is a very drastic operation, which will make OracleAS Certificate Authority installation non-functional and invalidate the certificates already issued. This operation, revocation, should only be done when the CA key is compromised, so that you can install a new certificate authority.

Using a sub-CA reduces the risk and cost. Hierarchical CA structure enables normal operations to be conducted by the sub-CA while the root CA is especially protected, perhaps being off-line in a highly secure location. In this way, even if an online subordinate CA is compromised, it can be revoked and a new sub-CA created to replace it. All earlier operations can continue using certificates as issued.

However, if the root CA is compromised, a completely new infrastructure needs to be established, and all applications relying on it need to be updated.

For these reasons, Oracle recommends using a hierarchy of CA's, with special protection for the root CA.

The revokecert command enables you to revoke a root certificate authority certificate or an OracleAS Certificate Authority Administrators certificate. It can only be used when OracleAS Certificate Authority services are not running. Revoking a root certificate authority certificate is required before installing a new CA signing for ongoing OracleAS Certificate Authority operations.

When you intend to install a new CA, first revoke all certificates issued by the existing CA, and update the Certificate Revocation List. This step is necessary because until the new CA signing certificate is generated, all the old certificates signed by the old CA would be marked as Invalid in the OracleAS Certificate Authority repository.

Then use revokecert to revoke the old CA signing wallet, giving your reason as a parameter. Once the CA signing certificate is revoked, all certificates issued by that CA would be in an inconsistent state, had you not revoked them already.

Once the OracleAS Certificate Authority administrator certificate is revoked, the administrator cannot access any administrative functions on the web until he gets a new certificate. When he opens the Administration home page, it will require a new enrollment to get a new Administrators certificate.

Example of the command to revoke CA certificate when its key is compromised:

ocactl revokecert -type CA -reason KEY_COMPROMISE

Steps to be followed to revoke CA certificate and restart OracleAS Certificate Authority:

  1. Stop OracleAS Certificate Authority. Use the command

    $ORACLE_HOME/oca/bin/ocactl stop
    
    
  2. Revoke the CA signing wallet using the command shown earlier.

  3. Regenerate the CA SSL wallet.

  4. Start OracleAS Certificate Authority. Use the following command:

    $ORACLE_HOME/oca/bin/ocactl start
    

7.2.3 Revoking the OracleAS Certificate Authority Web Administrator's Certificate

You may in future need to replace the administrator's certificate. Reasons could include the password to your private key being lost, the private key somehow being compromised or stolen, or the administrator role being given to someone new. This operation, revocation, should only be done when the Web administrator key is compromised, so that you can enroll new OracleAS Certificate Authority web administrator.

To replace the administrator certificate, you must stop the server, revoke the current administrator's certificate, and restart the server. These tasks are performed by using the server command-line tool opmnctl and the OracleAS Certificate Authority command-line tool ocactl, which requires the OracleAS Certificate Authority Administrator password.

Once the OracleAS Certificate Authority administrator certificate is revoked, the administrator cannot access any administrative functions on the web until he gets a new certificate. When he opens the Administration home page, it will require a new enrollment to get a new Administrator's certificate.

The administrator then navigates to the OracleAS Certificate Authority web page and fills in the OracleAS Certificate Authority Web administrator enrollment form.

Example of the command to revoke Web Administrator's wallet when its key is compromised:

ocactl revokecert -type WEBADMIN -reason KEY_COMPROMISE

Steps to be followed to revoke Web Administrator's certificate and restart OCA:

  1. Stop OracleAS Certificate Authority. Use the command

    $ORACLE_HOME/oca/bin/ocactl stop
    
    
  2. Revoke the Web Administrator's certificate using the command

    ocactl revokecert -type WEBADMIN -reason <REASON>
    
    
  3. Start OracleAS Certificate Authority. Use the following command:

    $ORACLE_HOME/oca/bin/ocactl start
    
    

Note:

Having revoked the webadmin certificate, you cannot use it to log in to the web interface for OracleAS Certificate Authority. You must remove it from the browser certificate store before opening the OracleAS Certificate Authority web interface. Then you will be able to display that interface and enroll anew as the administrator.

7.2.4 Configuring Globalization Support for Screens

The administrative and user screens for OracleAS Certificate Authority can appear in the language of the client or of the server, under the following conditions:

  1. The Database Character Set must be UTF8.

  2. The UI and online help of OracleAS Certificate Authority are rendered in the locale of the client, as are dates. (Times are rendered in the server time zone.) If the client locale is not supported, the screens are rendered in the server locale. If the server locale is also not among the languages supported by OracleAS Certificate Authority, then English is the language used.

  3. The practice statement is rendered in the locale in which the Administrator edits the practice statement irrespective of the client locale.

  4. ocactl provides globalization support depending on the server locale. If the server locale is anything other than the OracleAS Certificate Authority supported languages, display is in English.

  5. In every locale, the actual ocactl commands are themselves in English.

  6. Informational messages, such as alerts, notifications, or error messages, are displayed in the language of the server locale, not in the client locale if that is different from the server locale. For example, if OracleAS Certificate Authority were installed on a server whose locale is English, and a Japanese client submits a request, the notification will be in English.

    If you use templates for customizing alerts or notifications, as described in the next section, the language in which you edit those templates is used. It is advisable to edit the templates in the language of the server, because the message body is encoded in the language of the server locale.If you do not use templates, then all alerts and notifications will appear in the language of the server locale.

7.3 Performance Tuning for OracleAS Certificate Authority

You can enhance the performance of your OracleAS Certificate Authority instance by setting several customizable parameters for the database, Single Sign-On, and memory, as described in these sections:

7.3.1 Tuning Database Connections

Table 7-1 Tuning Database Usage

Method Topic Reference

Make the database pool size the number of concurrent users that you are expecting (default 20).

"Database Settings"


Make the database pool scheme dynamic. (default)

"Database Settings"



Each connection in the connection pool uses up a database dedicated process. Therefore, if you adjust these sizes, you need to ensure that the database parameter named PROCESSES is greater than the sum of the following five numbers:

  • Size of the OracleAS Certificate Authority pool

  • Number assigned for Single Sign-On maximum connections in pool

  • Number of mod_plsql connections (could equal the number of users concurrently logging out, because Single Sign-On uses mod_plsql for logout)

  • Number of Oracle Internet Directory connections, computed as the product of Oracle Internet Directory processes and the number of database connections for each process

  • Number of database connections used by other Oracle products


See Also:

See the discussion of PROCESSES in Oracle10i Database Administrator's Guide.

7.3.2 Tuning Interactions with OracleAS Single Sign-On

For optimum performance, ensure that the Single Sign-On database pool size is not less than the OracleAS Certificate Authority database pool size.

In OracleAS Certificate Authority, the minimum database pool size is hardcoded as 3, so for OracleAS Certificate Authority you can only adjust the maximum. Single Sign-On lets you configure both the minimum and maximum pool size, which are in the policy.properties file as the parameters (minConnectionsInPool and maxConnectionsInPool.

7.3.3 Tuning Maximum Memory

OracleAS Certificate Authority is configured to use a maximum memory of 256MB, which should be sufficient for most purposes. However, if you experience OutOfMemory errors, you can change your configuration to use more memory by setting the JVM heap size.


See Also:

See the discussion of JVM heap in Oracle Application Server Performance Guide.

7.3.4 Tuning Oracle Internet Directory Connections

The number of database connections used by Oracle Internet Directory depends on the number of Oracle Internet Directory processes and the number of database connections for each process. Tune these parameters by adjusting the number of concurrent database connections a single directory server process can have and the number of server processes a single instance can spawn.


See Also:

See the discussion of connections and Server Management Fields in Oracle Directory Manager in the appendix on graphical user interfaces in Oracle Internet Directory Administrator's Guide.

7.3.5 Tuning Other Components

Other Oracle components that you have installed may have additional parameters useful in tuning your system's performance. See the manuals for those components to learn about possible steps you can take toward performance enhancement at your site.

7.4 Customization Support

OracleAS Certificate Authority enables you to customize the SSO-OracleAS Certificate Authority interface by specifying your own headers and footers for the following three provisioning pages:

  1. The Welcome screen

    Description of welcomenetscape.gif follows
    Description of the illustration welcomenetscape.gif


    Note:

    To see this pop-up, users must have pop-up-blocking turned off in their browsers.

  2. The Enrollment screen

    Description of scndssontscpaftrwlcm.gif follows
    Description of the illustration scndssontscpaftrwlcm.gif

  3. The Install Certificate screen

    Description of ssoapprvdcertinf90103.gif follows
    Description of the illustration ssoapprvdcertinf90103.gif

Although OracleAS Certificate Authority will by default render the existing screens without customization, the OracleAS Certificate Authority administrator can customize any of the three with unique headers or footers. By providing a custom HTML file for any such screen, the administrator signals OracleAS Certificate Authority to use that customized screen in place of the corresponding default screen. These custom HTML files can contain static HTML content. If no customized HTML files are provided, or if they are of zero size, the default screens are used.

The templates for creating such a custom HTML file are in the directory named $ORACLE_HOME/oca/templates/screens. The administrator controls the look and feel of this content.

If any customization screen HTML file exists with nonzero size, its content is added to the default screen at the specified position indicated in Table 7-2.


Notes:

After making changes to any of these HTML files, the administrator must restart OracleAS Certificate Authority to cause those changes to be used.

Please note that OracleAS Certificate Authority is not responsible for the content, translation, or accessibility of anything customized, such as screens, messages, alerts, notifications, or other content, which will be rendered as is.


Table 7-2 Customization of Single Sign-On Popup Screens

Screen Name Position of Replaceable Text Files to Contain Replaceable TextFoot 1 

Welcome Screen

For a header: between the OracleAS Certificate Authority lines reading "Welcome to OracleAS Certificate Authority" and "To get a certificate Click Here"

For a footer: under the line reading "To get a certificate Click Here"

$ORACLE_HOME/oca/templates/ screens/homeheader.html

$ORACLE_HOME/oca/templates/ screens/homefooter.html

Enrollment Screen

For a header: between OCA's "Blue bar at the top" and the line reading "User DN"

For a footer: under the lines at the bottom, reading "Key Size" and "SKI".

$ORACLE_HOME/oca/templates/ screens/enrollheader.html

$ORACLE_HOME/oca/templates/ screens/enrollfooter.html

Install Certificate Screen

For a header: between the OracleAS Certificate Authority lines reading

"View Certificate" and "Certificate details"

For a footer: between the OracleAS Certificate Authority lines reading "After certificate details" and "SKI" at the bottom.

$ORACLE_HOME/oca/templates/ screens/importheader.html

$ORACLE_HOME/oca/templates/ screens/importfooter.html


Footnote 1 If any file in this column exists with nonzero size, the corresponding header or footer will be replaced with that file's static HTML.

7.5 Log or Trace OracleAS Certificate Authority Actions

You can use the ocactl set command to enable log and trace, so that OracleAS Certificate Authority/Admin operations can be viewed in the log/trace storage.

Table 7-3 Storage Locations for OracleAS Certificate Authority Log and Trace Data

Type of Data Storage Form Location

OracleAS Certificate Authority Log

OracleAS Certificate Authority repository

OracleAS Certificate Authority repository

OracleAS Certificate Authority Trace

File: oca.trc

$ORACLE_HOME/oca/logs

ADMIN Log

File: admin.log

$ORACLE_HOME/oca/logs

ADMIN Trace

File: admin.trc

$ORACLE_HOME/oca/logs


The set command has the following format:

ocactl set  -type {LOG | TRACE} -mode {OCA|ADMIN} -state {ON|OFF}

Examples:

  1. ocactl set -type LOG -mode OracleAS Certificate Authority -state ON

    Enables storing log messages in the OracleAS Certificate Authority repository.

  2. ocactl set -type TRACE -mode OracleAS Certificate Authority -state ON

    Enables storing trace messages in the oca.trc file.

  3. ocactl set -type LOG -mode ADMIN -state ON

    Enables storing log messages in the admin.log file.

  4. ocactl set -type TRACE -mode ADMIN -state ON

    Enables storing trace messages in the admin.trc file.

  5. ocactl set -type TRACE -state OFF

    Turns off tracing: no trace data are stored.

7.5.1 Clearing Log or Trace Information for OracleAS Certificate Authority

The ocactl administrative command line tool enables removal of existing log or trace storage at the administrator's choice. The OracleAS Certificate Authority log will be stored in the OracleAS Certificate Authority repository, and the OracleAS Certificate Authority trace will be stored in oca.trc at $ORACLE_HOME/oca/logs. The Admin log will be stored in admin.log at $ORACLE_HOME/oca/log, and the Admin trace will be stored in admin.trc at $ORACLE_HOME/oca/logs.

Executing the clear command on an allowed type and mode deletes the old contents of such log or trace storage. Files affected by such commands (oca.trc, admin.trc, or admin.log) are simply removed from the file system.

The clear command has the following format:

ocactl clear -type {LOG |TRACE}  -mode {OCA|ADMIN} 

Examples:

  1. ocactl clear -type LOG -mode ADMIN

    Removes the Admin log file admin.log from $ORACLE_HOME/oca/logs

  2. ocactl clear -type TRACE -mode ADMIN

    Removes the Admin trace file admin.trc from $ORACLE_HOME/oca/logs

  3. ocactl clear -type LOG -mode OCA

    Removes log messages in the OracleAS Certificate Authority repository

  4. ocactl clear -type TRACE -mode OCA

    Removes the OracleAS Certificate Authority trace file oca.trc from $ORACLE_HOME/oca/logs

7.6 Changing the Infrastructure Services

Changes to OracleAS Single Sign-On and Oracle Internet Directory, such as using a new port or host, can arise in a variety of ways, including the following situations:

OracleAS Certificate Authority is installed as part of the OracleAS Identity Management (IM) infrastructure and uses the services of Oracle Internet Directory, OracleAS Single Sign-On, and a metadata repository. If any of these components is replaced or restored, OracleAS Certificate Authority can be configured to use these new services. It can either use existing versions of these three components or work with a new Oracle Internet Directory, OracleAS Single Sign-On and metadata repository.

Oracle Application Server supports two types of infrastructure change:

The following section describes the display of data regarding these services:

7.6.1 Changing Identity Management (IM) Services

After installation of a new OracleAS Single Sign-On or Oracle Internet Directory, changing OracleAS Certificate Authority's IM Services requires two steps:

  • Installing a new IM and migrating the existing data.

  • Configuring OracleAS Certificate Authority to use the newly installed IM Services.

OracleAS provides scripts to migrate data from one IM instance to another, assuming that a new IM (OracleAS Single Sign-On/Oracle Internet Directory) has been installed. However, you cannot use the Change Identity Management Wizard on the Infrastructure page of the Application Server Control Console to change OracleAS Certificate Authority services because OracleAS Certificate Authority itself is an infrastructure component. So OracleAS Certificate Authority supports changing OCA's IM Services by providing the "changesecurity" command from the OracleAS Certificate Authority administrative command line tool ocactl.


See Also:


The following steps establish the new IM services for OracleAS Certificate Authority:

  1. Install Identity Management and Metadata Repository on Machine 1.

  2. Install Identity Management on Machine 2.

  3. Migrate IM data from Machine 1 to Machine 2 using the scripts provided by OracleAS.

  4. In the machine with OracleAS Certificate Authority (Machine 1), bring down OracleAS Certificate Authority, OracleAS Certificate Authority's OC4J, and OHS. Use these commands:

    $ORACLE_HOME/oca/bin/ocactl stop
    $ORACLE_HOME/opmn/bin/opmnctl stopall
    
    
  5. In Machine 1, edit the ias.properties file to make the OIDhost and OIDport parameters under $ORACLE_HOME/config directory point to the new IM, that is, Machine 2.

  6. On Machine 1, execute the following command:

    $ORACLE_HOME/oca/bin/ocactl changesecurity -server_auth_port portno 
    
    

    This command performs the following two actions:

    • Updates the file oca.conf at $ORACLE_HOME/oca/conf to point to the new IM Services machine (Machine 2)

    • Registers OracleAS Certificate Authority with the new OracleAS Single Sign-On server (Machine 2)


    Note:

    Identity Management (IM) reassociation can be used to accommodate changes to the configuration of OracleAS Single Sign-On or Oracle Internet Directory services for scalability or failover purposes, or to accommodate the transition from a pilot IM to production IM.For more information on such reassociation, see Oracle Application Server Administrator's Guide.

7.6.2 Changing Metadata Repository (MR) Services

Changing OracleAS Certificate Authority's Metadata Services from one physical database to a different physical database is not supported. However, changes to connection strings, such as changing the listener or the port, are accommodated by using the updateconnection command as documented in Appendix A.

7.6.3 Where Connection Information Is Stored and Displayed

Information defining connections to the OracleAS Certificate Authority repository and directory (used for publishing certificates) is stored in Oracle Internet Directory. This connection information is originally written to Oracle Internet Directory when Oracle Application Server is installed, at which time it is also fetched from Oracle Internet Directory and written into the OracleAS Certificate Authority configuration file $ORACLE_HOME/oca/conf/oca.conf.

This connection information is displayed under Settings in the General subtab of the OracleAS Certificate Authority web interface for the administrator.

7.7 OracleAS Certificate Authority and High-Availability Features

The primary reference for Oracle Application Server high-availability features is the Oracle Application Server High Availability Guide. The following discussion is merely an overview to orient you to those features.

OracleAS Certificate Authority facilitates swift and easy use of certificates in real-world, high-availability systems. The linkages, procedures, conventions, and preparations supporting the high-availability capabilities of Oracle® Application Server Cold Failover Clusters and Real Application Clusters are discussed in the following sections of the Oracle Application Server High Availability Guide:

7.7.1 OracleAS Certificate Authority Deployment Using Cold Failover

In a cold-failover configuration, a number of physical hosts have access to a common store on shared disks, and each physical node can host one or more logical hosts at the same time. Using an Oracle® Application Server Cold Failover Cluster enables transparent failover of an Oracle Application Server instance from a failed node to a backup. The failover can also be initiated manually, for maintenance.

In this example, there is only one software and database installation to be performed, and two physical hosts share access to the disk on which the OracleAS Certificate Authority/Oracle Application Server software and database reside. If the hardware for Oracle Application Server is configured as a cluster of machines, then the installer recognizes the node as part of the cluster and asks for the name of the virtual host. When the physical host 1 fails or is taken offline for maintenance purposes, its logical hostname (virtual host A) will be migrated to the other physical host. Vendor-specific scripts and hardware cluster software can be used to start the required database, listener and OracleAS Certificate Authority/Oracle Application Server processes to effect transparent failover. Clients continue to talk to the same logical host as before, with minimal service disruption. OracleAS Certificate Authority, too, must be restarted with the ocactl start command, after HTTP server and OC4J are brought up.

7.7.2 OracleAS Certificate Authority Deployment Using Real Application Clusters

OracleAS Certificate Authority provides limited support for Real Application Clusters (RAC). It can use the RAC configuration's other infrastructure components, such as Oracle Internet Directory, Oracle Database, and OracleAS Single Sign-On, but OracleAS Certificate Authority itself cannot be in the RAC mode.


See Also:

Oracle Application Server High Availability Guide for guidance regarding how to install these components in the RAC mode.


Note:

In OracleAS Certificate Authority 10g Release 2 (10.1.2), RAC is not supported on Windows.

7.8 OracleAS Certificate Authority Backup and Recovery Considerations

The phrase "backup and recovery" refers to the various strategies and procedures involved both in guarding against data loss and in reconstructing the data if a loss occurs. The Oracle Application Server backup recovery tool aids in backing up and recovering the Oracle Application Server environment in the event of a failure.


See Also:

Full documentation of backup and recovery tools and procedures appears in the following books:
  • For detailed descriptions of the various backup and recovery methods available, the installation and configuration of the Oracle Application Server backup/recovery tool, and component-wise backup and recovery, please refer to the backup/recovery documentation in the Oracle Application Server Administrator's Guide.

  • For database backup, use the Oracle backup and recovery guidelines as described in the Oracle10i Backup and Recovery Advanced User's Guide.

  • For backing up Oracle Internet Directory, use the Oracle Internet Directory Administrator's Guide.


The descriptions that follow are introductory only; full information is in the books listed earlier.

Scenarios in which backup/recovery techniques could be used to recover data include the following situations:

Table 7-4 Scenarios for Backup/Recovery

Situations Responses

Loss of host

You can restore to a new host with the same hostname and IP address.

Alternatively, you can restore to a new host with a different hostname and IP address.

Oracle software/binary loss or corruption

If any Oracle binaries are corrupted or lost, you must recover the entire infrastructure.

Metadata Repository instance failure, such as a failure of the database instance

Use database instance recovery methods to recover the metadata repository instance.

Metadata Repository database failure, meaning only the metadata repository has been corrupted, and not any other files in the infrastructure Oracle home.

Take a backup of the metadata repository using B/R scripts and recover the database using the OracleAS Backup and Recovery Tool.

Deletion/corruption of Oracle Application Server component runtime configuration files

Restore configuration files using a B/R script.

Metadata Repository listener failure

Kill and restart the listener process.


Various backup and recovery procedures protect and preserve OracleAS Certificate Authority content and capability in the event of required maintenance or unexpected loss of service.

Backup and corresponding recovery methods are supported by the following backup/recovery tools:

Table 7-5 Backup/Recovery Tools

Tool Name Functionality

Cold Backup/Recovery

Refers to restoring the entire Oracle Application Server infrastructure instance including the Oracle home, configuration files, and database files that were backed up after completing a clean and normal shutdown of all Oracle Application Server infrastructure processes and metadata repository

Partial Online (hot) Backup/Recovery

Refers to restoring the Oracle Application Server infrastructure configuration files and database files that were backed up after completing a proper online backup of the OracleAS instance and metadata repository

Incremental Backup/Recovery of Configuration files

Refers to restoring only the Oracle Application Server infrastructure configuration files taken from an online backup


Since OracleAS Certificate Authority uses the Oracle Database as its primary repository, the OracleAS Certificate Authority information stored in that database will be automatically backed up when that database is backed up. Similarly, OracleAS Certificate Authority relies on Oracle Internet Directory for publishing certificates and for certain OracleAS Single Sign-On operations. The three books named at the start of this section provide the detailed information supporting all related backup and recovery operations.

In addition to information stored in the database and directory, OracleAS Certificate Authority also creates a number of important operating system files. These files should be backed up as part of the normal backup process. These files are as follows (where $ORACLE_HOME represents the home directory in which OracleAS Certificate Authority is installed):

7.9 Restricting the Realm of Certificate Publication

Large organizations with geographically separate campuses can establish separate Certificate Authorities for each campus for more efficient local administration. These campuses could be in different states, such as Wyoming and New York, or in different countries, such as one in the United States and one in the United Kingdom. The different instances of OracleAS Certificate Authority may be Sub CAs or independent CAs that trust each other.

By default, when an OracleAS Certificate Authority instance is installed in a particular machine, an entry is placed into Oracle Internet Directory representing that installed OracleAS Certificate Authority instance, with the following DN:

cn=ocaN,cn=OCA,cn=PKI,cn=Products,cn=OraclContext

(where N is 1,2 …n)

To see the entry that corresponds to the current OracleAS Certificate Authority, go to the Administration page, to the Configuration Management tab and the General subtab. The DN under the Directory settings entry for Agent shows you the current Oracle Internet Directory for the current OracleAS Certificate Authority.

By default, each such CA is a member of the group cn=PKIAdmins,cn=Groups, cn=OracleContext, which is the top-level Oracle context.

When such a CA publishes a user certificate, that certificate is automatically placed in that user's DN entry in the corresponding subscriber realm within Oracle Internet Directory. By default, all CA's are trusted and can publish to any user entry in the whole directory. For example, a user in the US realm could receive a certificate from the UK OracleAS Certificate Authority, and the user certificate would be placed in that user's DN entry in the US realm.

However, it is possible to restrict the publishing rights of an OracleAS Certificate Authority instance so that it can only publish to a particular subscriber realm. For example, the UK OracleAS Certificate Authority could be restricted to publishing only to the UK subscriber realm. If this is done, then a certificate issued by the UK OracleAS Certificate Authority to a US user could not be published, because the user's standard realm would not be accessible to the UK OracleAS Certificate Authority.

To restrict an OracleAS Certificate Authority to a particular realm, you must remove it from the top-level group (cn=PKIAdmins,cn=Groups, cn=OracleContext) and add an entry for that OracleAS Certificate Authority to the desired group. For example, to restrict OCA2 to publish only to this subscriber dc=com,dc=acme, the following two commands would be used:

-remove cn=oca2,cn=cn=OCA,cn=PKI,cn=Products,cn=OraclContext from group cn=PKIAdmins,cn=Groups,cn=OracleContext

-add cn=oca2,cn=cn=OCA,cn=PKI,cn=Products,cn=OraclContext to group cn=PKIAdmins,cn=Groups,cn=OracleContext,dc=acme,dc=com

In addition, a custom plug-in can be written to limit the CA to manage only certificates from a specific set of DN's. For example, the sample plug-in developed in Chapter 6, "Managing Policies in Oracle Application Server Certificate Authority" restricts that CA to issuing certificates from non-U.S. domains only.

This restriction appears in line 12 of the example in that chapter's section entitled "An Example of a Custom Policy Plug-in":

12: if (!policyRequest.getCountry().equals("US"))

A few alterations --- removing the "!" and changing "US" to whatever realm is desired --- plus fixing a few subsequent, dependent lines would restrict certificate issuance to that chosen realm.

7.10 Replacing the CA and Deinstalling OracleAS Certificate Authority

In the rare and drastic event that the root CA needs to be replaced, perhaps because its private key was somehow compromised, OracleAS Certificate Authority should be deinstalled and then reinstalled. The deinstallation will remove all traces of the original installation's database and Oracle Internet Directory entries.To accomplish this deinstallation, follow the instructions in Section C.1.5 of the Oracle Application Server 10g Installation Guide.