5 Procuring Resources for an Enterprise Deployment

It is essential to procure the required hardware, software, and network settings before you configure the Oracle Identity and Access Management reference topology.

This chapter provides information on how to reserve the required IP addresses and identify and obtain software downloads for an enterprise deployment.

Parent topic: Preparing for an Enterprise Deployment

Hardware and Software Requirements for the Enterprise Deployment Topology

It is important to understand the hardware load balancer requirements, host computer hardware requirements, and operating system requirements for the enterprise deployment topology.

This section includes the following sections.

Parent topic: Procuring Resources for an Enterprise Deployment

External Load Balancer Requirements

The section lists the requirements of the external load balancer.

The enterprise topology uses an external load balancer. The features of the external load balancer are:

  • Ability to load-balance traffic to a pool of real servers through a virtual host name: Clients access services by using the virtual host name (instead of using actual host names). The load balancer can then load balance requests to the servers in the pool.

  • Port translation configuration should be possible so that incoming requests on the virtual host name and port are directed to a different port on the backend servers.

  • Monitoring of ports on the servers in the pool to determine availability of a service.

  • Ability to configure names and ports on your external load balancer. The virtual server names and ports must meet the following requirements:

    • The load balancer should allow configuration of multiple virtual servers. For each virtual server, the load balancer should allow configuration of traffic management on more than one port. For example, for Oracle HTTP Server in the web tier, the load balancer needs to be configured with a virtual server and ports for HTTP and HTTPS traffic.

    • The virtual server names must be associated with IP addresses and be part of your DNS. Clients must be able to access the external load balancer through the virtual server names.

  • Ability to detect node failures and immediately stop routing traffic to the failed node.

  • It is highly recommended that you configure the load balancer to be in fault-tolerant mode.

  • It is highly recommended that you configure the load balancer virtual server to return immediately to the calling client when the backend services to which it forwards traffic are unavailable. This is preferred over the client disconnecting on its own after a timeout based on the TCP/IP settings on the client machine.

  • Ability to maintain sticky connections to components. Examples of this include cookie-based persistence, IP-based persistence, and so on.

  • The load balancer should be able to terminate SSL requests at the load balancer and forward traffic to the backend real servers by using the equivalent non-SSL protocol (for example, HTTPS to HTTP).

  • In this Enterprise Deployment Guide, SSL listeners are used for the Oracle HTTP Servers and the Oracle WebLogic Servers. The load balancer should therefore be able to establish SSL communication with the backend servers in its pools.

  • The ability to route TCP/IP requests. This is a requirement for LDAP

  • SSL acceleration (this feature is recommended, but not required for the enterprise topology).

Parent topic: Hardware and Software Requirements for the Enterprise Deployment Topology

Host Computer Hardware Requirements

This section provides information to help you procure host computers that are configured to support the enterprise deployment topologies.

It includes the following topics.

Parent topic: Hardware and Software Requirements for the Enterprise Deployment Topology

General Considerations for Enterprise Deployment Host Computers

This section specifies the general considerations that are required for the enterprise deployment host computers.

Before you start the process of configuring an Oracle Fusion Middleware enterprise deployment, you must perform the appropriate capacity planning to determine the number of nodes, CPUs, and memory requirements for each node depending on the specific system's load as well as the throughput and response requirements. These requirements vary for each application or custom Oracle Identity and Access Management system being used.

The information in this chapter provides general guidelines and information that helps you determine the host computer requirements. It does not replace the need to perform capacity planning for your specific production environment.

Note:

As you obtain and reserve the host computers in this section, note the host names and system characteristics in the Enterprise Deployment workbook. You will use these addresses later when you enable the IP addresses on each host computer. See Using the Enterprise Deployment Workbook.

Reviewing the Oracle Fusion Middleware System Requirements

This section provides reference to the system requirements information to help you ensure that the environment meets the necessary minimum requirements.

Review the Oracle Fusion Middleware System Requirements and Specifications to ensure that your environment meets the minimum installation requirements for the products that you are installing.

The Requirements and Specifications document contains information about general Oracle Fusion Middleware hardware and software requirements, minimum disk space and memory requirements, database schema requirements, and the required operating system libraries and packages.

It also provides some general guidelines for estimating the memory requirements for your Oracle Fusion Middleware deployment.

Typical Memory, File Descriptors, and Processes Required for an Enterprise Deployment

This section specifies the typical memory, number of file descriptors, and operating system processes and tasks details that are required for an enterprise deployment.

The following table summarizes the memory, file descriptors, and processes required for the Administration Server and each of the Managed Servers computers in a typical Oracle Identity and Access Management enterprise deployment. These values are provided as an example only, but they can be used to estimate the minimum amount of memory required for an initial enterprise deployment.

