Skip Headers

Oracle® Application Server Certificate Authority Administrator's Guide
10g (9.0.4)

Part Number B10663-01
Go To Documentation Library
Home
Go To Product List
Solution Area
Go To Table Of Contents
Contents
Go To Index
Index

Go to previous page Go to next page

6
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:

Wallet Operations for OracleAS Certificate Authority

Wallets are containers for certificates and trusted authorities' certificates. Oracle Application Server 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:

Regenerating the CA Signing Wallet


Note:

You need to be extremely cautious before this operation is attempted. Because this operation regenerates the CA signing certificate, it replaces the existing CA certificate and invalidates all the certificates issued by the existing CA.


Installation of Oracle Application Server Certificate Authority as a root certificate authority (CA) also creates the CA signing certificate, CA SSL wallet, and CA SMIME wallet. If the CA key is somehow compromised, these wallets can be regenerated using the ocactl command line tool, as described in the next section.

The new CA certificate and private key will be stored in the OCA repository. The private key is encrypted by the password that was requested during its generation. The former CA signing certificate entry and all other certificates issued by that former CA signing certificate will become invalid. Critical wallets like CA SSL, CA SMIME need to be regenerated. After regeneration of the CA wallet, a CRL issued by the old CA will not be useful.

Example of the command to generate the CA wallet:

ocactl generatewallet -type CA

OCA 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 3, "Introduction to OCA Administration and Certificate Management".


Note:

Domain component entries in the DN can be used in addition to (or to replace) entries for organization or country. Examples include dc=be (for belgium) or dc=us (for United States) or dc=oracle or dc=com. See also the section entitled Domain Component Attributes in Appendix E, "Glossary".


Regenerating the CA SSL and CA SMIME Wallets

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 SMIME wallets in order to establish secure communications with the OCA server. These circumstances include a wallet becoming compromised or corrupted, or the CA wallet being regenerated, or a new Sub CA certificate being imported.

Example of the command to generate the CA SSL wallet:

ocactl generatewallet -type CASSL

OCA, OCA's OC4J, and OHS all need to be stopped to execute this command. After this command executes, restart OHS, OCA's OC4J, and OCA, 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 SSO 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 SSO-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 OCA instance in OPMN will use this wallet for SSL server authentication.

The CA SMIME Wallet

The CA SMIME wallet is used to enable the Oracle Application Server Certificate Authority to sign alerts and notification messages. This wallet will be used only when "Send SMIME E-Mails" is enabled in Notification page of Configuration Management in OCA Admin page.

See Also:

Mail Details in Chapter 4, "Configuring Oracle Application Server Certificate Authority"

If this SMIME wallet is compromised or corrupted, or when the CA wallet is regenerated, you must regenerate the CA SMIME wallet. This wallet is encrypted by the password that was provided during its generation.

Example of the command to generate CA SMIME wallet:

ocactl generatewallet -type CASMIME

The following steps generate and use the CASMIME wallet:

  1. Stop OCA. Use the command

    $ORACLE_HOME/oca/bin/ocactl stop
    
    
  2. Generate the CA SMIME wallet using above command.

  3. If you have not already done so, go to the Notification page of Configuration Management in the OCA web interface and enable the "Send SMIME E-Mails" option. It uses the generated CA SMIME wallet to sign alerts and notifications.

  4. Start OCA. Use the command

    $ORACLE_HOME/oca/bin/ocactl start
    
    

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

Renewing Critical Wallets

When a certificate is going to expire, renewal will be required. CA, CA SSL, and CASMIME wallets can be renewed using the ocactl 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 OCA'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 SMIME wallet is renewed, the new wallet overwrites the old CA SMIME wallet at $ORACLE_HOME/oca/wallet/email.

Example to renew CA wallet:

ocactl renewcert -type CA

Renewed wallets take effect only after OHS, OCA's OC4J, and OCA are restarted, in that order, as described in the section titled Starting and Stopping Oracle Application Server Certificate Authority in Chapter 3, "Introduction to OCA Administration and Certificate Management".

Changing Passwords

After installation, you can change any of the following passwords: CA, CA SSL, CA SMIME, or DB. With the exception of the database password (DB), all other passwords can be changed even when Oracle Application Server Certificate Authority is in operation. The possibility of active connections to the CA, using the existing DB password, precludes allowing the DB password to be changed until Oracle Application Server Certificate Authority has been stopped.

The changes resulting from executing these commands take effect after the next start of Oracle Application Server Certificate Authority. Each use of ocactl requires the OCA 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 OCA administrator password.

Example to change OCA repository password:

