4 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: Preparing 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 4-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

Script to Create Certificates

A script has been provided as part of the Identity and Access Management Automation scripts called create_idm_certs.sh, which can be used to perform all of the tasks outlined below. To obtain the scripts, see Automating the Enterprise Deployment.

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 -addext "basicConstraints=critical,CA:TRUE" -addext "keyUsage=critical,keyCertSign,cRLSign" -addext "subjectKeyIdentifier=hash"
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 -addext "keyUsage=critical,keyCertSign,cRLSign" -addext "subjectKeyIdentifier=hash"

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 4-1 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 4-2 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