Skip Headers
Oracle® Application Server Certificate Authority Administrator's Guide
10g Release 2 (10.1.2)
B14080-02
  Go To Documentation Library
Home
Go To Product List
Solution Area
Go To Table Of Contents
Contents
Go To Index
Index

Previous
Previous
Next
Next
 

3 OracleAS Certificate Authority Deployment Guidelines

This chapter helps you understand CA deployment issues and gather the information you need for a smooth, effective deployment. Addressing these issues requires a sound understanding of creating, securing, transmitting, and guaranteeing the integrity of certificates. This chapter describes key capabilities and helps you plan your OracleAS Certificate Authority deployment to meet your site's certificate security requirements. It contains these sections:

3.1 Road Map for Setting up a Certificate Authority

Oracle Application Server Certificate Authority is a trusted entity that provides a secure infrastructure for the use of digital certificates. Certificates find many diverse applications, for example:

As the administrator tasked with deploying OracleAS Certificate Authority for these and other applications, you must ensure that it is deployed and managed in a manner that enables it to be a trusted entity for your site's digital transactions.

You must have a sound understanding of the following areas:

3.2 Certificate Requirements and Policies

You must plan the following components of your OracleAS Certificate Authority deployment to effectively meet your organization's certificate needs:

3.2.1 Define Certificate Requirements and Properties

In the initial planning stages, you must consider the certificate life cycle and the types of certificates to use, taking into account the requirements of your user base. This section describes:

3.2.1.1 Certificate Provisioning

OracleAS Certificate Authority can provision user certificates in manual or automatic mode:

  • Manual provisioning, which is the conventional means for providing certificates, dictates that the CA administrator approve certificate requests manually. OracleAS Certificate Authority can enforce a manual approval process, turning off Single Sign-on and SSL provisioning modes.

    This approach is suitable for organizations that need to be conservative when issuing certificates, and when the volume of requests is not too large.

  • For automatic provisioning, OracleAS Certificate Authority provides a choice of OracleAS Single Sign-On and SSL mechanisms:

    • A user authenticated to OracleAS Single Sign-On, and provisioned in Oracle Internet Directory, can request a digital certificate from OracleAS Certificate Authority by providing a username and password, or other configured single sign-on authentication mechanism

    • An existing certificate can authenticate the user with SSL and allow OracleAS Certificate Authority to automatically issue a new certificate

    Benefits of automatic provisioning include reduced costs and delays compared to the manual approach. Automatic provisioning is recommended if you have already deployed an identity management solution or a centralized directory.

For details, see "Automatic or Manual Provisioning of Certificates" in Chapter 2.

3.2.1.2 Certificate Types

As shown in Table 3-1, certificate types depend on the user's role in the organization, whether the certificate consumer is a client or server, and the intended applications:

Table 3-1 Certificate Types

Client Certificate Server Certificate Description

Authentication

Authentication

Enables secure identification when requesting or providing access or services, such as when logging into an enterprise portal. (Typically, SSL protocol is used.)

Encryption

Encryption

Enables encrypting and decrypting electronic documents and e-mail.

Signing

Signing

Provides electronic documents including e-mail, using S/MIME with verifiable signature and assures non-tampering

Code Signing

Code Signing

Provides verifiable signature for a provider of Java code, Java Script, and other signed files, and assures non-tampering.

NA

CA Signing

Enables requesting subordinate CA certificates


OracleAS Certificate Authority can combine the first three types of certificates to produce certificates that meet multiple needs:

  • Authentication and encryption

  • Authentication and signing

  • Encryption and signing

  • Authentication, encryption, and signing

OracleAS Certificate Authority does not limit how many certificates you issue to each user, and it is quite possible to issue multiple certificates. However, a good rule of thumb is to allow each user to possess only one certificate at a time for each task, consistent with the user's role in the organization.

For example, user A might have one certificate for authentication and another certificate for encryption, whereas user B might only have a single certificate for authentication. (You can enforce this using the UniqueCertificateConstraint policy rule. See Chapter 6.) As another example, if you are initially considering an application like secure login to the enterprise portal, you can just use authentication. However, if you foresee that in future, other applications such as secure e-mail are likely to be added, you might want to add signing and encryption certificates as well.

Common Uses for Certificates