ocactl setpasswd -type DB


Note:

If the CA SSL wallet password is changed, you must restart OHS, OCA's OC4J, and OCA, in that order.


Configuration Operations for OracleAS Certificate Authority

The administrator for OracleAS Certificate Authority 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 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:

Configuring Oracle HTTP Server to Use a Third Party SSL Wallet

When OCA is installed, it is automatically configured in SSL mode. Browsers will warn that this site is not trusted until you import the CA certificate, either through explicit CA import or an additional act of editing the CA entry. To avoid this warning, the OCA administrator can get an SSL certificate for the OCA 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 SSO 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 SSO-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 SSO (single sign-on) to bring up the web server in SSL mode automatically, without asking a human for the wallet password.

To import a wallet from a well-known CA, the administrator can do the following:

  1. Shut down OCA, 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. Import the certificate of the third-party CA that issued the server certificate.

    3. Import your requested server certificate.

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

    See Also:

    The Oracle Application Server 10g Security Guide, particularly the Appendix on Managing PKI Credentials with Oracle Wallet Manager.

  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. Restart OCA, OCA's OC4J, and OHS, in that order.

Revoking a Certificate Authority Certificate

Revoking a CA signing certificate is a very drastic operation, which will make OCA 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 OCA Administrators certificate. It can only be used when OCA services are not running. Revoking a root certificate authority certificate is required before installing a new CA signing for ongoing OCA 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 OCA repository.

Then use revokecert to revoke the old CA 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 OCA 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 OCA:

  1. Stop OCA. Use the command

    $ORACLE_HOME/oca/bin/ocactl stop
    
    
  2. Revoke the CA wallet using the above command.

  3. Regenerate the CA SSL wallet.

  4. Start OCA. Use the command

    $ORACLE_HOME/oca/bin/ocactl start
    
    

Revoking the OCA 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 OCA 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 command-line tool ocactl, which requires the OCA Administrator password.

Once the OCA 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 Oracle Application Server Certificate Authority web page and fills in the OCA Admin forms.

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 OCA. Use the command

    $ORACLE_HOME/oca/bin/ocactl stop
    
    
  2. Stop OCA's OC$4J. Use the following command in ORACLE_HOME:

    $ORACLE_HOME/opmn/bin/opmnctl startproc type=oc4j instancename=oca 
    
    
  3. Revoke the Web Administrator's certificate using the above command.

  4. Start OCA. Use the command

    $ORACLE_HOME/oca/bin/ocactl start
    
    

Configuring National Language Support (NLS) for OCA Screens

The administrative and user screens for OracleAS Certificate Authority can appear in the language of the client or of the server, if certain prerequisites are met, as follows:

  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. 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 OCA, 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' supports NLS depending on the server locale. If the server locale is anything other than the OCA supported languages, display is in English.


    Notes:

    • In every locale, ocactl commands are in English.

    • Informational, error messages, etc. are displayed in the language of the server locale.

    • The CA and CA SSL certificate DN's must not contain multibyte characters. If the CA's DN contains multibyte characters, the install will fail (Bug: 2991110).


Customization Support

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

  1. The Welcome screen

    Text description of welcomenetscape.gif follows.

    Text description of the illustration welcomenetscape.gif

  2. The Enrollment screen

    Text description of scndssontscpaftrwlcm.gif follows.

    Text description of the illustration scndssontscpaftrwlcm.gif

  3. The Import Certificate screen

    Text description of ssoapprvdcertinf90103.gif follows.

    Text description of the illustration ssoapprvdcertinf90103.gif

    See:

    Single Sign-on (SSO) and OracleAS Certificate Authority (OCA)in Chapter 3, "Introduction to OCA Administration and Certificate Management"

Although OCA will by default render the existing screens without customization, the OCA 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 OCA 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 directory. The administrator controls the look and feel of this content.

If any customization screen HTML file exists with nonzero size, its content is used instead of the default screen.


Note:

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


Table 6-1 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 OCA lines reading
"Welcome to OracleAS Certificate Authority" and "To get a certificate Click Here"

For a footer: below 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: below the lines at the bottom, reading
"Key Size" and "SKI".

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

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

Import Certificate Screen

For a header: between the OCA lines reading
"View Certificate" and "Certificate details"

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

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

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

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.

Log or Trace OCA Actions for Oracle Application Server Certificate Authority

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

Table 6-2 Storage Locations for OCA Log and Trace Data  
Type of Data Storage Form Location

Log

OCA repository

OCA repository

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 OCA -state ON

    Enables storing log messages in the OCA repository.

  2. ocactl set -type TRACE -mode OCA -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.

