IIQ Database Encryption

IdentityIQ (IIQ) IIQ Discussion and Questions
1

Which IIQ version are you inquiring about?

8.4p2 - On Windows with Apache Tomcat (SSB)

Share all details about your problem, including any error messages you may have received.

Hi everyone, I’m reaching out because I have an effort to encrypt the traffic between IIQ and the database’s that IIQ uses. We are on 8.4p2 and therefore we have 3 databases that we use. I have successfully encrypted the traffic on our DEV and QA environment but when I made the same change in our production environment the database administrators are showing that the traffic isn’t encrypted.

I’m not quite sure what i’m doing wrong in the production environment, why it wouldn’t show encrypted but the lower environments do.

I was hoping I could get some insights from others who’ve maybe done this before.

Here are my JDBC connection strings in iiq.properties:

dataSource.url=jdbc:sqlserver://piiqsql02:1433;databaseName=identityiq;encrypt=true;trustServerCertificate=false;

dataSourceAccessHistory.url=jdbc:sqlserver://piiqsql02:1433;databaseName=identityiqah;encrypt=true;trustServerCertificate=false;

pluginsDataSource.url=jdbc:sqlserver://piiqsql02:1433;databaseName=identityiqPlugin;encrypt=true;trustServerCertificate=false;

Steps I’ve taken so far:

  1. The certificate has been installed on the server by the DBA’s / Sys Admins.
  2. I’ve updated the iiq.properties file to have the above connection strings for each database.
  3. Merged changes from my feat branch into my master
  4. Ran Build Deploy
  5. I rebooted Apache (cleared cache)
  6. I Rebooted SailPoint IQ Service
  7. I Rebooted the entire Server Host

I’m not sure if I missed some steps or something else maybe overridding the setting… Any help would be greatly appreciated!

2

The Most likely cause: Stale SSB build — your edited iiq.properties was never packaged into the deployed WAR.

The fix could be is to rebuild the SSB artifact incorporating your iiq.properties changes, redeploy the WAR to Tomcat, then restart. Don’t just edit the file on disk and restart — in SSB, iiq.properties is a build-time artifact.

3

I did do a rebuild through my deployment process. I usually first change the code via a feat branch, then merge into our master branch then do a build deploy which does the rebuild of our .war

4

In that case the issue could be The JVM truststore on prod doesn’t have the SQL Server certificate.

You have trustServerCertificate=false, which means the JDBC driver must validate the cert against the JVM truststore. If the cert isn’t there, some driver versions silently fall back to unencrypted rather than throwing an error.

Import the SQL Server cert into the JVM truststore on the prod host, and then restart tomcat.

5

@MRP4ND4 There could be multiple reasons for the issue:

  • With trustServerCertificate=false, the JDBC driver performs full certificate validation. The SQL Server’s TLS certificate (or its CA chain) must be imported into the Java truststore (cacerts) on the IIQ application server.
  • With trustServerCertificate=false, the certificate’s Common Name (CN) or Subject Alternative Name (SAN) must match the hostname used in the JDBC URL.
  • Even though the client requests encryption, the SQL Server must also be properly configured to allow the server-side TLS.
  • After making changes, ensure all existing connection pool connections are flushed. A full Tomcat restart (not just cache clear) should handle this, but verify no load balancer is routing to a stale instance.

Please review them and let us know if it works or not.