In deciding what types of certificate to use, consider the range of applications for certificates:

  • Certificates for SSL-enabling servers

    Enabling secure SSL communication for web servers is probably the most common use of certificates. It allows client browsers to validate the identity of a web server, and also securely encrypts the data flow between the browser and web server. In this type of usage, scalability is not a critical issue. All approvals are manual and no integration with a directory service is required.

    Consider the following issues when enabling servers for SSL authentication:

    • How clients will get the server's CA certificate to authenticate the server. Options include making OracleAS Certificate Authority a subCA of a recognized CA, or distributing the CA certificate.

    • How the communicating parties will test for certificate revocation. Browsers and servers need to be aware of the relevant certificate revocation lists.

    For more information, see:

  • Certificates for authenticating users

    This common application of certificates can take many forms such as:

    • enabling PKI certificates on OracleAS Single Sign-On to log on to enterprise portals

    • using certificates for Virtual Private Network (VPN) access

    To prepare the user community to work with certificates, users must be trained in how to get their own certificates, and how to renew or revoke their certificates as needed. The certificate holder's responsibility, if the private key is lost or compromised, should be emphasized. If smart cards are to be used for key storage, training is essential to ensure that the cards are used properly and secured at all times.

    For details about user tasks relating to certificates, see Chapter 8, "End-User Interfaceof the Oracle Application Server Certificate Authority".

    Although end users can typically obtain and maintain their own certificates, the administrator is responsible for overall certificate provisioning and life cycle maintenance - for example, maintaining updated CRLs to prevent misuse, and revoking a user certificate after an employee leaves the organization.

  • Certificates for signing e-mail and documents

    Digital signing of documents with PKI certificates provides the twin benefits of data security, and authentication of the document's origin. See Appendix G, "S/MIME with OracleAS Certificate Authority" for details on how to make certificates available to e-mail clients.

  • Certificates for encrypting e-mail

    S/MIME applications, such as Outlook or Netscape mail clients, can use certificates to sign and encrypt e-mail messages. With OracleAS Certificate Authority, separate certificates can be used for signing and encryption, or these functions can be fulfilled with the same certificate, as explained earlier.

    At sites that implement message encryption, users must remember to back up their keys properly, because in the event that the encryption keys are lost, the user can no longer decrypt mails.

3.2.1.3 Certificate Properties

On a day-to-day basis, the OracleAS Certificate Authority administrator examines certificates and certificate requests from end-users (who may be individuals or server entities), renews or revokes certificates, and approves or rejects certificate requests. In order to carry out these duties, the administrator must understand the different certificate configuration options:


Note:

Some configuration decisions are made at OracleAS Certificate Authority installation time, and others are made when a certificate is requested. Some changes can only be effected by regenerating the root certificate.

For details about certificate configuration, see Chapter 4, "Introduction to Administration and Certificate Management".

3.2.1.3.1 Certificate Naming

A distinguished name (DN) is a globally unique identifier representing an individual or other entity's identity, and appears in each certificate. While OracleAS Certificate Authority issues no explicit recommendations for the DN, there are some general rules that should be followed:


Note:

Automatic provisioning eliminates the need for this task, since your directory is already deployed.

  • The DC and EMAIL components must use only printable, ASCII characters. This is true even if your site uses a multibyte character set.

  • The CA's DN must be unique and clearly identify the organization

  • The CN for the CA's DN cannot be the server host name

  • The organization must always be included in the DN, otherwise browsers may be confused

  • For SSL server certificates, the cn component of the DN must be the host name (of the CA, web server, and so on)

For users already provisioned in Oracle Internet Directory, this naming has already been assigned as part of the Oracle Internet Directory provisioning. OracleAS Certificate Authority uses the DN information from Oracle Internet Directory for single sign-on users.


Note:

The DN is the central factor in configuring certificate policy. For details, see Table 6-9, "Predicate Attributes" and the subsequent discussion in Chapter 6 for guidelines on forming DNs.

3.2.1.3.2 Certificate Key Size

In general, you should use the strongest key size possible for your certificates (consistent with performance considerations - larger key sizes lower performance):

  • Key sizes of 512 bits provide the weakest level of encryption

  • Key sizes of 1024 provide stronger encryption and are commonly employed

  • Key sizes of 2048 or better are the best choice for high-security needs.

Recommended key sizes follow:

Intended Usage Recommended Key Size. bytes Comments
CA Certificate >=2048 Must be defined at installation time
Server Certificate >=1024
User Certificate >=1024 A minimum key size of 1024 is recommended

3.2.1.3.3 Certificate Validity Period

Although the end user indicates a validity period when requesting a certificate manually, the administrator can control the certificate's actual validity using the ValidityRule policy rule. With this rule the administrator can specify the minimum validity period (defaults to 90 days), the maximum validity period (defaults to 3650 days), and the default value, the certificate types, and DN's to which the rule applies.

For automatic certificate requests (using OracleAS Single Sign-On Server or SSL authentication), ValidityRule automatically sets the validity period.


See Also:

For more information, see "ValidityRule" in Chapter 6.

3.2.1.3.4 Supported Extensions

Using extensions, an organization can customize a certificate to provide information beyond that which is allowed in the standard certificate fields. There are two types of extensions, critical and non-critical:

  • a certificate-using system (application) must reject the certificate if it encounters a critical extension that it does not recognize, or if the value does not fit the intended use

  • a non-critical extension is processed if possible, but the application may be ignored if it is not recognized or does not fit the intended use