Clearing Log or Trace Information for OracleAS Certificate Authority

The ocactl command line tool enables removal of existing log or trace storage at the administrator's choice. The OCA log will be stored in the OCA repository, and the OCA 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 log or storage. The files oca.trc, admin.trc and admin.log can be removed from the file system using OS remove commands.

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 OCA repository

  4. ocactl clear -type TRACE -mode OCA

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

Changing the Infrastructure Services That OCA Uses

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

OCA is installed as part of the OracleAS Identity Management (IM) infrastructure and uses the services of OID, SSO, and a metadata repository. If any of these components is replaced or restored, OCA can be configured to use these new services. can either use existing versions of these three components or work with a new OID, SSO and metadata repository.

Two types of infrastructure change are supported by OracleAS:

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

Changing Identity Management (IM) Services (SSO/OID) Used by OCA

After installation of a new SSO or OID, changing OCA's IM Services requires two steps:

OracleAS provides scripts to migrate data from one IM instance to another, assuming that a new IM (SSO/OID) has been installed. However, you cannot use the Change Identity Management Wizard on the Infrastructure page of the Application Server Control to OCA because OCA itself is an infrastructure component. So OCA supports changing OCA's IM Services by providing the "changesecurity" command from the OCA administration command line tool ocactl.

See Also:

The following steps establish the new IM services for OCA:

  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 OCA (Machine 1), bring down OCA, OCA'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, i.e., Machine 2.

  6. On Machine 1, execute the following command:

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

    This command updates the file oca.conf at $ORACLE_HOME/oca/conf to point to the new IM Services machine (Machine 2) and port number ("portno"), and registers OCA with the new SSO (Machine 2).

Changing Metadata Repository (MR) Services Used by OCA

Changing OCA's Metadata Services also requires two steps:

OCA provides scripts to migrate OCA data from one MR to another. Please refer to the Export Utility and Import Utility sections below for more details on the migration scripts.

The Change Metadata Repository Wizard on the Infrastructure page of the Application Server Control is not available for OCA because OCA is an infrastructure component. To change Metadata Services, OCA provides the following command from the OCA administration command line tool:

changeschema -host hostname -service service 

This command (used in step 9 below) changes the password for the new OCA schema used in the new MR to be the old password stored in the old OCA schema's password store. It also updates $ORACLE_HOME/oca/conf/oca.conf with the new MR host name and service.

The following steps establish the new metadata services for OCA:

  1. Install OCA and metadata repository on Machine 1.

  2. Install metadata repository on another machine (Machine 2).

  3. Stop OCA, OCA's OC4J, and OHS on Machine 1. Use these commands:

    $ORACLE_HOME/oca/bin/ocactl stop
    $ORACLE_HOME/opmn/bin/opmnctl stopproc type=oc4j instancename=oca 
    $ORACLE_HOME/opmn/bin/opmnctl stopproc type=ohs
    
    
  4. Export data from MR of Machine 1 using the 'migoca' script under $ORACLE_HOME/oca/bin. (See Export Utility for more details.)

  5. Transfer the export dump file to Machine 2.

  6. Import data to MR of Machine 2 using the 'migoca' script under $ORACLE_HOME/oca/bin. (See Import Utility for more details.)

  7. Manually edit the entry in Oracle Internet Directory regarding the Metadata Services used by OCA.

  8. Restart OHS, OCA's OC4J, and OCA, in that order, on Machine 1, as follows:

    $ORACLE_HOME/opmn/bin/opmnctl startproc type=ohs
    $ORACLE_HOME/opmn/bin/opmnctl startproc type=oc4j instancename=oca 
    $ORACLE_HOME/oca/bin/ocactl start
    
    
  9. Then execute the following command, where "new" refers to Machine 2:

    ocactl changeschema -host <new-hostname> -service <new-MR-service>
    

Export Utility

This utility, available under $ORACLE_HOME/oca/bin, is used to export OCA data from the source MR, that is, from the specified OCA Server. After the export command is executed, an export dump (migoca.dmp) file is created, which must be transferred to the destination machine.

Syntax for the export command is as follows:

migoca export    -p <system_password>   [-c <connect_string>]  [-d <log_dir>]  
[-f <log_file>] [-df <dump_file_name>] 

where

Table 6-3 Parameters for Export Utility  
Flag and Parameter Meaning or Usage Default Parameter

-p system_password

"system" user password

None

-c connect_string

Net8 Connect string

None

-d log_dir

Log directory name

Current directory

-f log_file

Log file name

migoca.log

-df dump_file_name

Dump file name

