Oracle® Application Server Certificate Authority Administrator's Guide
10g Release 2 (10.1.2) Part No. B14080-01 |
|
![]() Previous |
![]() Next |
This chapter describes a number of issues that can arise in the installation or administration of Oracle Application Server Certificate Authority.
The following sections of this Appendix describe how to deal with or work around those issues for the current release:
1. Prerequisite Issues and Warnings
a. Issue: Browser issues a warning if the CA SSL Server's CN does not match the machine name.
b. Issue: Browsers use only the first (rightmost) CN component
Certain issues need to be addressed before further progress in using OCA can go forward, and so are termed "prerequisite".
For Windows client machines, this operation requires NT to have Service pack 5 or above.
Visit Microsoft's website and download the necessary upgrades for your configuration
ocactl
to change any password related to OCA.
If you first log in to OCA as a normal user via SSL, then trying to go to Certificate Management causes a JAZN error. The reason is that you are not recognized as the web administrator unless you log in as such, even though you are enrolled as the web admin. The SSL session established between OCA and you as a non-admin user remains active; your enrollment does not change your SSL session.
Enroll as web admin,
Exit your browser, and
Login as web admin, by choosing your web admin certificate for authentication.
ocactl
is used to change any of these passwords, OCA will stop working.
ocactl
tool, then OCA will not start up. This circumstance also prevents you from resetting the database password with ocactl
. Instead, what you must do is log in to the database as any DBA, such as SYS or SYSTEM, etc., and issue the command
alter user oca identified by <OCA_admin_password>
If the DB password in the password store has never been changed from the default (which happens to be <OCA-admin-password> as established during installation), then regaining access to the database (after someone changed the password originally recognized by the database schema) can be accomplished by this command:
"alter user oca identified by <OCA-admin-password>"
This resetting of the database schema password to the <OCA-admin-password> causes it to match what is in the password store as the database schema password.
If the DB password in the password store has been changed and the OCA administrator does know what it is (for example, <new_DB_pswd_in_store>, then if the schema password is changed (by a database admin, perhaps), the OCA administrator can restore database accessibility by "alter user oca identified by <new_DB_pswd_in_store>".
If the DB password in the password store has been changed and the OCA administrator does not know (or remember) what it is, changing the schema password will prevent OCA operations. Here's why: database access will not be granted unless the password offered by OCA from the password store matches the current schema password. If the schema password is changed, then either that password or the DB password in the password store must be changed so that they again match. Since the DB password in the password store is unknown, the administrator cannot supply it in an "alter user" command. Nor can she change the DB password in the password store, because ocactl
requires the current DB password before allowing it to be changed. So no recovery is possible. The unknown DB password remains unchangeable.
These scenarios all rely on the OCA administrator retaining the privileges necessary to invoke "alter user oca".
Some symptoms may arise only when you are using a certain type or level of browser. This section describes the presently known browser-related issues.
The machine name is likely used widely and inconvenient to change. Therefore, the CN for the CA SSL Server must be made identical to that machine name, requiring a new certificate.
When a DN has more than one CN component, the browser names the certificate for that DN using only its first CN component (from the right). This certificate is listed in the popup for SSL Mutual Authentication as "users's", in both MicroSoft's Internet Explorer and Netscape (4.7x and 7.x). (DN fields must be separated by a comma.)
The following issues affect only Netscape clients.
Netscape 4.79 shows only the latest certificate in this popup window.
Alter the order of certificates so that the one that you want to use is the last certificate on the list.
Netscape 4.7x versions do not automatically trust the CA certificate; they require the user to state explicitly that the CA certificate is to be trusted. Until that is done, Netscape does not assume it is trusted.
Using Netscape 4.7x browsers, users can in some circumstances receive this message: "The Security library has encountered an improperly formatted DER-encoded message". Its meaning is that when the certificate was issued, the Distinguished Name (DN) for that certificate included non-printable or other special characters, causing the issuer to use a special set of characters that Netscape cannot handle.
Re-issue the server certificate using only allowed printable characters in the DN, that is, using only combinations of lowercase letters, uppercase letters, the space character, the numerals 0 through 9, or the following eleven special characters ( + ' , - . / : = ? ). Note that underscore is not included in this set: (- - - - a..z, A..Z, 0..9, ( + ' , - . / : = ? ) - - - -)
If the time zone of the client is behind that of the server, there can be a period of time in which Netscape might issue a 'certificate is expired' warning. The reason is that the CASSL certificate is not yet valid in the user's time zone.
The problem should resolve itself in a relatively short period of time, depending on the time zone differential.
Netscape 7.x browser users can face this anomaly: If the user has two SSL client certificates, one from the CA and another from a SubCA of that CA, then during client authentication to the SubCA, both certificates are listed. Select the certificate appropriate to the CA in use for this SSL site.
The following issues affect only Internet Explorer clients.
The IE button Import... does show the CRL for viewing, but it does not actually install the CRL into the browser.
Use the IE menus to choose the following command sequence: Tools -> Internet Options -> Content -> Certificates -> Import
In User Pages -> Manual Authentication -> Save CA certificate -> Advanced, clicking Help opens a new window that may display an error message saying that the page contains both secure and non-secure information. This is not a security breach.
When online help is opened while using OCA, IE will display a security alert. It appears that the alert is generated whenever an https URL is in use and then a second https URL is invoked.
Sometimes after generating many certificate requests using Internet Explorer, one can get an additional dialog box with such a message.
The following messages or issues are particularly relevant to networks.
The following message:
"Forbidden
You don't have permission to access /oca/sso/ssoInitServlet on this server"
arises from an IP address check if a proxy server with multiple IP addresses is used between the browser and the OracleAS Single Sign-On server.
When the access is through an intranet, the browser should be configured not to use a proxy, following the instructions in the browser documentation.
If this is not the case, or if such a change does not solve the problem, then the following change is needed on the server side: the value of the directive OssoIpCheck in the OracleAS Single Sign-On configuration file must be set to "off". To do so, navigate to the file located at
$ORACLE_HOME/Apache/Apache/conf/mod_osso.conf
and edit the line containing OssoIpCheck to say "OssoIpCheck off ".
After modifying the configuration file, you must restart the Oracle HTTP Server by executing the following stop and start commands:
$ORACLE_HOME/opmn/bin/opmnctl stopproc type=ohs $ORACLE_HOME/opmn/bin/opmnctl startproc type=ohs
This message can arise when a browser requires re-authentication because an operation was attempted with Oracle Application Server Certificate Authority after some period of inactivity.
You need to re-authenticate yourself to OCA by going to the Certificate Management tab and, when asked, choosing the Web Admin Certificate.
These symptoms can arise when a configuration change has altered the connection strings that OCA uses to connect to its repository or to Oracle Internet Directory (for publishing certificates). Changes can include altered ports or RAC nodes, for example. The messages may say "Cannot Establish Connection" or "Internal Server Error".
You need to have OCA re-acquire the new connection strings, by issuing the following ocactl command:
ocactl updateconnection
When that command completes, it has updated the configuration file at $ORACLE_HOME/oca/conf/oca.conf.
After using this command, you must restart OCA by issuing the following commands:
The following issues relate primarily to certificates or certificate management.
An attempt to install a user certificate does not in fact do so.
All CA/Sub CA certificates must contain the O (Organization) component in their Subject DN. The components mandatory in the CA/Sub CA DN are C, O, and CN each separated from the next by a comma.
When installing Oracle Application Server Certificate Authority, or regenerating the Root CA, users should input a DN that includes at least country, organization, and common name ("C, O, CN").
When installing a Sub CA, ensure that the DN of the CA signing certificate has O (organization) RDN in its subject DN.
Attempts to access or use the Certificate Management facility fail.
Access to Certificate Management requires that your browser has imported a valid Web Administrator certificate. Thus you must apply for and receive such a certificate before clicking Certificate Management. You do so in the Administration Setup tab, by clicking the button labeled Web Administrator Enrollment ... .
An Oracle Application Server Certificate Authority administrator may wish to do certificate management tasks from any of multiple machines. However, his Web Administrator certificate is contained in the browser of the machine he used when originally authenticating himself to be the OCA Web Administrator.
To switch from one machine to another and maintain the ability to do certificate management tasks, you need to export the certificate from the previous browser and import it into the new browser, as follows:
Exporting the certificate on Netscape: Choose Security->Certificates->Yours->choose the Web Admin Cert ->Export
Importing the certificate on Netscape: Choose Security->Certificates->Yours->Import Certificate.
Exporting the certificate on Internet Explorer: Choose Internet options ->Content->Certificates->Personal-><choose your Web Admin Cert> ->Export
Importing the certificate on Internet Explorer: Choose Internet options->Content->Certificates->Personal->Import
Some issues relate primarily to Single Sign-on capabilities.
These certificates do not show the common name or DN. They are distinguishable only by having different certificate serial numbers.
Click on "View" to check the certificate serial number, and pick the certificate identified by the serial number you wish to use.
In OracleAS Single Sign-On, you request a certificate by clicking "Submit" in the popup window. Since there is no message to wait and no visible indication of progress, users sometimes click "Submit" again, causing this error.
Try again, being sure to click "Submit" only once and to wait until the certificate is returned.
After logging in to OracleAS Single Sign-On by name and password, but then changing authentication by choosing SSL, a known IE bug gives the "Page cannot be displayed error."
Try to reload the page. If that isn't helping, exit from the current browser session, and then re-access Oracle Application Server Certificate Authority to try anew.
This warning occurs due to switching from https to http. No action is needed.
After using the Mozilla browser to log in to Oracle Application Server Single Sign-On, get a certificate, and import it, a user might still not see this just-imported certificate in the client authentication window.
If the user did not include "Authentication" among the intended Usages specified when requesting the certificate, then that certificate will not appear in the client authentication box for authentication use.
To confirm the chosen usages, search for the certificate by its the serial number and see its details. If the Usages do not show Client Authentication, then this certificate cannot be used for SSL authentication.
The solution then is to request a new certificate and ensuring that Authentication is specified as one of the Usages for it.
Another reason the certificate might not appear is that the CASSL certificate is for some reason unusable. In this case, the administrator must replace it:
The following issue relates to making recovery possible after a failure.
Errors and unpredicted events can threaten the continuity of OCA operations.
Take a backup of the OCA repository periodically. Oracle Application Server commandline tools such as "export" can be used to save the OCA repository to a file. It can then be restored to the "same" database using the "import" tool.
The following miscellaneous issues are general in nature.
Sometimes such delays can occur, possibly after Oracle Application Server Certificate Authority has been in operation for a substantial period.
Restart OCA's OC4J instance, which will return you to faster operations.
In some Windows environments, when you select the certificate for SMIME signing in Outlook Express, there is no certificate listed. The reason is that there is an installed version of Microsoft Outlook.
You will need to use Microsoft Outlook and not Outlook Express.
You can find more solutions on Oracle MetaLink, http://metalink.oracle.com
. If you do not find a solution for your problem, log a service request.
See Also: Oracle Application Server Release Notes, available on the Oracle Technology Network: |