OracleAS Certificate Authority complies with the IETF X.509 V3 certificate format and supports several standard certificate extensions, enabling you to configure certificates to fit their intended applications and to provide more information about the subject. By default, OracleAS Certificate Authority supports:

  • key usage, automatically configured based on the certificate type selected

  • extended key usage, automatically configured based on the certificate type selected

  • CRL distribution, allowing the CRL location to be imbedded in the certificate. This extension is used by the relying applications to find the CRL.

  • the subject alternative name (subjectAltName) extension, which lets the administrator configure the system so that a predefined alternate name identifier appears in certificates issued to SSO-authenticated users. This extension typically contains an e-mail address or alternate user names, and enables e-mail encryption, signing, or use by other applications.

    You can specify that the extension is mandatory, meaning that the certificate request is denied if the alternative name cannot be found in Oracle Internet Directory.


    Note:

    The subject alternative name extension is available for manually authenticated users and SSO certificate requests.

    For more information, see:

3.2.1.3.5 Smart Card Support

When requesting a certificate, the end user can specify that the certificate is to be stored on a cryptographic token or smart card; the card can be removed for separate storage and increased security. OracleAS Certificate Authority supports popular smart card vendors, using the browser to interact with the hardware.

The user chooses the card from a list; only cards that are actually installed on the user's system will be listed.

3.2.1.4 Certificate Renewal and Revocation

A certificate currently in use has a validity period and can no longer be used after it expires. The OracleAS Certificate Authority administrator can configure:

  • whether renewal is allowed

  • the validity period for renewed certificates. For example, the initial certificate could be valid for five years, whereas the renewed certificate might only be valid for two years.

  • a time window, prior to and following the expiration date, during which the certificate can be renewed. If this is not specified, the default window is 10 days before or after the expiration date.

Responsibility for certificate renewal depends on the certificate type:

  • A certificate that was requested by manual approval (a manual certificate) must be renewed by the administrator.

  • A certificate issued using OracleAS Single Sign-On Server or SSL authentication (an automatic certificate) can be renewed by either the certificate owner or the administrator.


See Also:

The following sections provide more information about certificate renewal:

Either the certificate user or the OracleAS Certificate Authority administrator can revoke a certificate. The administrator typically revokes certificates:

  • When the certificate owner no longer has the right or need to use the certificate (for example, due to a change in status)

  • When the certificate owner's private key (either the signing key or the decryption key) has been compromised


See Also:

The following sections provide more information about certificate revocation:

3.2.1.5 Distributing the CA Certificate

To work with OracleAS Certificate Authority, users must be able to trust the CA certificate. This is necessary so users can trust the certificates they receive from an issuing certificate authority, or simply to trust the servers whose certificates, in turn, are issued by the certificate authority.

There are several ways to distribute the CA certificate so users can establish this trust relationship with OracleAS Certificate Authority:

  1. A user can explicitly install the certificate into the browser. See "Configuring Your Browser to Trust OracleAS Certificate Authority" and "Installing a CA Certificate" in Chapter 8.

  2. The CA certificate can be installed in the machine's base image. End users utilizing the installed browser automatically obtain the CA certificate.

  3. You can follow any patching and security update push mechanism to push these changes to the client machines.

  4. The CA certificate can be pushed out through SMS

  5. The entire Windows domain can be made to trust the CA certificate by using a group policy

3.2.2 Define Certificate Policies and Practices

A Certificate Practice Statement (CPS) describes the policies and practices that your certificate authority follows when providing certificate services, including:

  • Certificate types and usage

  • Management of the certificate life-cycle

  • Procedures and policies governing end-users

  • Technical specifications for certificates

The range of information contained in a CPS includes, but is not limited to:

  • General information

    • legal issues, liabilities and financial obligations

    • Public Key Infrastructure knowledge requirements

  • Authentication and identification concerns

    • positive identification of the CA, including CA name, server name, and DNS address

    • how users are authenticated to the CA

    • the intended purpose of the certificate

    • what certificate policies are implemented by the CA and what certificate types are issued

    • policies, procedures, and processes for issuing, renewing, and recovering certificates

  • Physical and personnel security

    • physical, network, and procedural security for the CA

    • requirements for certificate enrollment and renewal

    • requirements for certificate users, including what users must do in the event that their private keys are lost or compromised

    • policies for revoking certificates, including conditions for certificate revocation, such as employee termination and misuse of user rights

    • warning and caution notes about using certificates

  • Technical security requirements

    • cryptographic algorithms, Cryptographic Service Provider (CSP), and key length used for the CA certificate

    • minimum length for the public key and private key pairs

    • certificate key strengths and related security consequences

    • lifetime of the CA certificate

    • certificate life cycle details

    • standards or protocols used

    • private key management requirements, such as storage on local disk, smart cards, or other hardware devices

  • Certificate profile

    • certificate types and usage

    • extensions supported and used, constraints

    • certificate limitations

  • CRL policies

    • where to locate CRL distribution points

    • how often CRLs are published

You can add or alter your certificate practice statement by editing the $ORACLE_HOME/j2ee/oca/applications/ocaapp/oca/helpsets/oca_practice_stmt/ocaadmin_cs_practicestmt.html file.