The example in this topic reflects the minimum requirements for configuring the Managed Servers and other services required on OAMHOST1, as depicted in the reference topologies.

When you procure systems, use the information in the Approximate Top Memory column as a guide when determining the minimum physical memory that each host computer should have available.

After you procure the host computer hardware and verify the operating system requirements, review the software configuration to be sure that the operating system settings are configured to accommodate the number of open files listed in the File Descriptors column and the number processes listed in the Operating System Processes and Tasks column.

See Setting the Open File Limit and Number of Processes Settings on UNIX Systems.

Table 5-1 Typical Memory, File Descriptors, and Processes Required for an Enterprise Deployment

Managed Server, Utility, or Service Approximate Top Memory Number of File Descriptors Operating System Processes and Tasks

Access Administration Server

3.5 GB

2300

180

Governance Administration Server

4.5 GB

2100

100

soa_server

6.0 GB

3100

240

oim_server

8 GB

1400

190

oam_server

2.7 GB

2000

170

oam_policy_mgr

2.88 GB

1700

160

WLST (connection to the Node Manager)

1.5 GB

910

20

Configuration Wizard

1.5 GB

700

20

Node Manager

1.0 GB

300

20

TOTAL

31.58 GB*

14510

1100

* Approximate total, with consideration for Operating System and other additional memory requirements.

Typical Disk Space Requirements for an Enterprise Deployment

This section specifies the disk space that is typically required for this enterprise deployment.

For the latest disk space requirements for the Oracle Fusion Middleware 14c (14.1.2.1.0) products, including the Oracle Identity and Access Management products, review the Oracle Fusion Middleware System Requirements and Specifications.

In addition, the following table summarizes the disk space that is typically required for an Oracle Identity and Access Management enterprise deployment.

Use the this information and the information in Preparing the File System for an Enterprise Deployment to determine the disk space requirements required for your deployment.

Server Disk

Database

nXm

n = number of disks, at least 4 (striped as one disk)

m = size of the disk (minimum of 30 GB)

WEBHOSTn

10 GB

OAMHOSTn

10 GB*

OIGHOSTn

10 GB*

LDAPHOSTn

10 GB*

* For a shared storage Oracle home configuration, two installations suffice by making a total of 20 GB.

Operating System Requirements for an Enterprise Deployment Topology

This section provides details about the operating system requirements.

The Oracle Fusion Middleware software products and components that are described in this guide are certified on various operating systems and platforms, which are listed in Oracle Fusion Middleware System Requirements and Specifications.

Note:

This guide focuses on the implementation of the enterprise deployment reference topology on Oracle Linux systems.

The topology can be implemented on any certified, supported operating system, but the examples in this guide typically show the commands and configuration steps as they should be performed by using the bash shell on Oracle Linux.

Parent topic: Hardware and Software Requirements for the Enterprise Deployment Topology

About Private Networks

A private network enables you to keep inter-application communications within the private network, providing communication that is both faster and more secure. By keeping inter-application traffic inside the private network, you do not expose traffic to the internet. To use a private network, you have to create a private VLAN.

Parent topic: Hardware and Software Requirements for the Enterprise Deployment Topology

About Virtual Server Templates

You can customize the values of the Virtual Server Templates depending on the results of your capacity planning.

The following are the typical virtual server templates that you can customize.

Table 5-2 Virtual Server Templates

Type Description Memory (GB) Number of Virtual CPUs

VERY_LARGE

Large Memory Intensive Applications

20

6

EXTRA_LARGE

CPU Intensive Applications

16

6

LARGE

Average Intensity Applications

8

2

SMALL

Low intensity applications

4

1

Parent topic: Hardware and Software Requirements for the Enterprise Deployment Topology

Reserving the Required IP Addresses for an Enterprise Deployment

You have to obtain and reserve a set of IP addresses before you install and configure the enterprise topology. The set of IP addresses that need to be reserved are listed in this section.

Before you begin installing and configuring the enterprise topology, you must obtain and reserve a set of IP addresses:

  • Physical IP (IP) addresses for each of the host computers that you have procured for the topology

  • A virtual IP (VIP) address for the Administration Servers and a virtual host name mapped to this VIP

  • VIPs are not required for any of the Managed Servers in the FMW IAM Enterprise Deployment since all components support Automatic Service Migration.

    For Fusion Middleware 14c products that support Automatic Service Migration, VIPs for the Managed Servers are typically not necessary.

You can then work with your network administrator to be sure that these required VIPs are defined in your DNS server. Alternatively, for non-production environments, you can use the /etc/hosts file to define these virtual hosts.

For more information, see the following topics.

Parent topic: Procuring Resources for an Enterprise Deployment

What is a Virtual IP (VIP) Address?

This section defines the virtual IP address and specifies its purpose.

