|
Oracle® Application Server Certificate Authority Administrator's Guide
10g Release 2 (10.1.2) Part No. B14080-01 |
|
 Previous |
 Next |
|
Oracle® Application Server Certificate Authority Administrator's Guide
10g Release 2 (10.1.2) Part No. B14080-01 |
|
|
Previous |
Next |
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:
Log or Trace OCA Actions for Oracle Application Server Certificate Authority
OracleAS Certificate Authority and High-Availability Features
OracleAS Certificate Authority Backup and Recovery Considerations
Replacing the CA and Deinstalling 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:
Installation of Oracle Application Server 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 OCA 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 request 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
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".
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 Signing wallet being regenerated, or a new Sub CA certificate being installed.
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 OracleAS Single Sign-On Server 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 OCA instance in OPMN will use this wallet for SSL server authentication. (After CA SSL/OracleAS Single Sign-On Server wallet generation, the OPMN stopall and startall commands are required.)
The CA SMIME wallet enables the Oracle Application Server 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 OCA Administration pages. Once generated, this wallet resides in the OCA database repository.
If this SMIME wallet is compromised or corrupted, or when the CA signing wallet is regenerated, you must regenerate the CA SMIME 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.
Example of the command to generate CA SMIME wallet:
ocactl generatewallet -type CASMIME
The following steps generate and use the CA SMIME wallet:
Stop OCA. Use the command
$ORACLE_HOME/oca/bin/ocactl stop
Generate the CA SMIME wallet using the command
ocactl generatewallet -type CASMIME
After generating the wallet, 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.
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.
When a certificate is going to expire, renewal will be required. CA Signing, CA SSL, and CA SMIME 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 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 in the database repository.
Example to renew CA signing wallet:
ocactl renewcert -type CA
A renewed CA SMIME wallet can be used simply by restarting OCA. The renewed CA and CA SSL 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".
After installation, you can change any of the following passwords: CA, CA SSL, CA SMIME, or DB, by stopping OCA, issuing the ocactl setpasswd command, and then restarting OCA.
|
Note: The OCA 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, e.g., by using sqlplus, because OCA will stop working if that is done.
|
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, except in the default install scenario wherein OCA uses cwallet.sso: in that case, OHS need not be restarted. |
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 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:
When OCA 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 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 OracleAS Single Sign-On Server 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 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, the administrator can do the following:
Shut down OCA, OCA's OC4J, and OHS.
Using Oracle Wallet Manager, create a complete SSL server wallet:
Request an SSL certificate.
Install the certificate of the third-party CA that issued the server certificate.
Install your requested server certificate.
Using OWM, import the current OCA CA's certificate as a trust point into this wallet.
|
See Also: Oracle Advanced Security Administrator's Guide |
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.
Copy the wallet created from the third-party CA (in PKCS#12 format) to $ORACLE_HOME/oca/wallet/ssl/ewallet.p12.
Start OCA, OCA's OC4J, and OHS, in that order.
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 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 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:
Stop OCA. Use the command
$ORACLE_HOME/oca/bin/ocactl stop
Revoke the CA signing wallet using the above command.
Regenerate the CA SSL wallet.
Start OCA. Use the following command:
$ORACLE_HOME/oca/bin/ocactl start
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 server command-line tool opmnctl and the OCA 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 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:
Stop OCA. Use the command
$ORACLE_HOME/oca/bin/ocactl stop
Revoke the Web Administrator's certificate using the command
ocactl revokecert -type WEBADMIN -reason KEY_COMPROMISE
Start OCA. Use the following command:
$ORACLE_HOME/oca/bin/ocactl start
|
Note: Having revoked the webadmin certificate, you cannot use it to log into the web interface for OCA. You must remove it from the browser certificate store before opening the OCA web interface. Then you will be able to display that interface and enroll anew as the administrator. |
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:
The Database Character Set must be UTF8.
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 locale.) 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.
The practice statement is rendered in the locale in which the Administrator edits the practice statement irrespective of the client locale.
'ocactl' supports NLS depending on the server locale. If the server locale is anything other than the OCA supported languages, display is in English.
In every locale, the actual ocactl commands are themselves in English.
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 OCA 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.
|
Note: If the client locale is Arabic, then screens are rendered in English. However, the order of rendering is right to left. (Bug numbers 3382624 & 3384940.) |
You can enhance the performance of your OCA instance by setting several customizable parameters for the database, Single Sign-On, and memory.
Table 6-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 OCA 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 per process
Number of database connections used by other Oracle products
|
See Also: See the discussion of PROCESSES in Oracle10i Database Administrator's Guide. |
For optimum performance, ensure that the Single Sign-On database pool size is not less than the OCA database pool size.
In OCA, the minimum database pool size is hardcoded as 3, so for OCA 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.
|
See Also: See "policy.properties" in Oracle Application Server Single Sign-On Administrator's Guide. |
OCA 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.
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 per 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. |
OCA enables you to customize the SSO-OCA interface by specifying your own headers and footers for the following three provisioning pages:
The Welcome screen
The Enrollment screen
The Install Certificate screen
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. 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.
|
Notes: After making changes to any of these HTML files, the administrator must restart OCA to cause those changes to be used. Please note that OCA 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 6-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 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 |
| Install 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 |
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-3 Storage Locations for OCA Log and Trace Data
The set command has the following format:
ocactl set -type {LOG | TRACE} -mode {OCA|ADMIN} -state {ON|OFF}
Examples:
ocactl set -type LOG -mode OCA -state ON
Enables storing log messages in the OCA repository.
ocactl set -type TRACE -mode OCA -state ON
Enables storing trace messages in the oca.trc file.
ocactl set -type LOG -mode ADMIN -state ON
Enables storing log messages in the admin.log file.
ocactl set -type TRACE -mode ADMIN -state ON
Enables storing trace messages in the admin.trc file.
ocactl set -type TRACE -state OFF
Turns off tracing: no trace data are stored.
The ocactl administrative 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 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:
ocactl clear -type LOG -mode ADMIN
Removes the Admin log file admin.log from $ORACLE_HOME/oca/logs
ocactl clear -type TRACE -mode ADMIN
Removes the Admin trace file admin.trc from $ORACLE_HOME/oca/logs
ocactl clear -type LOG -mode OCA
Removes log messages in the OCA repository
ocactl clear -type TRACE -mode OCA
Removes the OCA trace file oca.trc from $ORACLE_HOME/oca/logs
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:
Restore operations after a backup
Configuration changes to LDAP (directory) or the Oracle Database
Migration from a pilot scenario to a production environment
OCA is installed as part of the OracleAS Identity Management (IM) infrastructure and uses the services of Oracle Internet Directory, OracleAS Single Sign-On Server, 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 Oracle Internet Directory, OracleAS Single Sign-On Server and metadata repository.
Two types of infrastructure change are supported by OracleAS:
The following section describes the display of data regarding these services:
After installation of a new OracleAS Single Sign-On Server or Oracle Internet Directory, changing OCA's IM Services requires two steps:
Installing a new IM and migrating the existing data.
Configuring OCA 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 Server/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 OCA because OCA itself is an infrastructure component. So OCA supports changing OCA's IM Services by providing the "changesecurity" command from the OCA administrative command line tool ocactl.
|
See Also:
|
The following steps establish the new IM services for OCA:
Install Identity Management and Metadata Repository on Machine 1.
Install Identity Management on Machine 2.
Migrate IM data from Machine 1 to Machine 2 using the scripts provided by OracleAS.
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
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.
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 OCA 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 Server 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. |
Changing OCA'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.
Information defining connections to the OCA repository and directory (used for publishing certificates) is stored in Oracle Internet Directory. This connection information is originally written to Oracle Internet Directory when OracleAS is installed, at which time it is also fetched from Oracle Internet Directory 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.
|
See Also: updateconnection in Table A-2, "Operations and Parameters of the OracleAS Certificate Authority (OCA) ocactl Tool" of Appendix A, "Command-Line Administration". |
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.
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
OracleAS Certificate Authority Deployment Using Real Application Clusters
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.
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.
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 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. |
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:
|
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-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 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-5 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 for publishing certificates and for certain OracleAS Single Sign-On Server 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, 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):
$ORACLE_HOME/oca/policy/*
$ORACLE_HOME/oca/logs/admin.*
$ORACLE_HOME/oca/conf/ocaplugin.xml
$ORACLE_HOME/oca/wallet/ldap/ewallet.p12
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 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.
In the rare and drastic event that the root CA needs to be replaced, perhaps because its private key was somehow compromised, OCA 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.