After OracleAS Certificate Authority is restarted, your changes will appear on the Practice Statement page when a user clicks the Practice Statement icon which appears on every page.


Note:

The Certificate Practice Statement created by the OracleAS Certificate Authority administrator using this procedure is not globalization (i18n) compliant. This means that it is rendered in the locale in which it is edited by the administrator, regardless of the client locale; clients will see it only in the language in which it was created.

3.2.3 Define CRL Policies

Before using a certificate, applications in your trust environment should be able to verify the status of the certificate so that a revoked certificate is not used for authentication. The certificate revocation list (CRL) accomplishes this goal, with OracleAS Certificate Authority periodically generating and storing the list of revoked certificates.


Note:

OracleAS Certificate Authority's Certificate Revocation List resides in Oracle Internet Directory with a CRL Distribution Point (CRLDP) extension, and also resides in the database. To prevent a revoked certificate from being misused, applications extract the CRLDP from the certificate and use it to retrieve the CRL from Oracle Internet Directory. End users, on the other hand, point their browser to OracleAS Certificate Authority, which retrieves the CRL from the database.

There are two ways to generate the CRL:

  • By default, OracleAS Certificate Authority automatically generates the CRL. The administrator can configure a notification parameter for e-mail notification in the event that CRL generation fails.

  • The administrator can also generate an updated CRL manually.

Some recommendations for administering the CRL follow:

  • You should identify an appropriate validity period for the CRL, as well as the interval (before and after expiry) in which a new CRL should be generated. This interval should be less than the validity period, and chosen so that applications have some grace period to retrieve the latest CRL. This also allows some time (the range of time between the end of CRL validity and the next CRL generation) to recover from a certificate authority failure before the CRLs become invalid.

  • Configure automatic CRL generation. Reserve the use of manual CRL generation for extreme cases, for instance when a high-value certificate must be revoked.


See Also:


3.2.4 Define Alerts and Notifications

OracleAS Certificate Authority provides a range of parameters to alert end-users and the administrator when key events occur, and to schedule administrative jobs:

  • receive an alert when the number of pending certificate requests exceeds a specified threshold

  • schedule a job to automatically generate the CRL at specified intervals

  • receive an alert whenever automatic generation of the CRL fails

  • schedule a job to synchronize certificate information with Oracle Internet Directory (this is useful in the event that the directory goes down, since OracleAS Certificate Authority can queue up certificates and synchronize with the directory once it comes back up)

  • customize the e-mails automatically sent to OracleAS Certificate Authority users to notify them of administrative actions like certificate approval and rejection

For details on this topic, see "Notification Sub-tab" in Chapter 5.

3.3 Planning your OracleAS Certificate Authority Architecture

It is important to think about certain system architecture issues before you begin implementing OracleAS Certificate Authority. You should consider what kind of trust hierarchy you need, whether to configure offline CAs, and the security of your OracleAS Certificate Authority installation. Proper planning will enable you to implement a reliable and scalable certificate authority.

This section contains the following topics:

3.3.1 CA Trust Hierarchy

In a CA trust hierarchy, the root certificate authority for a security domain is the basic CA that is ultimately trusted by all users in the organization. The root CA can in turn issue a certificate to another CA, thus creating a subordinate CA (sometimes known as a Sub CA).

You can install a subordinate CA at any time, create a certificate request and save it to a file, and submit it to the root CA. Once approved, the certificate can then be imported into the subordinate CA for use as a Sub CA signing certificate. Sub CAs can, in turn, issue certificates to lower levels of CAs.

By appropriate use of these techniques, which OracleAS Certificate Authority fully supports, you can set up a trust hierarchy in which end users (or applications acting on behalf of users) can trace the CA certificate chain back to the root CA - the ultimate source of trust for the hierarchy - providing secure, reliable, and efficient digital communication.

3.3.1.1 Online and Offline CAs

In the simplest scenario, there is a single certificate authority serving the entire organization. This CA serves multiple roles: as the root CA, and also as certificate issuer. Figure 3-1 illustrates this scenario.

However, this configuration is not advisable even for relatively small sites; it is preferable to create a hierarchy of CAs to provide important benefits in security, reliability, availability, and cost savings. For example, CAs in the hierarchy can be dedicated to specific roles to protect critical CAs against attack.

Figure 3-2 demonstrates how the root CA can be protected. It shows a simple certificate authority hierarchy serving an organization which consists of two geographically distinct sites. Each site is served by a SubCA. The two SubCAs are subordinate to the root CA, which is offline. The SubCAs are both online, and service certificate requests for the end users at their respective sites.

Figure 3-2 A Simple CA Hierarchy

Description of Figure 3-2  follows
Description of "Figure 3-2 A Simple CA Hierarchy"