A virtual IP address is an unused IP Address that belongs to the same subnet as the host's primary IP address. It is assigned to a host manually. If a host computer fails, the virtual address can be assigned to a new host in the topology. For the purposes of this guide, virtual IP addresses are referenced, which can be reassigned from one host to another, and physical IP addresses are referenced, which are assigned permanently to hardware host computer.

Parent topic: Reserving the Required IP Addresses for an Enterprise Deployment

Why Use Virtual Host Names and Virtual IP Addresses?

For an enterprise deployment, in particular, it is important that a set of VIPs and the virtual host names to which they are mapped are reserved and enabled on the corporate network.

Alternatively, host names can be resolved through the appropriate /etc/hosts file propagated through the different nodes.

The Oracle Identity Governance product supports Automatic Service Migration. As a result, it is no longer necessary to reserve VIPs for each of the Managed Servers in the domain. Instead, a VIP is required for the Administration Server only.

In the event of the failure of the host computer where the IP address is assigned, the IP address can be assigned to another host in the same subnet so that the new host can take responsibility for running the Admin Server. The reassignment of virtual IP address for the Administration Server must be performed manually.

Note:

Regardless the use of virtual or physical IPs, Oracle also recommends that you use aliases to map to different IPs in different data centers in preparation for disaster recovery. It is recommended to use these aliases to configure the listen address for the components. This approach will be used in this guide.

Parent topic: Reserving the Required IP Addresses for an Enterprise Deployment

Physical and Virtual IP Addresses Required by the Enterprise Topology

This section describes the physical IP (IP) and virtual IP (VIP) addresses that are required for the Administration Server and each of the Managed Servers in a typical Oracle Identity and Access Management enterprise deployment topology.

Before you begin to install and configure the enterprise deployment, reserve a set of host names and IP addresses that correspond to the VIPs in Table 5-3.

You can assign any unique host name to the VIPs, but in this guide, each VIP is referenced by using the suggested host names in the table.

Note:

As you obtain and reserve the IP addresses and their corresponding virtual host names in this section, note the values of the IP addresses and host names in the Enterprise Deployment workbook. You will use these addresses later when you enable the IP addresses on each host computer. See Using the Enterprise Deployment Workbook .

Table 5-3 Summary of the Virtual IP Addresses Required for the Enterprise Deployment

Virtual IP VIP Maps to... Description

VIP1

IADADMINVHN

IADADMINVHN is the virtual host name used as the listen address for the Administration Server used by the IAMAccessDomain and fails over with manual failover of the Administration Server. It is enabled on the node where the Administration Server process is running.

VIP2

IGDADMINVHN

IGDADMINVHN is the virtual host name used as the listen address for the Administration Server used by the IAMGovernacneDomain and fails over with manual failover of the Administration Server. It is enabled on the node where the Administration Server process is running.

Parent topic: Reserving the Required IP Addresses for an Enterprise Deployment

Identifying and Obtaining Software Distributions for an Enterprise Deployment

Before you begin to install and configure the enterprise topology, you must obtain the software distributions that you need to implement the topology.

The following table lists the distributions used in this guide.

For general information about how to obtain Oracle Fusion Middleware software, see Obtaining Product Distributions in Planning an Installation of Oracle Fusion Middleware.

For more specific information about locating and downloading specific Oracle Fusion Middleware products, see the Oracle Fusion Middleware Download, Installation, and Configuration Readme Files on OTN.

Note:

The information in this guide is meant to complement the information contained in the Oracle Fusion Middleware certification matrixes. If there is a conflict of information between this guide and the certification matrixes, then the information in the certification matrixes must be considered the correct version, as they are frequently updated.

Table 5-4 Oracle Fusion Middleware Distributions

Distribution Description Installer File Name Mandatory Patches

Oracle Identity Management quick installer 14c (14.1.2.1.0)

Download this distribution to install the Oracle Fusion Middleware Infrastructure, Oracle SOA Suite, and Oracle Identity and Access Management.

This distribution also installs the Repository Creation Utility (RCU), which in previous Oracle Fusion Middleware releases was packaged in its own distribution.

fmw_14.1.2.1.0_idmquickstart.jar

October 2025 Stack Bundle Patch or later.

For patch details, see Doc ID 2657920.2 on My Oracle Support.

Oracle Fusion Middleware 14c (14.1.2.1.0) Infrastructure

Download this distribution to install the Oracle Fusion Middleware Infrastructure, Oracle Identity and Access Management, Oracle SOA Suite.

Each product can be downloaded separately but this quite will use the quick installer.

This distribution also installs the Repository Creation Utility (RCU), which in previous Oracle Fusion Middleware releases was packaged in its own distribution.

fmw_14.1.2.1.0_infrastructure_generic.jar

October 2025 Stack Bundle Patch or later.

