Welcome Serena Central users! CLICK HERE
The migration of the Serena Central community is currently underway. Be sure to read THIS MESSAGE to get your new login set up to access your account.
Highlighted
Anonymous_User Absent Member.
Absent Member.
437 views

Integration Activity and Subject Alternate Name certs


IDM 4.5.4 on RedHat, with eDir 8.8.8.8 and OSP 6.0.03

I have a workflow with an Integration Activity calling the UA SOAP
endpoint to Create/Delete/Modify Roles.

The Start Workflow call from the engine server, uses a GCV that works to
start the process.

The workflow begins, only activity is the Integration Activity.

The integration activity uses the same GCV (Copied to UA driver, so not
actual same GCV, but same name and same value) to call the SOAP
endpoint.

cacerts (engine and UA server) has the public key of the UA's private
key. That key has 12 Subject Alternate Names (poor mans wildcard cert).
It has the public key of the eDir CA, the public key of OSP, the public
key of Tomcat.

osp.jks has the OSP private key, the eDir CA public key, the tomcat
public key.

tomcat.keystore has the Tomcat private key (with the 12 SAN's). The OSP
public key, and the eDir CA public key.

The IA throws an error that the name idmtomcat.acme.com does not match
myid.acme.com but I called idmhome.acme.com.

idmtomcat is the CN= name in the cert, which is not real nor in DNS, but
the 12 SAN's are all real and in DNS and the names myid.acme.com and
idmhome.acme.com are in the SAN list.

When I add a /etc/hosts entry of idmtomcat.acme.com to point at the UA
local (have to do this on each UA box) the IA works.

This leads me to think that Integration Activity's have an issue when
the Source NAme of the Cert does not match the name you use in the SOAP
call. This seems like it is NOT honoring Subject Alternate Names
properly.

Anyone else ever seen something like this?


--
relgis
------------------------------------------------------------------------
relgis's Profile: https://forums.netiq.com/member.php?userid=12955
View this thread: https://forums.netiq.com/showthread.php?t=57006

Labels (1)
0 Likes
7 Replies
ScorpionSting Absent Member.
Absent Member.

Re: Integration Activity and Subject Alternate Name certs

We have had similar issues with drivers actioning worktasks in workflows in our clustered environment.....ended up have local workflow calls use http://localhost:8080/xxx while the drivers would look up the ENGINEID for a worktask and action it on that node also using http (our ENGINEIDs are our node names).

So backend was mix of http(s) calls, but the user UI is purely https

Visit my Website for links to Cool Solution articles.
0 Likes
Knowledge Partner
Knowledge Partner

Re: Integration Activity and Subject Alternate Name certs

On 11/30/2016 6:16 PM, ScorpionSting wrote:
>
> We have had similar issues with drivers actioning worktasks in workflows
> in our clustered environment.....ended up have local workflow calls use
> http://localhost:8080/xxx while the drivers would look up the ENGINEID
> for a worktask and action it on that node also using http (our ENGINEIDs
> are our node names).
>
> So backend was mix of http(s) calls, but the user UI is purely https


I have seen this issue at clients as well. Usually I use a Hosts
reference as well to get around it. Which is kind of annoying.

Norbert's find of the bug is good to know about and a good one to tag an
SR onto.


0 Likes
Micro Focus Expert
Micro Focus Expert

Re: Integration Activity and Subject Alternate Name certs

On 30.11.2016 23:04, relgis wrote:
>
> IDM 4.5.4 on RedHat, with eDir 8.8.8.8 and OSP 6.0.03
>
> I have a workflow with an Integration Activity calling the UA SOAP
> endpoint to Create/Delete/Modify Roles.
>
> The Start Workflow call from the engine server, uses a GCV that works to
> start the process.
>
> The workflow begins, only activity is the Integration Activity.
>
> The integration activity uses the same GCV (Copied to UA driver, so not
> actual same GCV, but same name and same value) to call the SOAP
> endpoint.
>
> cacerts (engine and UA server) has the public key of the UA's private
> key. That key has 12 Subject Alternate Names (poor mans wildcard cert).
> It has the public key of the eDir CA, the public key of OSP, the public
> key of Tomcat.
>
> osp.jks has the OSP private key, the eDir CA public key, the tomcat
> public key.
>
> tomcat.keystore has the Tomcat private key (with the 12 SAN's). The OSP
> public key, and the eDir CA public key.
>
> The IA throws an error that the name idmtomcat.acme.com does not match
> myid.acme.com but I called idmhome.acme.com.
>
> idmtomcat is the CN= name in the cert, which is not real nor in DNS, but
> the 12 SAN's are all real and in DNS and the names myid.acme.com and
> idmhome.acme.com are in the SAN list.


Please open a SR and cite Bug 964563 - HTTP client that RBPM uses
doesn’t honor the SANs in a certificate

The same problem exists in the UserApp driver.

--
Norbert
0 Likes
Knowledge Partner
Knowledge Partner

Re: Integration Activity and Subject Alternate Name certs

On 12/1/2016 3:00 AM, Norbert Klasen wrote:
> On 30.11.2016 23:04, relgis wrote:
>>
>> IDM 4.5.4 on RedHat, with eDir 8.8.8.8 and OSP 6.0.03
>>
>> I have a workflow with an Integration Activity calling the UA SOAP
>> endpoint to Create/Delete/Modify Roles.
>>
>> The Start Workflow call from the engine server, uses a GCV that works to
>> start the process.
>>
>> The workflow begins, only activity is the Integration Activity.
>>
>> The integration activity uses the same GCV (Copied to UA driver, so not
>> actual same GCV, but same name and same value) to call the SOAP
>> endpoint.
>>
>> cacerts (engine and UA server) has the public key of the UA's private
>> key. That key has 12 Subject Alternate Names (poor mans wildcard cert).
>> It has the public key of the eDir CA, the public key of OSP, the public
>> key of Tomcat.
>>
>> osp.jks has the OSP private key, the eDir CA public key, the tomcat
>> public key.
>>
>> tomcat.keystore has the Tomcat private key (with the 12 SAN's). The OSP
>> public key, and the eDir CA public key.
>>
>> The IA throws an error that the name idmtomcat.acme.com does not match
>> myid.acme.com but I called idmhome.acme.com.
>>
>> idmtomcat is the CN= name in the cert, which is not real nor in DNS, but
>> the 12 SAN's are all real and in DNS and the names myid.acme.com and
>> idmhome.acme.com are in the SAN list.

>
> Please open a SR and cite Bug 964563 - HTTP client that RBPM uses
> doesn’t honor the SANs in a certificate
>
> The same problem exists in the UserApp driver.


That is an interesting bug, I have seen this issue as well before, and
will tag on an SR, since the more SR's the more priority bug fixes get.

What do you mean by the UA driver?

Is that because the UA driver is compiled from an old Composer config,
and when it reaches out to talk to the UA over SOAP/whatever API it
uses, it has issues with SAN's?

I wonder if there is a Java property you could set to tell the HTTP
stack to ignore that? Problem is, it would be for the entire Tomcat
instance, which would be bad, since it really should not ignore cert
issues, most of the time.


0 Likes
Micro Focus Expert
Micro Focus Expert

Re: Integration Activity and Subject Alternate Name certs

On 01.12.2016 19:33, Geoffrey Carman wrote:
> On 12/1/2016 3:00 AM, Norbert Klasen wrote:
>> On 30.11.2016 23:04, relgis wrote:
>>>
>>> IDM 4.5.4 on RedHat, with eDir 8.8.8.8 and OSP 6.0.03
>>>
>>> I have a workflow with an Integration Activity calling the UA SOAP
>>> endpoint to Create/Delete/Modify Roles.
>>>
>>> The Start Workflow call from the engine server, uses a GCV that works to
>>> start the process.
>>>
>>> The workflow begins, only activity is the Integration Activity.
>>>
>>> The integration activity uses the same GCV (Copied to UA driver, so not
>>> actual same GCV, but same name and same value) to call the SOAP
>>> endpoint.
>>>
>>> cacerts (engine and UA server) has the public key of the UA's private
>>> key. That key has 12 Subject Alternate Names (poor mans wildcard cert).
>>> It has the public key of the eDir CA, the public key of OSP, the public
>>> key of Tomcat.
>>>
>>> osp.jks has the OSP private key, the eDir CA public key, the tomcat
>>> public key.
>>>
>>> tomcat.keystore has the Tomcat private key (with the 12 SAN's). The OSP
>>> public key, and the eDir CA public key.
>>>
>>> The IA throws an error that the name idmtomcat.acme.com does not match
>>> myid.acme.com but I called idmhome.acme.com.
>>>
>>> idmtomcat is the CN= name in the cert, which is not real nor in DNS, but
>>> the 12 SAN's are all real and in DNS and the names myid.acme.com and
>>> idmhome.acme.com are in the SAN list.

>>
>> Please open a SR and cite Bug 964563 - HTTP client that RBPM uses
>> doesn’t honor the SANs in a certificate
>>
>> The same problem exists in the UserApp driver.

>
> That is an interesting bug, I have seen this issue as well before, and
> will tag on an SR, since the more SR's the more priority bug fixes get.
>
> What do you mean by the UA driver?
>
> Is that because the UA driver is compiled from an old Composer config,
> and when it reaches out to talk to the UA over SOAP/whatever API it
> uses, it has issues with SAN's?


It uses the same library for making HTTPS/SOAP calls as the integration
activity in workflows (xcd-all.jar)

>
> I wonder if there is a Java property you could set to tell the HTTP
> stack to ignore that? Problem is, it would be for the entire Tomcat
> instance, which would be bad, since it really should not ignore cert
> issues, most of the time.
>
>



--
Norbert
0 Likes
Knowledge Partner
Knowledge Partner

Re: Integration Activity and Subject Alternate Name certs

On 12/1/2016 3:07 PM, Norbert Klasen wrote:
> On 01.12.2016 19:33, Geoffrey Carman wrote:
>> On 12/1/2016 3:00 AM, Norbert Klasen wrote:
>>> On 30.11.2016 23:04, relgis wrote:
>>>>
>>>> IDM 4.5.4 on RedHat, with eDir 8.8.8.8 and OSP 6.0.03
>>>>
>>>> I have a workflow with an Integration Activity calling the UA SOAP
>>>> endpoint to Create/Delete/Modify Roles.
>>>>
>>>> The Start Workflow call from the engine server, uses a GCV that works to
>>>> start the process.
>>>>
>>>> The workflow begins, only activity is the Integration Activity.
>>>>
>>>> The integration activity uses the same GCV (Copied to UA driver, so not
>>>> actual same GCV, but same name and same value) to call the SOAP
>>>> endpoint.
>>>>
>>>> cacerts (engine and UA server) has the public key of the UA's private
>>>> key. That key has 12 Subject Alternate Names (poor mans wildcard cert).
>>>> It has the public key of the eDir CA, the public key of OSP, the public
>>>> key of Tomcat.
>>>>
>>>> osp.jks has the OSP private key, the eDir CA public key, the tomcat
>>>> public key.
>>>>
>>>> tomcat.keystore has the Tomcat private key (with the 12 SAN's). The OSP
>>>> public key, and the eDir CA public key.
>>>>
>>>> The IA throws an error that the name idmtomcat.acme.com does not match
>>>> myid.acme.com but I called idmhome.acme.com.
>>>>
>>>> idmtomcat is the CN= name in the cert, which is not real nor in DNS, but
>>>> the 12 SAN's are all real and in DNS and the names myid.acme.com and
>>>> idmhome.acme.com are in the SAN list.
>>>
>>> Please open a SR and cite Bug 964563 - HTTP client that RBPM uses
>>> doesn’t honor the SANs in a certificate
>>>
>>> The same problem exists in the UserApp driver.

>>
>> That is an interesting bug, I have seen this issue as well before, and
>> will tag on an SR, since the more SR's the more priority bug fixes get.
>>
>> What do you mean by the UA driver?
>>
>> Is that because the UA driver is compiled from an old Composer config,
>> and when it reaches out to talk to the UA over SOAP/whatever API it
>> uses, it has issues with SAN's?

>
> It uses the same library for making HTTPS/SOAP calls as the integration
> activity in workflows (xcd-all.jar)


Oh lordy, that JAR. I am pretty sure back in the 4.x days there was a
duplicate ldap class in there, that caused issues, and the fix was to
carve all the LDAP classes out of there and use the proper LDAP JAR's.

That issue was funny I recall, it depended on date stamps or create
times of the JAR's as to which JAR was loaded by Java first, as to
whether it worked or failed.


0 Likes
Knowledge Partner
Knowledge Partner

Re: Integration Activity and Subject Alternate Name certs

>> It uses the same library for making HTTPS/SOAP calls as the integration
>> activity in workflows (xcd-all.jar)

>
> Oh lordy, that JAR. I am pretty sure back in the 4.x days there was a
> duplicate ldap class in there, that caused issues, and the fix was to
> carve all the LDAP classes out of there and use the proper LDAP JAR's.
>
> That issue was funny I recall, it depended on date stamps or create
> times of the JAR's as to which JAR was loaded by Java first, as to
> whether it worked or failed.


NTS got back to me (And I guess to everyone tagged on the Bug via an SR)
with a new xcd-all.jar to test that should resolve this. Not had time
to test it yet. But good to see progress.


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.