Figure 3-3 shows an extension of the previous certificate authority hierarchy for the same organization. Each site is now served by a pair of Sub CAs; one Sub CA is online and functions as the issuing certificate authority, while the other, higher Sub CA is offline for security. Both pairs of Sub CAs are, in turn, subordinate to the root CA, which itself is offline.

With this arrangement, if the issuing Sub CA is somehow compromised, the offline Sub CA higher up in the hierarchy can revoke its CA certificate and create a new Sub CA to replace it.

Figure 3-3 A CA Hierarchy with Two Levels of SubCA

Description of Figure 3-3  follows
Description of "Figure 3-3 A CA Hierarchy with Two Levels of SubCA"

Another advantage of a trust hierarchy is the ability to set up trust relationships across companies or organizations that are served by independent certificate authorities.

In Figure 3-4, companies A and B have separate CAs; company A uses a third-party CA while company B uses OracleAS Certificate Authority. In this scenario there is no trust relationship between the organizations since the CAs are independent.

Figure 3-4 Organizations with no trust relationship

Description of Figure 3-4  follows
Description of "Figure 3-4 Organizations with no trust relationship"

In Figure 3-5, the two companies have entered into a trust relationship by establishing company B's certificate authority, OracleAS Certificate Authority, as a Sub CA to company A's third-party CA. Users in the two companies can now communicate securely based on the trust hierarchy that has been set up between the respective CAs.

Figure 3-5 Organizations related by a trust hierarchy

Description of Figure 3-5  follows
Description of "Figure 3-5 Organizations related by a trust hierarchy"

Depending on your security and availability requirements, you will need to decide upon a trust hierarchy that suits your needs. For configuration details, refer to "Configuring an OracleAS Certificate Authority Instance to Be a Subordinate CA of Another CA" in Appendix B.

3.3.2 Securing the CA

Securing the entire CA installation, and particularly the root CA, is of the utmost importance. Given the effort involved in redeploying CAs and reissuing certificates, a compromised root CA can prove much more costly than a compromised intermediate CA or issuing CA.

To protect the root CA, it is recommended that you:

  • install OracleAS Certificate Authority on a dedicated machine

  • secure it against intruder attack by maintaining the server in a physically secure location

  • limit access to trusted administrators

  • consider using hardware storage for administrator keys

  • offline the root CA (and subCAs, whenever possible) for additional protection. See "Online and Offline CAs" for more information.

  • set up an online Sub CA for day-to-day operations like issuing certificates

  • follow standard guidelines for hardening the host and for the Oracle Application Server installation

  • remove unnecessary services, and limit users who have access to the host machine

See Figure 3-3, "A CA Hierarchy with Two Levels of SubCA" and the related discussion for details.

3.4 Deployment Considerations and Base Scenarios

Depending on your site's requirements, you can choose from among several different deployment strategies for OracleAS Certificate Authority. This section describes the different scenarios and contains the following topics:

3.4.1 Required Components for OracleAS Certificate Authority

OracleAS Certificate Authority needs the following components for its operation:

  • Oracle HTTP Server (OHS) (must be on the same machine as OracleAS Certificate Authority)

  • OC4J for OracleAS Certificate Authority (must be on the same machine as OracleAS Certificate Authority)

  • Infrastructure metadata repository

  • Oracle Internet Directory

  • Single Sign-On (optional)


    Note:

    OCA is not automatically selected for installation - that is, as a default selected choice. To install OCA, you must explicitly select it for installation.

3.4.2 Default Deployment

In the default deployment, all the required components are installed on the same machine and in the same Oracle home, as shown in Figure 3-6. This configuration is ideal for development and non-production environments, and is the default configuration if you do not make other choices during installation.

Figure 3-6 Oracle Application Server Certificate Authority Default Installation

Description of Figure 3-6  follows
Description of "Figure 3-6 Oracle Application Server Certificate Authority Default Installation"

The installation instructions for this default deployment of OracleAS Certificate Authority appear in Section 6.19 of the Oracle Application Server Installation Guide.

3.4.3 Production Deployment

In the recommended production deployment, OHS, OC4J, OracleAS Certificate Authority, and the infrastructure metadata repository reside on one machine, in one Oracle home. Remaining components like OracleAS Single Sign-On and Oracle Internet Directory are on a different machine, in a different Oracle home. This physical separation makes it possible to harden the security of that separate location, to protect OracleAS Certificate Authority in a very secure location. Since OracleAS Certificate Authority is at the top of the trust chain for certificates, these additional protections are prudent in a production environment, as illustrated in Figure 3-7. Similarly, it is better for OracleAS Certificate Authority security reasons not to use remote administration mechanisms to start or stop these components.

Figure 3-7 OracleAS Certificate Authority Recommended Production Installation

Description of Figure 3-7  follows
Description of "Figure 3-7 OracleAS Certificate Authority Recommended Production Installation"

Installation instructions for this recommended deployment appear in Section 6.20 of the Oracle Application Server Installation Guide.

3.4.4 DMZ Deployment

