IT CanvassTalk to an advisor
Installation · LessonBy , SailPoint Trainer, 7 yrs · Published · IdentityIQ 8.4 · all levels

SSL

Securing IdentityIQ with TLS/SSL: certificates, keystores and connector trust.

Quick answer

Configure TLS on the app server with a valid certificate and keystore, and import target-system certificates so connectors trust them.

Key takeaways
  • Prerequisites for SSL
  • Step-by-step install path
  • Common pitfalls and fixes
  • Verification after install

TLS/SSL protects credentials and data in transit, both for users reaching the IdentityIQ UI and for connectors talking to target systems. A production deployment must enforce HTTPS for the web tier and trust the certificates of every system it integrates with. Certificate problems are, in turn, one of the most common sources of connectivity failures, so understanding the keystore/truststore model pays off.

Two sides of TLS in IdentityIQ

  • Inbound: the UI and REST APIs should be served over HTTPS, terminated at Tomcat's HTTPS connector or an upstream load balancer.
  • Outbound: when connectors talk to targets over TLS (LDAPS, HTTPS APIs), IdentityIQ must trust those systems' certificates via its truststore.

Step by step

  • 1. Obtain a valid certificate for the IdentityIQ hostname from a trusted CA.
  • 2. Configure the keystore and HTTPS connector (in server.xml or on the load balancer) to present that certificate.
  • 3. Enforce HTTPS for the UI and REST, redirecting or disabling plain HTTP.
  • 4. Import target certificates into IdentityIQ's truststore so connectors trust the systems they call.
  • 5. Test the full chain, including any intermediate CA certificates.

Certificate lifecycle

Certificates expire, and an expired signing or server certificate silently breaks SSO and connector connectivity. Track expiry dates and rotate ahead of time. When a connector suddenly fails with a TLS or trust error, an expired or untrusted certificate is the first thing to check.

Verify

Confirm the UI serves over HTTPS with a valid, fully-chained certificate and no browser warnings, and that TLS-based connectors aggregate successfully.

Common pitfalls

  • Incomplete certificate chain, missing intermediate CA certs.
  • Target certs not imported into the truststore, breaking connectors.
  • Expired certificates taking down SSO or connectivity.

Practice challenge

+0 XPStreak ×0
Question 1 of 3
What are the prerequisites for SSL?

Frequently asked questions

What does SSL stand for in SailPoint?
TLS/SSL protects credentials and data in transit, both for users reaching the IdentityIQ UI and for connectors talking to target systems. A production deployment must enforce HTTPS for the web tier and trust the certificates of every system it integrates with.
Which systems are connected to SSL?
Inbound: the UI and REST APIs should be served over HTTPS, terminated at Tomcat's HTTPS connector or an upstream load balancer. Outbound: when connectors talk to targets over TLS (LDAPS, HTTPS APIs), IdentityIQ must trust those systems' certificates via its truststore.
What is worth checking first with SSL?
When a connector suddenly fails with a TLS or trust error, an expired or untrusted certificate is the first thing to check.
What tends to go wrong with SSL?
Incomplete certificate chain, missing intermediate CA certs. Target certs not imported into the truststore, breaking connectors. Expired certificates taking down SSO or connectivity.
Want this with a live instructor and a lab tenant?
SailPoint Architect training →
Already working on SailPoint and stuck on a live ticket?Get an expert SailPoint developer on screen-share to finish your daily tasks with you. Deliver on time, protect your reputation and your job. Monthly support only, no task-wise plans.Task assigned · no idea where to startStill stuck · your job on the lineExpert joins your screenDelivered on timeExplore On Job Support