migoca.dmp


Note:

After export, the dump file (migoca.dmp) needs to be transferred to the destination machine.


Import Utility

This utility, available under $ORACLE_HOME/oca/bin, is used to import OCA data obtained from the source database to destination MR.

Syntax for the import command is as follows:

migoca import  -po <oca_password> -pp <oraoca_password> -p <system_password>   
[-c <connect_string>] [-d <log_dir>] [-f <log_file>]                               
[-df <dump_file_name>] 

where

Table 6-4 Parameters for Import Utility  
Flag and Parameter Meaning or Usage Default Parameter

-po oca_password

"oca" user password

None

-pp oraoca_password

"oraoca_public" user password

None

-p system_password

"system" user password

None

-c connect_string

Net8 Connect string

None

-d log_dir

Log directory name

Current directory

-f log_file

Log file name

migoca.log

-df dump_file_name

Dump file name

migoca.dmp


Note:

The existing data in the target database will be replaced with the data from the source MR. After this source and destination MR will be in sync.


Where OCA Connection Information Is Stored and Displayed

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

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

OracleAS Certificate Authority and High-Availability Features

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

Oracle Application Server 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:

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 OracleAS 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 OCA/OracleAS software and database reside. If the hardware for OracleAS 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 OCA/OracleAS processes to effect transparent failover. Clients continue to talk to the same logical host as before, with minimal service disruption. Oracle Application Server Certificate Authority, too, must be restarted with the ocactl start command, after HTTP server and OC4J are brought up.

See Also:

Oracle Application Server 10g High Availability Guide.

OracleAS Certificate Authority Deployment Using Real Application Clusters

Oracle Real Application Clusters provides a robust cluster architecture for the OracleAS Infrastructure, offering a more transparent high availability solution than cold failover clusters. Because all nodes in the Real Application Clusters solution are active, failover from one node to another is quick, requiring no manual intervention. This active-active set up also provides scalability to the Infrastructure deployed on it. A standard configuration is illustrated below.

The database files are installed in shared storage accessible by all nodes. The database instances open the database concurrently for read/write operations. Infrastructure configuration files are not in the database but in the file systems local to each node, containing identical but node-specific configuration information. More than two nodes can exist in the cluster and all of them actively accept requests from the middle tier.

The cluster is front-ended by a load balancer appliance, which Oracle recommends be deployed in a fault-tolerant mode to maintain availability in case of load balancer failure. This load balancer directs non-Oracle Net traffic, such as HTTP, HTTPS, and LDAP (directory) requests, from the middle tier to the Infrastructure. The configuration of the load balancer is set to direct requests from the middle tier to any of the active Infrastructure nodes.

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

See Also:

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

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 OracleAS backup recovery tool aids in backing up and recovering the OracleAS 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 OracleAS backup/recovery tool, and component-wise backup and recovery, please refer to the backup/recovery documentation in the Oracle Application Server 10g 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 above.

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

Table 6-5 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 crash 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 OracleAS 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 Oracle Application Server Certificate Authority (OCA) 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 6-6 Backup/Recovery Tools  

Tool Name

Functionality

Cold Backup/Recovery

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

Partial Online (hot) Backup/Recovery

Refers to restoring the OracleAS 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 OracleAS infrastructure configuration files taken from an online backup

Since OCA uses the Oracle Database as its primary repository, the OCA information stored in that database will be automatically backed up when that database is backed up. Similarly, OCA relies on Oracle Internet Directory (OID) for publishing certificates and for certain SSO operations. The three books named above provide the detailed information supporting all related backup and recovery operations.

In addition to information stored in the database and directory, Oracle Application Server 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 OCA is installed):

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 OCA may be Sub CAs or independent CAs that trust each other.

By default, when an Oracle Application Server Certificate Authority (OCA) instance is installed in a particular machine, an entry is placed into Oracle Internet Directory representing that installed OCA 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 OCA, 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 OCA.

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 OCA, 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 OCA instance so that it can only publish to a particular subscriber realm. For example, the UK OCA could be restricted to publishing only to the UK subscriber realm. If this is done, then a certificate issued by the UK OCA to a US user could not be published, because the user's standard realm would not be accessible to the UK OCA.

To restrict an OCA 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 OCA 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 5, "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 7 of the example in that chapter's section entitled "An Example of a Custom Policy Plug-in":

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


Go to previous page Go to next page
Oracle
Copyright © 2002, 2003 Oracle Corporation.

All Rights Reserved.
Go To Documentation Library
Home
Go To Product List
Solution Area
Go To Table Of Contents
Contents
Go To Index
Index