A DMZ configuration exposes OracleAS Certificate Authority to an external network and may be necessary if, for example, you wish to allow access to the certificate authority by internet users.

Figure 3-8 OracleAS Certificate Authority DMZ Installation

Description of Figure 3-8  follows
Description of "Figure 3-8 OracleAS Certificate Authority DMZ Installation"

In this scenario, which is shown in Figure 3-8, you configure proxy servers in the DMZ to handle OracleAS Certificate Authority requests.

OracleAS Certificate Authority requires two ports for its functioning. External users access OracleAS Certificate Authority on either port 443 (SSL users - this is the recommended setup) or port 80 (non-SSL users). All requests are routed through proxy server 1 utilizing, for example, port 6600 (or another port in the available range) for server authentication. If - and only if - it is determined that a request requires mutual authentication, OracleAS Certificate Authority internally redirects the request to proxy server 2, which then routes it to mutual authentication utilizing, for example, port 6601.

If only port 443 is allowed in the proxy server, then two proxy servers should be used. Also, the proxy server information needs to be updated in the OracleAS Certificate Authority repository.

For details about setting up this scenario, see Appendix F, "ExternalAccess to Protected OracleAS Certificate Authority".


Note:

This is not a recommended topology for OracleAS Certificate Authority deployment. However, if it becomes necessary to deploy in the DMZ, it is recommended that you:
  1. have a SubCA for external users

  2. allow only manual authentication to OracleAS Certificate Authority, and have the administrator issue these certificates


3.4.5 High Availability Deployment Options

Broadly speaking, there are two types of high availability options for protecting a certificate authority deployment:

  • problems such as human errors, machine and media failures can be resolved with localized, high availability protection at a single data center

  • natural disasters and regional network outage can be addressed with geographically distributed disaster recovery deployments

This section presents three high availability options for your OracleAS Certificate Authority deployment: a cold failover cluster for localized protection, a disaster recovery solution, and a combination of these to protect against both types of failures.


See Also:

The deployment options shown here are described in depth in the Oracle Application Server High Availability Guide.

3.4.5.1 Cold Failover Cluster

Cold failover cluster, which is shown in Figure 3-9, operates in an active-passive mode to provide localized high availability. The active node runs an Oracle Application Server instance including OracleAS Certificate Authority as well as other Oracle Identity Management components. The passive node, which is not started unless and until the active node goes down, likewise hosts an Oracle Application Server instance consisting of OracleAS Certificate Authority and related components. In this cluster environment, the ORACLE_HOME for the OracleAS Infrastructure resides on a shared storage system.

Figure 3-9 Cold Failover Cluster

Description of Figure 3-9  follows
Description of "Figure 3-9 Cold Failover Cluster"

As the name implies, the active node actively services certificate requests, while the passive node is inactive until there is a component failure in the active node; when this occurs, the user requests are redirected to the secondary node, which mounts the file system and assumes control over the shared storage to continue processing.


Note:

The virtual host provides a network-addressable host name that maps to one or more physical machines through a load balancer or a hardware cluster. The virtual host can be standalone or it can reside within the OracleAS Infrastructure.

3.4.5.2 Disaster Recovery

Figure 3-10 shows a disaster recovery configuration utilizing active and standby nodes which are synchronized but are geographically dispersed. Each node hosts an Oracle Application Server instance, including OracleAS Certificate Authority as well as other Oracle Identity Management components, each instance residing on its own ORACLE_HOME. In this scenario, the active site is the production site and actively services client requests, while the standby site mirrors the applications (including OracleAS Certificate Authority) and data repository of the production site. Site synchronization is provided by Oracle Data Guard, with OracleAS Guard providing the procedures necessary for backing up and restoring the necessary configuration files.

Figure 3-10 Disaster Recovery

Description of Figure 3-10  follows
Description of "Figure 3-10 Disaster Recovery"

In the event of catastrophic failure at the active site, OracleAS Guard performs failover tasks to switch the standby site over to active mode, and user requests are redirected to that node for continued operation.

3.4.5.3 Cold Failover Cluster and Disaster Recovery

This configuration combines the "Cold Failover Cluster" and "Disaster Recovery" solutions into a unified system that provides protection from isolated problems as well as from catastrophic failures affecting an entire site.

In this arrangement, shown in Figure 3-11, the active and standby sites each provide independent cold failover cluster services. The site-specific virtual hosts can handle local failures entirely within the site by redirecting requests to the passive Oracle Application Server instance. The overall "global" virtual host, on the other hand, provides a higher level of load balancing by failing over requests to the standby site in the event of a catastrophic failure.

Figure 3-11 Combined Cold Failover Cluster and Disaster Recovery

Description of Figure 3-11  follows
Description of "Figure 3-11 Combined Cold Failover Cluster and Disaster Recovery"

3.5 OracleAS Certificate Authority Implementation and Use Case

This section brings together the logical and physical concepts underlying certificate authority implementation to help you define the characteristics and decision points critical for your OracleAS Certificate Authority deployment.

