fp_idmworks Honored Contributor.
Honored Contributor.

Re: Error when authenticating to IDM OSP from IDGov

If I'm understanding right, the certs used for https on tomcat should be imported into the apps-trustore.pkcs12, as well as the certs in the osp keystore. So if you generated a tomcat.ks file for each application, such as reporting, IG and Identity Application; they would all need to be imported into the apps-trustore.pkcs12.

If you are running Identity Application with it's own osp, I'm assuming you would need to take everyting in the cacerts and import it into the IG OSP servers's apps-trustore.pkcs12. And then everything that was in the apps-trustore.pkcs12 in the IG Server should go into the cacerts on the identity Application server.

server 1: identity application server with it's own osp << need certs from apps-trustore.pkcs12 on the IG server
Server 2: IG, reporting, osp << needs certs from the apps-trustore.pkcs12 on the identity application server

I'm assuming aliases would need to match up, etc...

Is this right?
0 Likes
Micro Focus Expert
Micro Focus Expert

Re: Error when authenticating to IDM OSP from IDGov

On 2/5/19 5:24 AM, marcus jonsson wrote:
>
> marcus_jonsson;2494766 Wrote:
>> In addition, I also verified connections using SSLPoke, and that works
>> fine in all ways (OSP -> IDGov and IDGov -> OSP)
>> https://github.com/MichalHecko/SSLPoke
>>
>> Best regards
>> Marcus

>
> Hi.
>
> Issue resolved. Added CA and intermediate CA to the osp.jks keystore.
>
> Seems that tomcat/jre does not use cacerts in this process?
>
> Best regards
> Marcus
>
>

Greetings Marcus,
That is interesting. I am a bit curious as to why that was
necessary. Were you using the osp.jks file for more than just OSP to do
its work? Was tomcat also using it? In configupdate, there are 2 places
to map a truststore on the authorization tab. 1 should have been
pointing to the osp.jks and the other to the truststore that tomcat was
using for https. Was that the case for you?



--
Sincerely,
Steven Williams
Principal Enterprise Architect
Micro Focus
0 Likes
Marcus Tornberg Honored Contributor.
Honored Contributor.

Re: Error when authenticating to IDM OSP from IDGov

stevewdj;2494853 wrote:
On 2/5/19 5:24 AM, marcus jonsson wrote:
>
> marcus_jonsson;2494766 Wrote:
>> In addition, I also verified connections using SSLPoke, and that works
>> fine in all ways (OSP -> IDGov and IDGov -> OSP)
>> https://github.com/MichalHecko/SSLPoke
>>
>> Best regards
>> Marcus

>
> Hi.
>
> Issue resolved. Added CA and intermediate CA to the osp.jks keystore.
>
> Seems that tomcat/jre does not use cacerts in this process?
>
> Best regards
> Marcus
>
>

Greetings Marcus,
That is interesting. I am a bit curious as to why that was
necessary. Were you using the osp.jks file for more than just OSP to do
its work? Was tomcat also using it? In configupdate, there are 2 places
to map a truststore on the authorization tab. 1 should have been
pointing to the osp.jks and the other to the truststore that tomcat was
using for https. Was that the case for you?



--
Sincerely,
Steven Williams
Principal Enterprise Architect
Micro Focus


Hi!

I noted that I forgot to specify that it was added to the osp.jks on the IDGov server. No change was needed on the Identity Applications side.

I was not happy with my result yesterday, so after a night’s sleep I figure I'll try another thing.

To give some background that I probably should have provided from the start of the thread, IDGov was initially setup with OSP running on the IDGov server. My task was to reassign to the Identity Applications OSP instead.

As I do not have the GUI, I am left with guessing my way around configutil.sh, so I cannot answer Stevens questions directly as I have no idea what tab each setting is configured in.

I figured I try and remove the references in configutil.sh to the osp.jks file and for safety also rename the osp.jks so it cannot be magically found.

The following parameters were set pointing to osp.jks, and I cleared them using configutil.sh:
com.netiq.idm.osp.ssl-keystore.file = /opt/netiq/idm/apps/osp/osp.jks
com.netiq.idm.osp.oauth-keystore.file = /opt/netiq/idm/apps/osp/osp.jks
com.netiq.idm.osp.oauth-truststore.file = /opt/netiq/idm/apps/osp/osp.jks

I also completed the uninstall of osp on the idgov server.

After that, it seems that having the CA and intermediate CA in cacerts is enough.

My guess is therefor that tomcat/jre reads cacerts first to get trusted certs, and then later it reads osp.jks (if referenced) and only trusts any certificates in osp.jks (ignoring cacerts).

For future references, I set the following in configutil.sh to point IDGov to the Identity Applications OSP (osp.domain.com):
com.netiq.client.authserver.url.authorize = https://osp.domain.com:8443/osp/a/idm/auth/oauth2/grant
com.netiq.client.authserver.url.logout = https://osp.domain.com:8443/osp/a/idm/auth/app/logout
com.netiq.client.authserver.url.token = https://osp.domain.com:8443/osp/a/idm/auth/oauth2/getattributes
com.netiq.iac.authserver.host = https://osp.domain.com:8443
com.netiq.iac.authserver.url.authorize = https://osp.domain.com:8443/osp/a/idm/auth/oauth2/grant
com.netiq.iac.authserver.url.logout = https://osp.domain.com:8443/osp/a/idm/auth/app/logout
com.netiq.iac.authserver.url.token = https://osp.domain.com:8443/osp/a/idm/auth/oauth2/getattributes
com.netiq.iac.CORSclient = https://osp.domain.com:8443
com.netiq.iac2.redirect.url = https://osp.domain.com:8443/IDMProv/oauth
com.netiq.idm.osp.ldap.host = osp.domain.com
com.netiq.idm.osp.url.host = https://osp.domain.com:8443

I am not sure that the two last settings are neccecary (com.netiq.idm.osp*).

Best regards
Marcus
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.