IGA 3.7.3 - FQDN of OSP has changed

Dear Forum,

in my lab environment I have installed IDM Applications and OSP on one Server and IG on an other server. 

The setup was working, quite well.

After a while I changed the IDM Applications and OSP to run behind an Apache proxy and changed the FQDN as well.

Access to IDM Applications through the new FQDN and an url like https://newserver is working as expected. 

Since IG was using the OSP on the IDM Application Server by the URL https://oldserver:8543 I know I have to change the IG configuration, but this ain't work

First, I started the configutil provided by the IG installation and changed the OSP server in the authorization configuration.

But after pressing save the configutil gets stuck - I waited for several minutes, but it did not terminate.

Checking the ism-configuration.properties on the IG server I found two parameters still referring to the old OSP URL https://oldserver:8543, and I changed those parameters manually to https://newserver - but with no success. Accessing the login page, the browser is offering only a blank page! Using the browser development tools I found, it still is trying to access https://oldserver:8543

Can anybody provide some ideas how to fix the IG setup without reinstalling the whole server!

Kind regards


  • In addition to configutil, you will want to run configupdate as well to config the URLs.   Note that in recent versions the file ism-config and the ism-global config aren't authoritative for those settings. The values in the database ism-config table are authoritative.  The config tools are modifying the database.   You may also like to run configutil in -console mode, and take a look at all the available properties.  You might find some URL's that are not exposed in the GUI there that you may need to set.

    ALSO, you might need to look at the name resolution on the box running OSP.  during startup it tries to evaluate its own hostname (/etc/hosts file perhaps) and it will provide endpoints on what it thinks its running as.   One way to check the health of OSP is to hit this URL: http(s)://server:prt/osp/a/idm/auth/app .   That will let you authenticate right to OSP, and it will bring you to a blank dashboard if OSP is functional.   

    Similarly, there is a URL HTTP(s)://server:prt/osp/a/idm/auth/oauth2/.well-known/openid-configuration   that you should be able to hit that will show you the endpoint URLs that OSP is hosting for token service.  You will want to confirm these all look appropriate.

    I'd love to hear if you get OSP working behind a proxy - during use of the IG tool there is quite a bit of token traffic to OSP, so it may be more complicated that what I've mentioned here.


  • I agree with everything Jim said.  You can look at the DB itself, I find easier to find bad settings...  I forget the table name but it is very obvious.

    Also, the certificate uses for SSL must have a Subject Alternate Name for the new FQDN.  You can turn on a Java opt to override that, but best to re-mint the certificate.

    Also if DNS returns two names for the IP during resolution, there is something about it prefers the longer or shorter name.  There is a setting to tell it the preferred name in OSP.

  • It is:idm_global_config

    Also, that's a great point about the certificates.   You will need to ensure not only so the subject and subject alt names match up correctly, but that they (the tls certs for OSP) are trusted on the side where IG is hosted for the OSP certs.  Similarly, the IG server's tls cert will need to be trusted by OSP.   In previous versions I've added certs to the java truststore on the system as well as the osp truststore, and the tomcat/conf truststores, and that has worked, although I can't explain the details of which one is used when.


  • Verified Answer

    I highly recommend launching configutil in console mode and then issue: es
    This will dump all of the Global (database) and Local properties (ism-configuration.properties).

    This is one (1) of the first things that I request via Support when working on "configuration" kinds of issues.

    Steven Williams
    Principal Enterprise Architect
    OpenText Cybersecurity

  • Oh, that is slick!   I usually craft a script with 'dc' in it, then pass that to configutil and redirect the output, but I like this much more!


  • Hello Steven,

    thanks for this advice - I will run configutil in console mode, the next time I have access to my environment.

    The strange thing is, that if I run it in GUI mode, I can change the URL of the OAuth server, but after pressing save nothing happens .....

    Kind regards


  • HI jim,

    the certificates assigned to OSP are valid and SAN are set correctly. Since I can access IDM Dash after the changes the IDM Application server, I believe this side is good ...

    The new certificates of IDM Applications and OSP are signed by the eDirectory CA, like the old ones - and I had the CA certs imported on the IG server in the original setup, therefore I am confident, I do not have a certificate issue ;-)

    What I do see when using the web development tools of my browser is, that IG is constantly accessing the old server FQDN when accessing the OSP server. 

    I guess I will try to run configutil in console mode or tray to modify the entry in the configuration DB manually, as soon I am back home ...

    Kind regards


  • I'll suggest clearing your browser cache as well.  Check the hosts file, and ensure that the well-known endpoints URL has what you expect.   Something, somewhere is either remembering the old hostname, or is still set to use it!


Reply Children
  • Hi Jim,

    I followed your suggestion to run configutil.sh in console  mode, but did not find any parameter referring to the OSP URL - which is quite confusing, since in GUI mode it was showing all those settings.

    Following another suggestion, I went to the DB directly and found the parameter com.netiq.idm.osp.url.host in ism_global_config still set to the previous FQDN.

    After changing this value, the redirect to the OSP login is working as expected - but now I am facing a certificate revocation error:#

    [com.netiq.iac.server.j2ee.AuthFilter] [IG-SERVER] Encountered unexpected error: javax.net.ssl.SSLHandshakeException: PKIX path validation failed: java.security.cert.CertPathValidatorException: Could not determine revocation status

    Remembering a similar issue with IDM Applications, I added 


    to the JAVA_OPTS in setenv.sh, but this does not help!

    Just to clarify - the setup was working with the old FQDN of OSP and the certificate of the new FQDN was signed by the same CA (edirectory CA) as the old one ...

    Kind regards


  • sometimes the solution is to simple - using "-Dcom.sun.security.enableCRLDP=false" solved the  revocation issues using ISP! Anything seams to be sorted now!

    Thanks everyone!