3.5.1 Implementation Checklist

The following checklist summarizes the key planning items for a deployment of OracleAS Certificate Authority and provides the essential starting point for deployment.

Table 3-2 Implementation Checklist

Planning Item Recommended / Proposed Value Notes

Certificate policies and implementation details



CA DN



CA certificate lifetime


See Table 4-4 for default value

CA wallet type


Enter signing, SSL, or S/MIME

CA wallet key size


See Table 4-4 for default value

CA certificate validity period


See Table 4-4 for default value

SubCA certificate validity period



Total number of users



Number of authentication certificates



Number of encryption certificates



Number of signing certificates



Number of code signing certificates



Validity period for new certificates


See "User Certificates Tab" in Chapter 8 for defaults and other details.

Validity period for renewed certificates


See Table 6-7 for defaults.

Renewal window


Enter number of days before and after expiration that certificates can be renewed. See Table 6-7 for defaults.

RSA public/private key lengths


See "User Certificates Tab" in Chapter 8 for defaults and other details.

Allow multiple certificates for same usage to same name?


This is the UniqueCertificateConstraint policy

CRL distribution point


For details, see:

CRL publication frequency



How will certificates be stored?


Enter storage requirement, such as file or token

Architecture



Number of levels in CA hierarchy



Role of root CA


Enter online/offline, whether issues certificates

Sub CA type


Enter online or offline

Additional SubCA data



Deployment



Separate repository for OracleAS Certificate Authority?



DMZ Deployment?



High Availability



Cold Failover?



Disaster Recovery?




3.5.2 Use Case: MyPKIsite.com

This use case describes a fictional deployment scenario, MyPKIsite.com, to demonstrate PKI-enabled enterprise deployment using OracleAS Portal and OracleAS Certificate Authority. Rather than provide an exhaustive listing of tasks, it identifies the major factors that should be taken into account when deploying OracleAS Certificate Authority.

3.5.2.1 Scenario

MyPKIsite.com is a fictional online travel service which enables travelers to plan itineraries, make reservations, and securely exchange messages with travel advisors on two continents. The company needs to secure its website using PKI certificates.


Note:

MyPKIsite.com is a fictitious company, used only for the purposes of illustration.

Here are some basic facts about the company and its security needs:

  • The company has offices in the US and UK

  • In addition to employees at both locations, the site must support external users, including customers and partners

  • The company's security requirements include

    • enabling SSL authentication for servers

    • the ability to implement single sign-on for a number of applications, using client certificates for authentication

    • the ability to sign and encrypt e-mail messages with S/MIME

3.5.2.2 Administrative Roles

Based on current needs, it is decided to appoint one person to serve as both the OracleAS Certificate Authority administrator and the web administrator.

3.5.2.3 CA Hierarchy for MyPKIsite.com

The implementation team decides to implement a basic two-level hierarchy:

  1. Offline root CA

  2. Four issuing SubCAs:

    • Two issuing SubCAs in the US, one for internal users and another for external users. These issuing SubCAs are subordinate to the root CA

    • Two issuing SubCAs in the UK, one for internal users and another for external users. These issuing SubCAs are subordinate to the root CA.

Alternative Hierarchy Option

During planning, the team had also considered an alternative option consisting of a three-level hierarchy:

  1. Offline root CA

  2. Offline SubCA for the US, and another offline SubCA for the UK

  3. Four issuing SubCAs:

    • Two issuing SubCAs in the US, one for internal users and another for external users. These issuing SubCAs are subordinate to the offline US SubCA.

    • Two issuing SubCAs in the UK, one for internal users and another for external users. These issuing SubCAs are subordinate to the offline UK SubCA.

If security warrants the need for additional protection at a later time, they can later move to this three-level hierarchy by adding another SubCA layer consistent with this option.

3.5.2.4 User Entries in Oracle Internet Directory

User entries, which will contain users' certificates, must be added in Oracle Internet Directory. Given the large number of users who require certificates, the team decides to use Oracle Internet Directory's bulk loading tool to define and maintain user entries in the directory.

bulkload loads and appends large numbers of entries to Oracle Internet Directory through LDIF files. bulkload handles various steps of the procedure, including:

  • Checking the input files for schema and data consistency

  • Converting the LDIF data into a format appropriate for the loader

  • Loading and indexing the data

By way of reference, there are other tools the team could have utilized for creating user entries:

  • Delegated Administration Services

  • Command-line tools

  • Oracle Directory Manager

3.5.2.5 Component Instances

The site will make use of shared Oracle Internet Directory and Oracle Application Server Single Sign-On components.


Note:

Multiple physical instances of Oracle Internet Directory, one in the US and one in UK, can be set up in multi-master mode.

The team must install a total of five instances of OracleAS Certificate Authority, including one root CA and four issuing SubCAs. Each instance has its own metadata repository, on its own machine.

3.5.2.6 Certificate Requirements for MyPKIsite.com

