| Oracle® Application Server Certificate Authority Administrator's Guide 10g (10.1.4.0.1) Part Number B15989-01 |
|
|
View PDF |
| Oracle® Application Server Certificate Authority Administrator's Guide 10g (10.1.4.0.1) Part Number B15989-01 |
|
|
View PDF |
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:
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:
Securing e-commerce with SSL encryption and authentication for Web servers
User authentication
Securing e-mail
Digitally signing documents
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:
Components of the OracleAS PKI, and OracleAS Certificate Authority's features and capabilities
For a detailed treatment of this subject, see Chapter 1, "Public Key Infrastructure and OracleAS".
OracleAS Certificate Authority is a component of the Oracle Identity Management infrastructure and leverages capabilities of this infrastructure. For examples, certificates issued by OracleAS Certificate Authority are published to Oracle Internet Directory. Users authenticated by Oracle Application Server Single Sign-On can obtain certificates seamlessly without prior knowledge of PKI. For details about the Oracle Identity Management infrastructure, see Chapter 2, "Identity Management and OracleAS Certificate Authority Features".
How many users and servers will need certificates, and for what applications
You will need a thorough survey to determine end user requirements such as: How many users and servers will need certificates? What types of certificates will they need? What guidelines do users need when requesting or using a certificate? What should be the life span of user and server certificates? Also take into account anticipated growth needs if possible.
For information about these and other certificate design issues, see "Certificate Requirements and Policies".
What deployment topology best fits the site's functional needs
You must consider the unique needs of your organization and be able to answer questions like: What kinds of trust relationships do I need with external CAs? Do I need a centralized or distributed certificate authority? Do any components need to be outside the firewall? Can my CA installation support growth and changes in the organization's structure?
Issues relating to the design of a CA infrastructure are addressed in "Planning your OracleAS Certificate Authority Architecture". Network and architectural issues are presented in "Deployment Considerations and Base Scenarios".
Security requirements
The certificate authority, being the central component of the PKI, must be housed in a secure facility. You will need to define where servers, storage devices and related components are to be located. Consider appropriate safeguards to prevent unauthorized access to CA components and to ensure that they are operated and maintained by qualified personnel.
Availability requirements
Given the strategic role played by a certificate authority, it is important to build in failover capabilities to safeguard against malicious attacks, component failures, and natural disasters. For more information, read "High Availability Deployment Options".
Testing and pilot deployment phase
These phases are important for verifying the efficiency, effectiveness, and security of the CA's operation and procedures.
Training
Training must be tailored to the needs of end users, help desk personnel, security officers, and administrators.
Putting it all together
With an appropriate understanding of PKI and OracleAS Certificate Authority, you are ready to address the critical implementation tasks:
Defining PKI policies, certificate policies, and the Certificate Practice Statement (CPS). See:
Designing the certificate authority hierarchy. Your design should consider the optimum number of levels in the hierarchy, which depends on such factors as the user population. See:
Implementing the CA hierarchy by installing and configuring the necessary CA instances.
Securing the components of the CA hierarchy to protect against intrusion attempts and attacks. See:
Oracle Application Server Security Guide for a discussion of the Oracle Application Server security architecture
Setting up certificate validation with the Certificate Revocation List (CRL). See "Updating the Certificate Revocation List (CRL)".
Defining roles and responsibilities for the entities who interact with the CA, including the CA administrator, the web administrator, end users and so on.
Deciding on your site's availability needs and configuring the environment to meet those needs. See "High Availability Deployment Options".
Establishing trust with external enterprises as needed. See .
See "Implementation Checklist" and "Use Case: MyPKIsite.com" for a list of essential planning data and a use case illustrating these decision points as an organization plans and implements an OracleAS Certificate Authority deployment.
You must plan the following components of your OracleAS Certificate Authority deployment to effectively meet your organization's certificate needs:
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:
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.
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, Encryption
Authentication, Signing
Signing, Encryption
Authentication, Signing, Encryption
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.
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".
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. |
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 |
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.
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:
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.
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: |
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:
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.
The CA certificate can be installed in the machine's base image. End users utilizing the installed browser automatically obtain the CA certificate.
You can follow any patching and security update push mechanism to push these changes to the client machines.
The CA certificate can be pushed out through SMS
The entire Windows domain can be made to trust the CA certificate by using a group policy
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. |
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:
|
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.
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:
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.
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. 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.
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-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
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
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
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.
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.
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:
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)
|
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. |
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
The installation instructions for this default deployment of OracleAS Certificate Authority appear in Section 6.19 of the Oracle Application Server Installation Guide.
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
Installation instructions for this recommended deployment appear in Section 6.20 of the Oracle Application Server Installation Guide.
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
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:
|
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. |
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.
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. |
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.
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.
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
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.
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? |
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.
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
Based on current needs, it is decided to appoint one person to serve as both the OracleAS Certificate Authority administrator and the web administrator.
The implementation team decides to implement a basic two-level hierarchy:
Offline root CA
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:
Offline root CA
Offline SubCA for the US, and another offline SubCA for the UK
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.
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
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.
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.
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.
Certificate Distribution
The team considers two options for distributing the root CA and SubCA certificates:
The user imports these certificates manually
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.
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".
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.
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 |
- |
|
|
Request administrator certificate |
- |
|
|
Request server certificates |
- |
|
|
Request user certificates (ongoing) |
- |
|
|
Revoke expired certificates? |
Yes, allowing for grace period (see "Set certificate renewal window") |
|
|
Set certificate renewal window |
30 days before/after expiration |
|
|
User certificate unique? |
Yes |
|
|
Set certificate validity |
Ten year server certificate Two year user certificate |
|
|
Set certificate key sizes |
2048 (CA) 1024 (server, user) |
|
|
Set key storage mechanism |
smart cards |
- |
|
Define e-mail parameters |
- |
|
|
Set up notifications |
daily |
|
|
Configure CRL generation frequency |
every seven days |
|
|
High Availability |
"OracleAS Certificate Authority and High-Availability Features" in Chapter 7 |
|
|
Write CPS |
|