For patch details, see Doc ID 2657920.2 on My Oracle Support.

Oracle HTTP Server 14c (14.1.2.0.0)

Download this distribution to install the Oracle HTTP Server software on the Web Tier.

fmw_14.1.2.0.0_ohs_linux64.bin

October 2025 Bundle Patch or later.

Oracle Unified Directory 14c (14.1.2.1.0)

Download this distribution to install the Oracle Unified Directory software.

fmw_14.1.2.1.0_oud.jar

October 2025 Stack Bundle Patch or later.

For patch details, see Doc ID 2657920.2 on My Oracle Support.

Patch 38047590 - LDAPConfigTool

Oracle Internet Directory 14c (14.1.2.1.0)

Download this distribution to install the Oracle Internet Directory software.

fmw_14.1.2.1.0_oid_linux64.bin

October 2025 Stack Bundle Patch or later.

For patch details, see Doc ID 2657920.2 on My Oracle Support.

Patch 38047590 - LDAPConfigTool

Oracle Identity and Access Management 14c (14.1.2.1.0)

Download this distribution to install the Oracle Identity and Access Management software.

fmw_14.1.2.1.0_idm.jar

October 2025 Stack Bundle Patch or later.

For patch details, see Doc ID 2657920.2 on My Oracle Support.

Oracle SOA Suite 14c (14.1.2.0.0)

Download this distribution to install the Oracle SOA Suite software.

Note:

This is not required if you are using idm quick installer.

fmw_14.1.2.0.0_soa.jar

October 2025 Stack Bundle Patch or later.

For patch details, see Doc ID 2657920.2 on My Oracle Support.

Oracle Internet Directory Connector (12.2.1.3+)

Download this distribution to integrate with Oracle Internet Directory and Oracle Unified Directory.

oid-12.2.1.3.0.zip

  

Parent topic: Procuring Resources for an Enterprise Deployment

Obtaining SSL Certificates

The Enterprise Deployment Topology uses SSL and hence you must obtain SSL certificates. SSL can be terminated at the load balancer or can be enabled all the way from the external clients to the backend application servers.

The SSL protocol (HTTPS/LDAPS) is used for the communication between the clients and the front-end load balancer, the front-end load balancer and Oracle HTTP Servers (OHS), and the Oracle HTTP Servers and the WebLogic Servers and LDAP directories.

For these communications to take place, each access point (whether the frontend load balancer, Oracle HTTP Server or Oracle WebLogic Server) needs to certify its identity and provide a public key to encrypt traffic. This is done using the appropriate SSL certificate used at each access point. These SSL certificates are typically provided by commercial Certificate Authorities (CAs). It is expected that in a real enterprise deployment, the certificates used by each endpoint are issued by one of these commercial CAs. Since each Certificate Authority has its own mechanism to issue a SSL certificate, it is out of the scope of this Enterprise Deployment Guide to use and describe such processes. However, to provide SSL encryption between the different components across tiers, this guide provides SSL configuration steps using a self-issued Certificate Authority. This approach is considered secure and solid enough since the endpoints involved (OHS and WLS listeners) reside behind their corresponding firewalls and are not really exposed to the public. The front-end load balancer is considered a much more exposed endpoint and it is expected in all cases that users acquire the load balancer certificate from a commercial Certificate Authority.

For more information, see the following topics:

Parent topic: Procuring Resources for an Enterprise Deployment

Understanding SSL

There are two methods of implementing SSL communication: One-way authentication where a client establishes trust to a server, and two-way authentication where a client establishes trust to a server and the server in turn establishes trust to the client. This guide utilizes one-way SSL authentication.

Every communication in a system has a client and a server for the purposes of authentication. A given component may act as both a client and a server depending on the action it is performing, for example:

A Web-browser is always a client. A user types in a URL to access a web-resource. The Web-browser contacts a load balancer, which in this case is acting as a server. Once the load balancer has received the request it changes role and becomes a client whilst it transfers the request to an Oracle HTTP server, whose role in this transaction is a server. The Oracle HTTP server becomes a client whilst it interacts with a WebLogic Server which is the client, and so on.

In one-way SSL a client will contact a server and initiate a SSL handshake. After establishing a common SSL protocol and ciphersuite, the server will send the SSL certificate to the client. The client will then look at its truststore and see if it has a Certificate Authority (CA) which it can use to verify the SSL certificate that has been presented to it. The client verifies the certificate by checking the validity date, that the Common Name (CN) in the certificate matches the hostname of the server, and the digital signature is valid. If all the certificate checks pass, the transaction will be allowed to proceed. Some clients such as browsers, will report that a handshake has failed and provide you the option to manually trust the certificate. This commonly happens with self-issued Certificate Authorities which are not automatically trusted by browsers.

Note:

