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.

--Jim

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.

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.

--Jim