This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Workflow Error

Hello All,

I am working on 2 level resource request approval Workflow, when i request for resource from user application, Start of workflow fails and i was able to see resource request status as : Pending Approval: Pending Approval Retry in user application.

I couldn't find any start status of workflow in the logs, When i looked at logs of Roles and resource driver i am able to see the below error.

DirXML Log Event -------------------
Driver: \IDV\system\driverset1\Role and Resource Service Driver
Channel: Subscriber
Status: Error
Message: Unable to start Approval Workflow
Workflow DN: cn=AccountWF,cn=RequestDefs,cn=AppConfig,cn=UserApplication,cn=driverset1,o=system
Reason: java.lang.RuntimeException: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target.

Note: This error is coming only for this workflow, for the rest it was not showing any error and all the trusted root certificates are placed correctly.

Can someone suggest me how to fix this issue.


Regards,
Eswar.
  • 0   in reply to 
    On 8/10/2017 7:44 AM, ed00491298 wrote:
    >
    > Hi Siva,
    >
    > Thank you for the Response.
    >
    > I went and double checked the Certificates in the Keystore and found the
    > required certificates were missing.
    >
    > Import the required certificates and restarted the edirectory, it
    > started working without any errors.


    Which is interesting that the other Start Workflow calls worked...
    Perhaps those were hitting the http interface instead? (That is why I
    was asking for trace of a working and failing example to see).

  • 0   in reply to 
    On 8/10/2017 8:04 AM, SPSivasubramanian wrote:
    >
    > ed00491298;2463885 Wrote:
    >>
    >> Thank you for the Response.
    >>
    >> I went and double checked the Certificates in the Keystore and found the
    >> required certificates were missing.
    >>
    >> Import the required certificates and restarted the edirectory, it
    >> started working without any errors.
    >>
    >>

    >
    > Glad and Thank you Eswar for your double-confirmation on this. I hope,
    > this information could be added/updated in our Documentation section -
    > we'd take care of the same for other customers.[Had sent note to my
    > appropriate team on this request]


    Honestly, I think the docs need a troubleshooting OSP, UA sectionn that
    starts with listing the certs needed, sample keytool commands to
    export/import them and just be very clear on that. Right now it is
    there, but not consolidated in one place that is obvious what to do, once.

    Also remember, (I embarassingly forgot once, my defense was I was
    troubleshooting on the phone with a coworker while I bicyled home from
    work) to mention if using SAML, the OSP keystore also needs the NAM/IDP
    cert.
  • 0   in reply to 
    On 8/10/2017 7:46 AM, ed00491298 wrote:
    >
    > Hi geoff,
    >
    > Thank you for the reply.
    >
    > Checked and found the required certificates were missing in the
    > Keystore
    >
    > Import the required certificates and restarted the edirectory, it
    > started working without any errors.


    For fun, did you try before you restarted eDir?

    We know that JAR's if loaded, will not be updated (reloaded) without an
    eDir restart.

    OSP caches all the certs in memory (Or at least reads them initially,
    see the OSP.log in level ALL).

    What is unclear to me is if the engine re-reads cacerts each time, or
    caches it in memory and needs a restart of eDir.
  • 0 in reply to   
    geoffc;2463894 wrote:
    On 8/10/2017 8:04 AM, SPSivasubramanian wrote:
    >
    > ed00491298;2463885 Wrote:
    >>
    >> Thank you for the Response.
    >>
    >> I went and double checked the Certificates in the Keystore and found the
    >> required certificates were missing.
    >>
    >> Import the required certificates and restarted the edirectory, it
    >> started working without any errors.
    >>
    >>

    >
    > Glad and Thank you Eswar for your double-confirmation on this. I hope,
    > this information could be added/updated in our Documentation section -
    > we'd take care of the same for other customers.[Had sent note to my
    > appropriate team on this request]


    Honestly, I think the docs need a troubleshooting OSP, UA sectionn that
    starts with listing the certs needed, sample keytool commands to
    export/import them and just be very clear on that. Right now it is
    there, but not consolidated in one place that is obvious what to do, once.

    Also remember, (I embarassingly forgot once, my defense was I was
    troubleshooting on the phone with a coworker while I bicyled home from
    work) to mention if using SAML, the OSP keystore also needs the NAM/IDP
    cert.


    Dear Geoffrey,

    Thanks much once again. We are listening to your valuable suggestions online and Offline; in the same way we are going to incorporate the comments in good form.
  • 0   in reply to   
    On 8/10/17 9:22 AM, Geoffrey Carman wrote:
    > On 8/10/2017 8:04 AM, SPSivasubramanian wrote:
    >>
    >> ed00491298;2463885 Wrote:
    >>>
    >>> Thank you for the Response.
    >>>
    >>> I went and double checked the Certificates in the Keystore and found the
    >>> required certificates were missing.
    >>>
    >>> Import the required certificates and restarted the edirectory, it
    >>> started working without any errors.
    >>>
    >>>

    >>
    >> Glad and Thank you Eswar for your double-confirmation on this. I hope,
    >> this information could be added/updated in our Documentation section -
    >> we'd take care of the same for other customers.[Had sent note to my
    >> appropriate team on this request]

    >
    > Honestly, I think the docs need a troubleshooting OSP, UA sectionn that
    > starts with listing the certs needed, sample keytool commands to
    > export/import them and just be very clear on that. Right now it is
    > there, but not consolidated in one place that is obvious what to do, once.
    >
    > Also remember, (I embarassingly forgot once, my defense was I was
    > troubleshooting on the phone with a coworker while I bicyled home from
    > work) to mention if using SAML, the OSP keystore also needs the NAM/IDP
    > cert.

    Greetings Geoffrey,
    The SOAP endpoints of the User Application are not "protected" by
    OSP.

    --
    Sincerely,
    Steven Williams
    Principal Enterprise Architect
    Micro Focus
  • 0   in reply to   
    On 8/10/17 9:23 AM, Geoffrey Carman wrote:
    > On 8/10/2017 7:46 AM, ed00491298 wrote:
    >>
    >> Hi geoff,
    >>
    >> Thank you for the reply.
    >>
    >> Checked and found the required certificates were missing in the
    >> Keystore
    >>
    >> Import the required certificates and restarted the edirectory, it
    >> started working without any errors.

    >
    > For fun, did you try before you restarted eDir?
    >
    > We know that JAR's if loaded, will not be updated (reloaded) without an
    > eDir restart.
    >
    > OSP caches all the certs in memory (Or at least reads them initially,
    > see the OSP.log in level ALL).
    >
    > What is unclear to me is if the engine re-reads cacerts each time, or
    > caches it in memory and needs a restart of eDir.

    Greetings Geoffrey,
    Please keep in mind that the SOAP endpoints in the User Application
    are not "protected" by OSP. The actions from IDM that call to the User
    App (start workflow, add role/resource, remove role/resource) are all
    calling to the SOAP endpoints. So, looking at OSP in these cases will
    not be of any benefit.



    --
    Sincerely,
    Steven Williams
    Principal Enterprise Architect
    Micro Focus
  • 0   in reply to   

    > The SOAP endpoints of the User Application are not "protected" by
    > OSP.


    Is that another way of saying you use Basic Auth to connect to SOAP? I
    had noticed. So in this very specific case, were the issue was Engine
    calling Do Start Workflow, and getting a cert error, it is just the
    Tomcat server cert not trusted.

    In the more general case, once we discuss docs, it is worth calling out
    ALL the certs that potentially can be in play.

    But a good point, thanks.

  • 0   in reply to   

    >>> Checked and found the required certificates were missing in the
    >>> Keystore
    >>>
    >>> Import the required certificates and restarted the edirectory, it
    >>> started working without any errors.

    >>
    >> For fun, did you try before you restarted eDir?
    >>
    >> We know that JAR's if loaded, will not be updated (reloaded) without an
    >> eDir restart.
    >>
    >> OSP caches all the certs in memory (Or at least reads them initially,
    >> see the OSP.log in level ALL).
    >>
    >> What is unclear to me is if the engine re-reads cacerts each time, or
    >> caches it in memory and needs a restart of eDir.



    > Please keep in mind that the SOAP endpoints in the User Application
    > are not "protected" by OSP. The actions from IDM that call to the User
    > App (start workflow, add role/resource, remove role/resource) are all
    > calling to the SOAP endpoints. So, looking at OSP in these cases will
    > not be of any benefit.


    Fair point. I was diverging to a different thought, which was a question
    of whether the Engine re-loads cacerts when needed, or caches it.
    Contrasting that with OSP which you case see loads it all at run time.
    (Cannot tell if it is cached or just loaded, and if it is reloaded on
    need).


  • 0 in reply to   
    On 8/10/2017 10:26 AM, Geoffrey Carman wrote:
    >
    >>>> Checked and found the required certificates were missing in the
    >>>> Keystore
    >>>>
    >>>> Import the required certificates and restarted the edirectory, it
    >>>> started working without any errors.
    >>>
    >>> For fun, did you try before you restarted eDir?
    >>>
    >>> We know that JAR's if loaded, will not be updated (reloaded) without an
    >>> eDir restart.
    >>>
    >>> OSP caches all the certs in memory (Or at least reads them initially,
    >>> see the OSP.log in level ALL).
    >>>
    >>> What is unclear to me is if the engine re-reads cacerts each time, or
    >>> caches it in memory and needs a restart of eDir.

    >
    >
    >> Please keep in mind that the SOAP endpoints in the User
    >> Application are not "protected" by OSP. The actions from IDM that
    >> call to the User App (start workflow, add role/resource, remove
    >> role/resource) are all calling to the SOAP endpoints. So, looking at
    >> OSP in these cases will not be of any benefit.

    >
    > Fair point. I was diverging to a different thought, which was a question
    > of whether the Engine re-loads cacerts when needed, or caches it.
    > Contrasting that with OSP which you case see loads it all at run time.
    > (Cannot tell if it is cached or just loaded, and if it is reloaded on
    > need).
    >
    >


    From past experience the IDM JVM inside ndsd memory space is loaded
    when you first load IDM and stays loaded, at that point it reads and
    caches cacerts. Every time I've updated the JVM's certs I had to restart
    ndsd.
  • 0   in reply to 
    >>
    >> Fair point. I was diverging to a different thought, which was a
    >> question of whether the Engine re-loads cacerts when needed, or caches
    >> it. Contrasting that with OSP which you case see loads it all at run
    >> time. (Cannot tell if it is cached or just loaded, and if it is
    >> reloaded on need).
    >>
    >>

    >
    > From past experience the IDM JVM inside ndsd memory space is loaded
    > when you first load IDM and stays loaded, at that point it reads and
    > caches cacerts. Every time I've updated the JVM's certs I had to restart
    > ndsd.


    Thanks, I was wondering, good to have it confirmed either way. I could
    see it looking it up each time a check was needed. Or else caching it.