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.

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

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

Thorsten

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!

--Jim

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 

-Dcom.sun.security.enableCRLDP=true

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

Thorsten

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!

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!