The majority of commercially issued Certificate Authorities are loaded into a browsers truststore automatically.

Every client has an SSL truststore. This truststore contains a list of Certificate Authorities that the client will trust. The more Certificate Authorities you have issuing certificates, the more entries you need in a truststore. If you are issuing your own certificates for a deployment, then this needs to be considered.

When using self-issued certificates in an identity management deployment, it is recommended that a single Certificate Authority is used to issue all certificates in the identity management deployment. This means only one Certificate Authority needs to be trusted by each component. If you are using self-issued certificates for your internal components and a commercial certificate for your load balancer, you will need to trust both Certificate Authorities.

The diagram below shows how you need to trust the Certificate Authorities of a typical identity management deployment:

Figure 5-1 Certificates in a Typical Identity and Access Management Topology


Certificates in a Typical Identity and Access Management Topology

Parent topic: Obtaining SSL Certificates

Types of Certificate

There are 3 types of SSL certificates:
  • Host based certificates – Host based certificates are certificates issued to a single host name. They are the most granular, but every new host needs a new certificate created. The more certificates you have the greater the administrative overhead.
  • Wildcard certificates – Wildcard certificates are certificates which are issued for a specific domain or subnet. For example *.example.com can be used for host1.example.com and host2.example.com. It is important to note that wildcard certificates are not recursive so *.example.com could not be used for host1.subnet1.example.com and host2.subnet2.example.com - in this situation you would need two wildcard certificates *.subnet1.example.com and *.subnet2.example.com. Wildcard certificates are easy to manage but can be a bit vague. They are perfect for Kubernetes deployments where you can create a wildcard certificate per namespace.
  • SAN based certificates – SAN (Subject Alternative Name) certificates are certificates which can have a list of specified hosts not necessarily in the same subnet. These certificates are a great compromise because they are easy to manage but not too encompassing.

    Note:

    Some products, namely LDAP and OHS, require SAN certificates which have both the specific host name and virtual host name included, for example: login.example.com and ohs1.ohssn.com.

Note:

In an enterprise deployment where you are using commercial certificates for the load balancer and internal certificates elsewhere, you may need to have two certificates for a specific host name, for example login.example.com being the commercial certificate used by the load balancer, and login.example.com being a self-issued certificate issued for the Oracle HTTP Server.

Parent topic: Obtaining SSL Certificates

Keystores and Truststores

A keystore is a collection of certificates stored in a single location. A truststore is a collection of Certificate Authorities stored in a single location.

Stores can either be stored in a file, in a database, or a certificate management system. Using a certificate management system can make certificate reissuing easier.

Stores in files can use several formats, for example:
  • JKS - Java Keystore.
  • PKCS12 – Public-Key Cryptography Standard, a more modern standard used across many platforms.
  • Wallets – A bespoke store used by products such as Oracle HTTP Server.

This guide uses PKCS12 stores for most of the products and a wallet for Oracle HTTP Server.

Parent topic: Obtaining SSL Certificates

Using Certificates in WebLogic Servers

The following guidelines outline using custom or third party SSL certificates with the WebLogic Servers:
  • The SSL certificate used by each WebLogic server (identity key, private key) must be issued to that server’s listen address. For example, if the server oam_server1 listens on oamhost1.example.com, the CN of its SSL certificate must be that hostname or the wildcard name valid for that hostname.
  • Oracle recommends using an identity keystore that is shared by all the servers in the same domain, where you import all the private keys used by the different WebLogic servers, each mapped to a different alias.
  • Oracle recommends using a trust keystore shared by all the servers in the domain. You must import the Certificate Authority’s (CA) certificate, and intermediate CA's if needed, into this trust keystore.
  • You must specify the identity keystore, alias of the identity key, and the trust keystore for each WebLogic server in the WebLogic domain’s configuration. Use the WebLogic Remote Console to configure these SSL settings for each server.
  • Start the WebLogic servers using the appropriate java options to point to the trusted keystore. This is required so the WebLogic servers can communicate with external SSL endpoints that use the Certificate Authorities included in such a trust store.

Parent topic: Obtaining SSL Certificates

Creating a Certificate Authority (CA)

A Certificate Authority (CA) is used to issue certificates. The CA is also placed in the truststore of clients interacting with those certificates. To create a Certificate Authority, use the following commands:
openssl genrsa -out idmCA.key 4096 
openssl req -x509 -new -key idmCA.key -out idmCA.crt -subj "C=<CountryName>/ST=<StateOrProvinceName>/L=<Locality>/O=<Organization>/CN=IDM Certificate Authority" -days 50000
For example:
openssl req -x509 -new -key idmCA.key -out idmCA.crt -subj "/C=US/ST=CA/L=Redwood Shores/O=Oracle/CN=IDM Certificate Authority" -days 50000

Parent topic: Obtaining SSL Certificates

