Implementing Custom CA-Signed Certificates

Products

• CA Identity Suite

Issue/Introduction

After attempting to implement custom CA-signed certificates, IGA services (Appserver and Balancer) fail to start. Standard documentation lacks instructions for manual CSR (Certificate Signing Request) generation and does not detail the requirement for Subject Alternative Names (SAN) or the removal of key passwords, as these are third party configurations.

Environment

• Product: IGA Xpress v15.0
• OS: Red Hat Enterprise Linux (RHEL) 9

Cause

IGA Xpress services require specific certificate configurations for inter-service communication. Startup failures can occur because:

1. IGA Requirement: The private key must be unencrypted (password removed) for the framework to initialize services automatically.
2. IGA Requirement: The certificate must contain Subject Alternative Names (SAN) for all cluster aliases (balancer, idm, idg, idp, iga15).
3. Persistence Requirement: Certificates must reside in the /opt/brcm/iga/cluster_conf/properties/trust.p12 store to persist across restarts.

Resolution

Perform these steps for each service to ensure the certificates meet IGA's environmental requirements:

1. Generate Private Key and Remove Password (Third-Party Tool: OpenSSL)

IGA requires a private key without a passphrase. Use OpenSSL to generate the key and then remove the encryption:

bash

 

# Generate the private key with a temporary password

openssl genrsa -des3 -out balancer.key 2048

# Remove the password from the key file (Mandatory for IGA)

openssl rsa -in balancer.key -out balancer.key

2. Create SAN Configuration (Third-Party Requirement for OpenSSL)

The use of a SAN.ext file is a third-party requirement for OpenSSL to include Subject Alternative Names in the request. Create a configuration file defining the aliases required by the IGA environment:

text

 

subjectKeyIdentifier = hashauthorityKeyIdentifier = keyid:always,issuer:alwaysbasicConstraints = CA:TRUEkeyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment, keyAgreement, keyCertSignsubjectAltName = DNS:balancer,DNS:idm,DNS:idg,DNS:idp,DNS:iga15issuerAltName = issuer:copy

3. Generate the CSR (Third-Party Tool: OpenSSL)

Generate the CSR using the unencrypted key and the third-party SAN configuration created in the previous step:

bash

 

openssl req -new -key balancer.key -out iga.csr

4. Import into Persistent Truststore (Third-Party Tool: Keytool)

Once the CA-signed PEM certificate is received, it must be imported into the Broadcom-specific persistent truststore:

bash

 

keytool -importcert -file [your_ca_cert].cer -alias [alias_name] -keystore /opt/brcm/iga/cluster_conf/properties/trust.p12 -storetype PKCS12

Note: The trust.p12 file is managed by the IGA framework; it will be initialized upon the first import.

5. Apply Changes

Restart all IGA services to apply the configuration:

bash

 

igactl restart all

Related Articles

Additional Information

Support Disclaimer

Important: The instructions above involve the use of third-party tools and configurations, such as OpenSSL, Keytool, and SAN.ext files. Broadcom Support provides these steps as a courtesy to define the requirements for IGA functionality. Assistance with the installation, syntax troubleshooting, or general usage of OpenSSL, Keytool, or creating third-party configuration files is not supported by Broadcom. For help with these tools, please consult the respective vendor documentation or your organization's internal certificate authority (CA) team.