|
Oracle® Application Server Certificate Authority Administrator's Guide
10g Release 2 (10.1.2) B14080-02 |
|
 Previous |
 Next |
|
Oracle® Application Server Certificate Authority Administrator's Guide
10g Release 2 (10.1.2) B14080-02 |
|
|
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:
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. 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:
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".
This section explains how to regenerate the CA SSL and CA S/MIME wallets, respectively.
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.)
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:
Go to Configuration Management -> Notification. Select the Send SMIME E-Mails option.
Stop OracleAS Certificate Authority using the command
$ORACLE_HOME/oca/bin/ocactl stop
Generate the CA S/MIME wallet using the command
ocactl generatewallet -type CASMIME
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.
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".
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.
|
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. |
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:
Configuring Oracle HTTP Server to Use a Third Party SSL Wallet
Revoking the OracleAS Certificate Authority Web Administrator's Certificate
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:
Shut down OracleAS Certificate Authority, 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 OracleAS Certificate Authority 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 OHS, OracleAS Certificate Authority's OC4J, and OracleAS Certificate Authority, in that order.
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:
Stop OracleAS Certificate Authority. Use the command
$ORACLE_HOME/oca/bin/ocactl stop
Revoke the CA signing wallet using the command shown earlier.
Regenerate the CA SSL wallet.
Start OracleAS Certificate Authority. 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 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:
Stop OracleAS Certificate Authority. Use the command
$ORACLE_HOME/oca/bin/ocactl stop
Revoke the Web Administrator's certificate using the command
ocactl revokecert -type WEBADMIN -reason <REASON>
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. |
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 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.
The practice statement is rendered in the locale in which the Administrator edits the practice statement irrespective of the client locale.
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.
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 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.
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:
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). |
|
|
Make the database pool scheme |
|
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. |
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.
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.
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. |
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:
The Welcome screen
The Enrollment screen
The Install Certificate screen
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" |
|
|
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". |
|
|
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. |
|
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 |
||
|
ADMIN Log |
File: admin.log |
$ORACLE_HOME/oca/logs |
|
ADMIN Trace |
$ORACLE_HOME/oca/logs |
The set command has the following format:
ocactl set -type {LOG | TRACE} -mode {OCA|ADMIN} -state {ON|OFF}
Examples:
ocactl set -type LOG -mode OracleAS Certificate Authority -state ON
Enables storing log messages in the OracleAS Certificate Authority repository.
ocactl set -type TRACE -mode OracleAS Certificate Authority -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 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:
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 OracleAS Certificate Authority repository
ocactl clear -type TRACE -mode OCA
Removes the OracleAS Certificate Authority 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
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:
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:
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 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
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.
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. |
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.
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.
|
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.
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:
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 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.
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. |
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:
|
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):
$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 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.
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.