Creating Certificates

The following topics explain how to create the different type of certificates:

Parent topic: Obtaining SSL Certificates

Creating a Host Based Certificate
To create a host-based certificate perform the following steps:
  1. Export the following environment variable substituting myhost.example.com with the required hostname:
    export host=myhost.example.com
  2. Generate a private key:
    openssl genrsa -out $host.key 4096
  3. Create a Certificate Signing Request (CSR):
    openssl req -new -key $host.key -out $host.csr -subj "/C=<CountryName>/ST=<StateOrProvinceName>/L=<Locality>/O=<Organization>/CN=$host"
    For example:
    openssl req -new -key $host.key -out $host.csr -subj "/C=US/ST=California/L=Redwood Shores/O=Oracle/CN=$host"

    Note:

    If you wish to enter the subject interactively you can do so without specifying the -subj clause.
  4. Sign the CSR with the Certificate Authority (CA):
    openssl x509 -req -in $host.csr -CA idmCA.crt -CAkey idmCA.key -CAcreateserial -out $host.crt -days 30000

Parent topic: Creating Certificates

Creating a SAN Based Certificate
A SAN based certificate includes multiple hosts in the same certificate. You can create multiple SAN certificates for individual components, or you can create a single SAN certificate to encompass all of the hosts and virtual hosts in your deployment.

Note:

Even if you are using host-based deployments you need to create the following SAN certificates:
  • An LDAP certificate that contains the host name and the virtual host name, for example ldaphost1.example.com and idstore.example.com.
  • An OHS certificate containing the host name and the virtual host name, for example webhost1.example.com and login.example.com.
To create a SAN based certificate perform the following steps:
  1. Export the following environment variable:
    export cert_name=idmCerts
  2. Create a certificate configuration file called $cert_name.cnf with the following contents:

    Note:

    Change the [ req_distinguished_name] parameters accordingly. Ensure that all the hostnames you wish to include are in the alt_names section. 
    [ req ]
default_bits           = 4096
distinguished_name     = req_distinguished_name
v3_reqensions         = v3_req

[ req_distinguished_name ]
countryName            = <CountryName>
stateOrProvinceName    = < StateOrProvinceName>
localityName           = <Locality>
organizationName       = <Organization>
commonName             = ldaphost1.dbsn.example.com

[ v3_req ]
keyUsage = critical, digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment, keyAgreement, keyCertSign, cRLSign
extendedKeyUsage = serverAuth, clientAuth
subjectAltName = @alt_names

[alt_names]

DNS.1   = ldaphost1.dbsn.example.com
DNS.2   = ldaphost2.db.example.com
DNS.3   = oamhost1.appsn.example.com
DNS.4   = oamhost2.appsn.example.com
DNS.5   = oighost1.appsn.example.com
DNS.6   = oighost1.appsn.example.com
DNS.7   = webhost1.ohssn.example.com
DNS.8   = webhost2.ohssn.example.com
DNS.9   = iadadminvhn.ohssn.example.com
DNS.10   = igdadminvhn.ohssn.example.com
DNS.11   = idstore.example.com
DNS.12   = iadadmin.example.com
DNS.13   = igdadmin.example.com
DNS.14   = login.example.com
DNS.15   = oig.example.com
DNS.16   = igdinternal.example.com
  3. Generate a Private Key:
    openssl genrsa -out $host.key 4096

    This will create a file called out $cert_name.key.

  4. Create a Certificate Signing Request (CSR) using the certificate configuration file:
    openssl req -new -key $cert_name.key -out $cert_name.csr -subj "/C=<CountryName>/ST=<StateOrProvinceName>/L=<Locality>/O=<Organization>/CN=$host" -config $cert_name.cnf -addext "subjectAltName = DNS:$cert_name"
    For example:
    openssl req -new -key $cert_name.key -out $cert_name.csr -subj "/C=US/ST=California/L=Redwood Shores/O=Oracle/CN=$cert_name" -config $cert_name.cnf -addext "subjectAltName = DNS:$cert_name"

    This will create a file called $cert_name.csr.

  5. Sign the CSR with the Certificate Authority (CA):
    openssl x509 -req -in $cert_name.csr -CA idmCA.crt -CAkey idmCA.key -CAcreateserial -out $cert_name.crt -days 30000 -setalias $cert_name -extfile $cert_name.cnf -extensions v3_req

    This will create a file called $cert_name.crt. This file will be in Privacy Enhanced Mail (PEM) format.

  6. Verify that each host is included in the certificate using the command:
    openssl x509 -text -noout -in $cert_name.crt -certopt no_subject,no_header,no_version,no_serial,no_signame,no_validity,no_issuer,no_pubkey,no_sigdump,no_aux

Parent topic: Creating Certificates