The team makes the following decisions about certificate provisioning and usage:

Provisioning

End users will be authenticated to the site using single sign-on certificates. Manual certificates will be issued for servers.


See Also:

For more information, see "Certificate Provisioning".

Certificate Lifetime

Certificates issued by MyPKIsite.com are valid for the following periods:

Table 3-3 Certificate Lifetimes

Certificate Initial Validity Renewal Window Renewed For

User

Two years

30 days before/after expiration

One year

Server

Ten years

30 days before/after expiration

Five years


Once certificates expire, they will not be renewed. (However, company practice allows certificates to be renewed up to 30 days after expiration. To implement this, the administrator can set a parameter which provides a "grace period" for renewal. Regardless, certificates cannot be renewed if they have been expired longer than 30 days.)

Certificate Key Sizes

MyPKIsite.com will use these key sizes:

  • 1024 bytes for user certificates

  • 1024 bytes for server certificates

  • 2048 bytes for CA certificates

Certificate Usage

The site will use two types of certificates:

  • One certificate for authentication and signing

  • Another certificate for encryption

The unique certificate constraint will be imposed, so that a user can only have one authentication and signing certificate, and one encryption certificate.


See Also:

See "Certificate Types" for more information.

Certificate Distribution

The team considers two options for distributing the root CA and SubCA certificates:

  1. The user imports these certificates manually

  2. The certificates reside in the base image of each user's machine

The team decides that users should import their certificates manually so that base images do not need to be rebuilt. Users will go to the OracleAS Certificate Authority home page to download and input the CA certificate into their browsers.

Certificate Storage

MyPKIsite.com users have smart cards on their desktop machines. Users will store their private keys on the smart cards.

Revocation

Certificates will be revoked for the standard revocation reasons:

  • Key Compromise

  • Affiliation Change

  • CA Compromise

  • Certificate Hold

  • Cessation of Operation

  • Remove From CRL

  • Superseded

CRL Location and Publication

The CRL is to be published every three days at midnight, and the CRL validity period is set at 7 days.

The root CA's CRL is valid for 6 months.


See Also:

See "Updating the Certificate Revocation List (CRL)" in Chapter 4 for more information.

3.5.2.7 Security Considerations

The team decides to take the following measures for securing the certificate authority:

  • Install the root OracleAS Certificate Authority instance, and its associated metadata repository, on a dedicated machine

  • Maintain the CA server in a physically secure location

  • Offline all non-issuing CAs, as outlined in "CA Hierarchy for MyPKIsite.com".

3.5.2.8 High Availability Considerations

Since they will handle all user requests, the four certificate issuing SubCAs must be highly available. They will be supported with a combination of Cold Failover Cluster and Disaster Recovery using Dataguard.

All CA instances, offline as well as online, need to be backed up on a regular schedule.

3.5.2.9 Detailed Implementation Checklist for MyPKIsite.com

MyPKIsite.com's implementation team has now finalized decisions about the design and operation of their OracleAS Certificate Authority installation. The checklist in Table 3-4 summarizes these decisions, and provides links which explain how the various setup tasks are performed.

Although derived from the checklist in Table 3-2, this list is more detailed and refers to specific OracleAS Certificate Authority tasks and functions.


Note:

Some of the items in the list, such as user certificate requests, are not immediate tasks but rather future activities. They are listed here for completeness.

Table 3-4 Implementation Checklist for MyPKIsite.com

Task/Item Value References

Install components

-

Platform-specific Oracle Application Server Installation Guide

Create user entries

-

Oracle Internet Directory Administrator's Guide


Set up SubCAs

4 SubCA instances

Appendix B, "Setting up a CA Hierarchy", particularly "Configuring an OracleAS Certificate Authority Instance to Be a Subordinate CA of Another CA".

Set up passwords

-

"Changing Privileged Passwords" in Appendix A

Request administrator certificate

-

"Requesting the Administrator Certificate" in Chapter 4

Request server certificates

-

"Server/SubCA Certificates Tab" in Chapter 8

Request user certificates (ongoing)

-

Revoke expired certificates?

Yes, allowing for grace period (see "Set certificate renewal window")

"RevocationConstraints" in Chapter 6

Set certificate renewal window

30 days before/after expiration

"RenewalRequestConstraint" in Chapter 6

User certificate unique?

Yes

"UniqueCertificateConstraint" in Chapter 6

Set certificate validity

Ten year server certificate Two year user certificate

"ValidityRule" in Chapter 6

Set certificate key sizes

2048 (CA) 1024 (server, user)

"RSAKeyConstraints" in Chapter 6

Set key storage mechanism

smart cards

-

Define e-mail parameters

-

"Mail Details" and "Email Templates" in Chapter 5

Set up notifications

daily

"Alerts" in Chapter 5

Configure CRL generation frequency

every seven days

"Scheduled Jobs" in Chapter 5

High Availability


"OracleAS Certificate Authority and High-Availability Features" in Chapter 7

Write CPS