SSL "Not Secure" error in User Behavior Analytics (UBA) after Failover

Applicability

Description

After performing a failover in Splunk UBA from the primary site to the standby site, users encounter an SSL "Not Secure" warning in their browsers when accessing the UBA web interface. This warning indicates that the SSL certificate being used was generated for the primary site's hostname and does not match the standby site's hostname now being accessed. The browser does not trust the certificate due to the hostname mismatch, preventing users from accessing the UBA interface without manually accepting security warnings.

  

Investigation

During investigation after a failover, the following issues are commonly identified:

Certificate Hostname Mismatch:

1. UBA is using a certificate generated for the primary site hostname
2. After failover, users are now accessing the standby site with a different hostname
3. Certificate Common Name (CN) does not match the current hostname being accessed
4. Subject Alternative Names (SAN) in the certificate do not include the standby site hostname

Failover Certificate Issue:

1. Certificate was generated only for the primary site during initial setup
2. Standby site was not included in the certificate's Subject Alternative Names
3. After promotion of standby to primary, the certificate is no longer valid for the new hostname
4. Default behavior does not automatically regenerate certificates during failover

Resolution

Follow these steps to generate a proper SSL certificate that works for both primary and standby sites:

Step 1: Stop Required Services

Stop the Resource Monitor and UI services before making certificate changes:

sudo service caspida-resourcesmonitor stop
sudo service caspida-ui stop

Step 2: Generate Root Certificate and Server Certificate

Execute the below command to generate a new root certificate and server certificate with private key. Replace the parameters with organization's details:

sudo /opt/caspida/bin/CaspidaCert.sh <Country> <State> <City> <Organization> <OrganizationDomain> "<UBA_Primary_FQDN>" /var/vcap/store/caspida/certs/mycerts

Example:

sudo /opt/caspida/bin/CaspidaCert.sh US California SanJose OrganizationName example.com "uba-primary.example.com" /var/vcap/store/caspida/certs/mycerts

This generates:

1. my-root-ca.crt.pem (Root CA certificate)
2. my-server.crt.pem (Server certificate)
3. my-server.key.pem (Private key)

Step 3: Configure Certificate Paths in uba-site.properties

Edit the UBA configuration file:

sudo vi /etc/caspida/local/conf/uba-site.properties

Add the following lines:

ui.auth.rootca=/var/vcap/store/caspida/certs/mycerts/my-root-ca.crt.pem
ui.auth.privateKey=/var/vcap/store/caspida/certs/mycerts/my-server.key.pem
ui.auth.serverCert=/var/vcap/store/caspida/certs/mycerts/my-server.crt.pem

Step 4: Create Subject Alternative Names (SAN) Configuration

Critical for failover environments: Create a SAN configuration file to include hostnames for both primary and standby sites:

vi /tmp/san.cnf

Add the following content (customize DNS entries for your primary and standby hostnames):

[ req ]
default_bits        = 2048
distinguished_name  = req_distinguished_name
req_extensions      = req_ext[ req_distinguished_name ]
countryName             = Country Code
stateOrProvinceName     = State Name
localityName            = City Name
organizationName        = Organization Name
commonName              = uba-primary.domain.com[ req_ext ]
subjectAltName = @alt_names[alt_names]
DNS.1 = uba-primary.domain.com
DNS.2 = uba-primary
DNS.3 = primary-node.domain.com
DNS.4 = primary-node
DNS.5 = standby-node.domain.com
DNS.6 = standby-node

Including both primary and standby hostnames in the SAN configuration ensures the certificate works after failover to either site, preventing hostname mismatch errors.

Step 5: Generate Certificate Signing Request (CSR)

Generate a CSR using the SAN configuration to submit to your Certificate Authority:

sudo openssl req -new -key /var/vcap/store/caspida/certs/mycerts/my-server.key.pem -out /var/vcap/store/caspida/certs/mycerts/myCACertificate.csr -config /tmp/san.cnf

This CSR can be submitted to your internal or external Certificate Authority for signing. The CA will return a signed certificate that includes all the DNS names specified in the SAN configuration, ensuring the certificate is valid for both primary and standby sites.

Step 6: Set Proper Permissions on Certificate Files

sudo chmod 644 /var/vcap/store/caspida/certs/mycerts/*
sudo chmod 600 /var/vcap/store/caspida/certs/mycerts/my-server.key.pem
sudo chown caspida:caspida /var/vcap/store/caspida/certs/mycerts/*

Step 7: Update Configuration with CA-Signed Certificate (After CA Signing)

Once received the signed certificate from CA, place the signed certificates in the certs directory and update the configuration:

sudo vi /etc/caspida/local/conf/uba-site.properties

Update to reference the CA-signed certificates:

ui.auth.rootca=/var/vcap/store/caspida/certs/mycerts/RootCA.pem
ui.auth.privateKey=/var/vcap/store/caspida/certs/mycerts/my-server.key.pem
ui.auth.serverCert=/var/vcap/store/caspida/certs/mycerts/SignedCertificate.pem

Note: Replace filenames with actual names of your CA-signed certificate files.

Step 8: Sync Configuration Across Cluster (Multi-node Only)

For multi-node UBA cluster, sync the certificate configuration to all nodes on both primary and standby sites:

/opt/caspida/bin/Caspida sync-cluster /etc/caspida/local/conf/

Step 9: Start UI and Resource Monitor Services

sudo service caspida-ui start
sudo service caspida-resourcesmonitor start

Related Links

Document Link: Reference