Creating a Wildcard Based Certificate
To create a wildcard based certificate perform the following steps:
  1. Export the following environment variable:
    export cert_name=examplecom
  2. Create a certificate configuration file called $cert_name.cnf with the following contents:

    Note:

    Change the [ req_distinguished_name] parameters accordingly. 
    [req]
default_md = sha256
prompt = no
req_extensions = req_ext
distinguished_name = req_distinguished_name

[req_distinguished_name]
commonName = *.example.com
countryName = <CountryName>
stateOrProvinceName = <StateOrProvince>
localityName = <Locality>
organizationName = <Organization>

[req_ext]

keyUsage=critical,digitalSignature,keyEncipherment
extendedKeyUsage=critical,serverAuth,clientAuth
subjectAltName = @alt_names
[alt_names]
DNS.1=example.com
DNS.2=*.example.com
  3. Generate a Private Key:
    openssl genrsa -out $host.key 4096

    This will create a file called out $cert_name.key.

  4. Create a Certificate Signing Request (CSR) from the private key:
    openssl req -new -nodes -$cert_name.key -config $cert_name.cnf -out $cert_name.csr

    This will create a file called $cert_name.csr.

  5. Sign the CSR with the Certificate Authority (CA):
    openssl x509 -req -in $cert_name.csr -CA idmCA.crt -CAkey idmCA.key -CAcreateserial -out $cert_name.crt -days 30000 -setalias $cert_name -extfile $cert_name.cnf -extensions req_ext

    This will create a file called $cert_name.crt. This file will be in Privacy Enhanced Mail (PEM) format.

  6. Verify that each host is included in the certificate using the command:
    openssl x509 -text -noout -in $cert_name.crt -certopt no_subject,no_header,no_version,no_serial,no_signame,no_validity,no_issuer,no_pubkey,no_sigdump,no_aux

Parent topic: Creating Certificates

Creating a PKCS12 Keystore

