Oracle® Application Server Certificate Authority Administrator's Guide 10g (9.0.4) Part Number B10663-01 |
|
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:
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, 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". |
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 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.
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:
$ORACLE_HOME/oca/bin/ocactl stop
$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, 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".
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
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:
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:
The Oracle Application Server 10g Security Guide, particularly the Appendix on Managing PKI Credentials with Oracle Wallet Manager.
See Also:
Now OCA-issued certificates can be trusted as client certificates against this wallet as the CA SSL server's certificate.
convertwallet -format SSO
.
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:
$ORACLE_HOME/oca/bin/ocactl stop
$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 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:
$ORACLE_HOME/oca/bin/ocactl stop
ORACLE_HOME
:
$ORACLE_HOME/opmn/bin/opmnctl startproc type=oc4j instancename=oca
$ORACLE_HOME/oca/bin/ocactl start
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:
OCA enables you to customize the SSO-OCA interface by specifying your own headers and footers for the following three provisioning pages:
Text description of the illustration scndssontscpaftrwlcm.gif
Text description of the illustration ssoapprvdcertinf90103.gif
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.
Screen Name | Position of Replaceable Text | Files to Contain Replaceable TextFoot 1 |
---|---|---|
Welcome Screen |
For a header: between the OCA lines reading
For a footer: below the line reading |
$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 |
$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
For a footer: between the OCA lines reading |
$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. |
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.
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
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:
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 (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:
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:
$ORACLE_HOME/oca/bin/ocactl stop $ORACLE_HOME/opmn/bin/opmnctl stopall
$ORACLE_HOME/config
directory point to the new IM, i.e., Machine 2.
$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 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:
$ORACLE_HOME/oca/bin/ocactl stop $ORACLE_HOME/opmn/bin/opmnctl stopproc type=oc4j instancename=oca $ORACLE_HOME/opmn/bin/opmnctl stopproc type=ohs
$ORACLE_HOME/oca/bin
. (See Export Utility for more details.)
$ORACLE_HOME/oca/bin
. (See Import Utility for more details.)
$ORACLE_HOME/opmn/bin/opmnctl startproc type=ohs $ORACLE_HOME/opmn/bin/opmnctl startproc type=oc4j instancename=oca $ORACLE_HOME/oca/bin/ocactl start
ocactl changeschema
-host <new-hostname> -service <new-MR-service>
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
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
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.
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:
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. 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. |
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:
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:
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):
$ORACLE_HOME/oca/conf/oca.conf
$ORACLE_HOME/oca/pwdstore/ocmpassword.p12
$ORACLE_HOME/oca/wallet/ssl/ewallet.p12
$ORACLE_HOME/oca/wallet/ssl/cwallet.sso
$ORACLE_HOME/Apache/Apache/conf/httpd.conf
$ORACLE_HOME/Apache/Apache/conf/ocm_apache.conf
$ORACLE_HOME/Apache/Apache/conf/osso/oca/osso.conf
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.
|
![]() Copyright © 2002, 2003 Oracle Corporation. All Rights Reserved. |
|