Setting Up SSL Client-Side Authentication Between Transformation Hub and ESM

Setting Up SSL Client-Side Authentication Between Transformation Hub and ESM - FIPS Mode

ArcSight Platform maintains its own certificate authority (CA) to issue certificates for individual nodes in the Transformation Hub cluster and external communication. ESM needs the signed certificates in its truststore so that it will trust connections to the Arcsight Platform and Transformation Hub. You might need to contact the ArcSight Platform administrator to obtain the signed certificates if you do not have sufficient privileges to access them and run the necessary commands.

Note: When configuring Transformation Hub access, you must specify the FQDN of the ArcSight Platform virtual IP for HA or single master node and not the IP address.

To complete the configuration, complete the following tasks:

Enabling Client-side Authentication Between Transformation Hub and ESM:

Verify that Transformation Hub is functional and that client authentication is configured.
As user arcsight, stop the ArcSight Manager:
```
/etc/init.d/arcsight_services stop manager
```

Generate the keypair and certificate signing request (.csr) file. When generating the keypair, specify the fully qualified domain name of the ArcSight Manager host as the common name (CN) for the certificate.

Run the following commands:

export COMMON_NAME=<your ESM host's fully qualified domain name>

/opt/arcsight/manager/bin/arcsight keytool -store clientkeys -genkeypair -dname "cn=${COMMON_NAME}, ou=<your organization>, o=<your company>, c=<your country>" -keyalg rsa -keysize 2048 -alias ebkey -startdate -1d -validity 366

/opt/arcsight/manager/bin/arcsight keytool -certreq -store clientkeys -alias ebkey -file  ${COMMON_NAME}.csr

where ${COMMON_NAME}.csr is the output file where the .csr is stored.

To sign the ESM certificate signing request, perform the following steps in the ArcSight Platform. For an on-premises deployment, perform the steps on the master node. For a cloud deployment, perform the steps on the Bastion host.

Create a temporary folder to store the generated certificates:
```
mkdir –m 700 /tmp/esm
```
Move the certificate signing request (.csr) file from the ESM host to the temporary folder that you created.

Set the environment variables:

export CA_CERT=re_ca.cert.pem

export COMMON_NAME=<your ESM host's fully-qualified domain name>

export TH=<FQDN of the ArcSight Platform virtual IP for HA or single master node>_<Kafka TLS-enabled port>

Note: For COMMON_NAME, use the same host FQDN as you used for the ESM client key pair.

Run the following commands to sign the ESM certificate signing request:

cd /tmp/esm

export CDF_APISERVER=$(kubectl get pods -n core -o custom-columns=":metadata.name"| grep cdf-apiserver)
export PASSPHRASE=$(kubectl get secret vault-passphrase -n core -o json 2>/dev/null | jq -r '.data.passphrase')
export ENCRYPTED_ROOT_TOKEN=$(kubectl get secret vault-credential -n core -o json 2>/dev/null | jq -r '.data."root.token"')
export VAULT_TOKEN=$(echo ${ENCRYPTED_ROOT_TOKEN} | openssl aes-256-cbc -md sha256 -a -d -pass pass:"${PASSPHRASE}")
export CSR=$(cat ${COMMON_NAME}.csr)

WRITE_RESPONSE=$(kubectl exec -it -n core ${CDF_APISERVER} -c cdf-apiserver -- bash -c "VAULT_TOKEN=$VAULT_TOKEN vault write -tls-skip-verify -format=json RE/sign/coretech csr=\"${CSR}\"") && \
echo "$WRITE_RESPONSE" | jq -r ".data | .certificate" > ${COMMON_NAME}.signed.crt && \
echo "$WRITE_RESPONSE" | jq -r ".data | .issuing_ca" > ${COMMON_NAME}.issue_ca.crt && \
echo "$WRITE_RESPONSE" | jq -r ".data | .certificate, if .ca_chain then .ca_chain[] else .issuing_ca end" > ${COMMON_NAME}.signed.cert.with.ca.crt

The signed certificate is in the file ${COMMON_NAME}.signed.crt. The issuing CA is in the file ${COMMON_NAME}.issue_ca.crt. The signed certificate with the CA chain is in the file ${COMMON_NAME}.signed.cert.with.ca.crt.

Retrieve the RE certificates:

For an on-premises deployment:

cd /opt/arcsight/kubernetes/scripts/

./cdf-updateRE.sh > /tmp/esm/${CA_CERT}

For a cloud deployment:

cd {path to cdf installer}/cdf-deployer/scripts/

./cdf-updateRE.sh > /tmp/esm/${CA_CERT}

Copy the following files from the Transformation Hub /tmp/esm folder to an ESM host folder (for example, /opt/arcsight/tmp):

/tmp/esm/${COMMON_NAME}.signed.cert.with.ca.crt

/tmp/esm/${CA_CERT}

Remove the files from /tmp/esm after you copy them.
On the ESM server, import the RE certificate from file ${CA_CERT} into the ESM client truststore:
```
/opt/arcsight/manager/bin/arcsight keytool -store clientcerts -alias <alias for the certificate> -importcert -file <absolute path to certificate file>
```
For example:

/opt/arcsight/manager/bin/arcsight keytool -store clientcerts -alias thcert -importcert -file /opt/arcsight/tmp/re_ca.cert.pem

Note: You might receive the following message:

Certificate already exists in keystore under alias <alias1>

Do you still want to add it? [no]:

It is not necessary to add an existing certificate.
On the ESM server, run the following command to import the signed certificate:
```
/opt/arcsight/manager/bin/arcsight keytool -store clientkeys -alias <alias for the key> -importcert -file <path to signed cert> -trustcacerts
```
For example:

/opt/arcsight/manager/bin/arcsight keytool -store clientkeys -alias ebkey -importcert -file /opt/arcsight/tmp/${COMMON_NAME}.signed.cert.with.ca.crt –trustcacerts

Note: You might see the following warning:

...

Top-level certificate in reply:

...

... is not trusted. Install reply anyway? [no]:

This is because the root certificate of the RE CA is not in the ESM truststore. This does not affect the functionality of ESM. Enter yes to allow the new certificate to be imported.

To complete the configuration, configure ESM to consume from Transformation Hub.