A keystore contains a private key, certificates and Certificate Authorities (CA's). You can create a keystore using the following commands:
  1. Export the following environment variables:

    Note:

    Change password to a password of your choice. 
    export cert_name=idmcerts.crt
export keystorepwd=password

    Note:

    Keystore Passwords MUST be unique to keystores, DO NOT use a password that you are planning on using for user accounts.
  2. Create the keystore:
    openssl pkcs12 -export -out $cert_name.p12 -inkey $cert_name.key -in $cert_name.crt -chain -CAfile idmCA.crt -passout pass:$keystorepwd -name $cert_name

    This will create a keystore file called $cert_name.p12. This file will be in PKCS12 format.

  3. Oracle recommends that WebLogic Domains use a single keystore with each of the host or SAN based certificates contained within. Each certificate is identified by an alias.

    For host based certificates this is the hostname. For SAN based certificates this is an arbitrary name such as idmcert.

    To create a keystore with all of the certifcates, you import each of the pkcs12 certifcates you created above one after the other, for example:
    keytool -importkeystore -srckeystore oamhost1.example.com.p12 -srcstoretype PKCS12 -destkeystore idmcerts.p12 -deststoretype PKCS12 -storepass <password_of_keystore> -srcstorepass <password_of_source_p12_file>
  4. Repeat the above step for each certificate to be added.

Parent topic: Obtaining SSL Certificates

Creating a PKCS12 Truststore

A truststore contains all the Certificate Authorities (CA's) that you wish to trust. In a deployment where each of the certificates are created using the same Certificate Authority (CA), this will contain:
  • The idmCA.
  • Any CA’s and Intermediate CA’s associated with your load balancer These may be self-signed CA’s or commercial CA’s.

The simplest way to create the truststore is using the keytool command.

  1. For each certificate you wish to add to the truststore, issue the following commands:
    keytool -import -keystore idmTrustStore.p12 -alias idmCA -cert -rfc -file idmCA.crt -storepass <password> -storetype pkcs12 -noprompt

    Where -alias imdCA is the user friendly name for the certificate, and -storepass <password> is a password for the keystore.

    Note:

    Keystore Passwords MUST be unique to keystores, DO NOT use a password that you are planning on using for user accounts.
  2. Repeat the above command for each CA certificate you wish to add to the truststore.
  3. Verify the contents of the keystore by issuing the command:
    openssl pkcs12 -info -in idmTrustStore.p12 -password pass:<password>

Parent topic: Obtaining SSL Certificates

Certificates Used in this Guide

To keep things as simple as possible, this guide assumes that you have the following certificates and Certificate Authorities (CA's):
  • One CA for the load balancer which is commercially issued.
  • One CA for the Identity Management Suite
  • Two SAN certificates for the load balancer
  • One SAN certificate for the rntire Identity Management Suite, or certificates for each host in the Oracle Identity Management topology.
The following table outlines all the certificates used in an enterprise deployment:

Table 5-5 Certificates Used in an IDM Enterprise Deployment

Purpose Alias Certificate Authority SAN Certificate (Host Names)

Public Load Balancer

 

lbrCA

login.example.com

oig.example.com

Private Load Balancer

  

lbrCA

iadadmin.example.com

igdadmin.example.com

login.example.com

oig.example.com

igdinternal.example.com

Identity Management Suite

idmcert

idmCA

iadadmin.example.com

igdadmin.example.com

login.example.com

oig.example.com

igdinternal.example.com

idstore.example.com

webhost1.ohssn.example.com

webhost2.ohssn.example.com

ldaphost1.dbsn.example.com

ldaphost2.dbsn.example.com

iadadminvh.appsn.example.com

oamhost1.appsn.example.com

oamhost2.appsn.example.com

igdadminvh.appsn.example.com

oighost1.appsn.example.com

oighost2.appsn.example.com

idmTrustStore

  

idmCA

lbrCA

  

Note:

Alias is the alias assigned to the certificate when placed into a keystore.

An alternative approach would be to use per host based certificates in which case you would have:

Table 5-6 Per Host Certificates Used in an IDM Enterprise Deployment

Purpose Alias Certificate Authority SAN Certificate (Host Names)

Public Load Balancer

  

lbrCA

login.example.com

oig.example.com

Private Load Balancer

  

lbrCA

iadadmin.example.com

igdadmin.example.com

login.example.com

oig.example.com

igdinternal.example.com

ldaphost1

ldaphost1

idmCA

idstore.example.com

ldaphost1.example.com

ldaphost2

ldaphost2

idmCA

idstore.example.com

ldaphost2.example.com

oamhost1

oamhost1

idmCA

iadadminvhn.example.com

oamhost1.example.com

oamhost2

oamhost2

idmCA

iadadminvhn.example.com

oamhost2.example.com

oighost1

oighost1

idmCA

igdadminvhn.example.com

oighost1.example.com

oighost2

oighost2

idmCA

igdadminvhn.example.com

oighost2.example.com

webhost1

  

idmCA

iadadmin.example.com

webhost1.example.com

webhost1

  

idmCA

igdadmin.example.com

webhost1.example.com

webhost1

  

idmCA

login.example.com

webhost1.example.com

webhost1

  

idmCA

oig.example.com

webhost1.example.com

webhost1

  

idmCA

igdinternal.example.com

webhost1.example.com

webhost2

  

idmCA

iadadmin.example.com

webhost2.example.com

webhost2

  

idmCA

igdadmin.example.com

webhost2.example.com

webhost2

  

idmCA

login.example.com

webhost2.example.com

webhost2

  

idmCA

oig.example.com

webhost2.example.com

webhost2

  

idmCA

igdinternal.example.com

webhost2.example.com

idmTrustStore

  

idmCA

lbrCA

  

Note:

Alias is the alias assigned to the certificate when placed into a keystore.

Certificates Used in a Kubernetes Deployment

To keep things as simple as possible, in a Kubernetes deployment the following Certificates and Certificate Authorities are recommended:
  • One CA for the load balancer which is commercially issued.
  • One CA for the Identity Management Suite.
  • Wild card certificates for each namespace.
Purpose Alias Certificate Authority SAN Certificate / Wild Card Names

Public Load Balancer

  

lbrCA

login.example.com

oig.example.com

Private Load Balancer

  

lbrCA

iadadmin.example.com

igdadmin.example.com

login.example.com

oig.example.com

igdinternal.example.com

webhost1

  

idmCA

iadadmin.example.com

webhost1.example.com

webhost1

  

idmCA

igdadmin.example.com

webhost1.example.com

webhost1

  

idmCA

login.example.com

webhost1.example.com

webhost1

  

idmCA

oig.example.com

webhost1.example.com

webhost1

  

idmCA

igdinternal.example.com

webhost1.example.com

webhost2

  

idmCA

iadadmin.example.com

webhost2.example.com

webhost2

  

idmCA

igdadmin.example.com

webhost2.example.com

webhost2

  

idmCA

login.example.com

webhost2.example.com

webhost2

  

idmCA

oig.example.com

webhost2.example.com

webhost2

  

idmCA

igdinternal.example.com

webhost2.example.com

idmTrustStore

  

idmCA

lbrCA

  

Ingress Namespace

  

idmCA

WildCard:

*.ingressns.svc.cluster.local

OUD Namespace

  

idmCA

WildCard:

*.oudns.svc.cluster.local

OAM Namespace

  

idmCA

WildCard:

*.oamns.svc.cluster.local

OIG Namespace

  

idmCA

WildCard:

*.oigns.svc.cluster.local

Parent topic: Obtaining SSL Certificates